Azure SQL Database 無伺服器(預覽)Azure SQL Database serverless (preview)

Azure SQL Database 無伺服器(預覽)是單一資料庫的計算層,可根據工作負載需求自動調整計算,並以每秒使用的計算量來計費。Azure SQL Database serverless (preview) is a compute tier for single databases that automatically scales compute based on workload demand and bills for the amount of compute used per second. 無伺服器計算層級也會在活動傳回時,自動在非使用中期間暫停資料庫,並自動繼續執行資料庫。The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns.

無伺服器計算層級Serverless compute tier

單一資料庫的無伺服器計算層是透過計算自動調整範圍和自動暫停延遲來進行參數化。The serverless compute tier for a single database is parameterized by a compute autoscaling range and an autopause delay. 這些參數的設定會塑造資料庫效能體驗和計算成本。The configuration of these parameters shape the database performance experience and compute cost.

無伺服器計費

效能設定Performance configuration

  • 最小虛擬核心最大虛擬核心是可設定的參數,可定義資料庫可用的計算容量範圍。The minimum vCores and maximum vCores are configurable parameters that define the range of compute capacity available for the database. 記憶體和 IO 限制會與指定的虛擬核心範圍成比例。Memory and IO limits are proportional to the vCore range specified.
  • 自動暫停延遲是可設定的參數,定義資料庫在自動暫停之前必須處於非使用中狀態的時間週期。The autopause delay is a configurable parameter that defines the period of time the database must be inactive before it is automatically paused. 當下一個登入或其他活動發生時,資料庫就會自動繼續。The database is automatically resumed when the next login or other activity occurs. 或者,您也可以停用 autopausing。Alternatively, autopausing can be disabled.

成本Cost

  • 無伺服器資料庫的成本是計算成本和儲存體成本的總和。The cost for a serverless database is the summation of the compute cost and storage cost.
  • 當計算使用量介於設定的最小值和上限之間時,計算成本會以使用的 vCore 和記憶體為基礎。When compute usage is between the min and max limits configured, the compute cost is based on vCore and memory used.
  • 當計算使用量低於設定的最小限制時,計算成本會以所設定的最小虛擬核心和最小記憶體為基礎。When compute usage is below the min limits configured, the compute cost is based on the min vCores and min memory configured.
  • 當資料庫暫停時,計算成本為零,而且只會產生儲存體成本。When the database is paused, the compute cost is zero and only storage costs are incurred.
  • 儲存體成本的決定方式與布建計算層中的相同。The storage cost is determined in the same way as in the provisioned compute tier.

如需更多的成本詳細資料,請參閱帳單For more cost details, see Billing.

案例Scenarios

無伺服器的性價針對採用間歇性、無法預測使用模式的單一資料庫最佳化,這些資料庫可接受在閒置使用期間之後,計算準備有些延遲。Serverless is price-performance optimized for single databases with intermittent, unpredictable usage patterns that can afford some delay in compute warm-up after idle usage periods. 相反地,已布建的計算層級是針對單一資料庫或彈性集區中的多個資料庫優化的性價比,其平均使用量較高,因此無法承受計算準備的任何延遲。In contrast, the provisioned compute tier is price-performance optimized for single databases or multiple databases in elastic pools with higher average usage that cannot afford any delay in compute warm-up.

適合用於無伺服器計算的案例Scenarios well-suited for serverless compute

  • 具有間歇性、無法預測之使用模式的單一資料庫,會隨著一段時間的閒置和較低的平均計算使用量而交錯。Single databases with intermittent, unpredictable usage patterns interspersed with periods of inactivity and lower average compute utilization over time.
  • 已布建計算層中的單一資料庫,經常重新調整,以及偏好將計算重新調整委派給服務的客戶。Single databases in the provisioned compute tier that are frequently rescaled and customers who prefer to delegate compute rescaling to the service.
  • 不使用歷程記錄的新單一資料庫,其中的計算大小很容易或無法在 SQL Database 中部署之前評估。New single databases without usage history where compute sizing is difficult or not possible to estimate prior to deployment in SQL Database.

適合用於佈建計算的案例Scenarios well-suited for provisioned compute

  • 具有更多一般、可預測使用模式的單一資料庫,以及一段時間內的平均計算使用率。Single databases with more regular, predictable usage patterns and higher average compute utilization over time.
  • 無法容忍以下情況造成效能妥協的資料庫:經常修剪記憶體或從暫停狀態自動繼續以致延遲。Databases that cannot tolerate performance trade-offs resulting from more frequent memory trimming or delay in autoresuming from a paused state.
  • 具有間歇性、無法預測使用模式的多個資料庫,可以合併到彈性集區,以獲得更佳的性價比優化。Multiple databases with intermittent, unpredictable usage patterns that can be consolidated into elastic pools for better price-performance optimization.

與佈建計算層級比較Comparison with provisioned compute tier

下表摘要說明無伺服器計算層級與佈建計算層級之間的差異:The following table summarizes distinctions between the serverless compute tier and the provisioned compute tier:

無伺服器計算Serverless compute 佈建計算Provisioned compute
資料庫使用模式Database usage pattern 一段時間內,平均計算使用率較低的間歇性、無法預測的使用量。Intermittent, unpredictable usage with lower average compute utilization over time. 使用一段時間的平均計算使用量較高的一般使用模式,或使用彈性集區的多個資料庫。More regular usage patterns with higher average compute utilization over time, or multiple databases using elastic pools.
效能管理投入量Performance management effort 較低Lower 較高Higher
計算調整Compute scaling 自動Automatic 手動Manual
計算回應性Compute responsiveness 在非使用期間後降低Lower after inactive periods 立即Immediate
計費細微度Billing granularity 每秒Per second 每小時Per hour

購買模型和服務層級Purchasing model and service tier

目前只有虛擬核心購買模型中第 5 代硬體的一般用途層級支援 SQL Database 無伺服器。SQL Database serverless is currently only supported in the General Purpose tier on Generation 5 hardware in the vCore purchasing model.

自動調整規模Autoscaling

調整回應性Scaling responsiveness

一般而言,無伺服器資料庫會在具有足夠容量的電腦上執行,以滿足資源需求,而不會中斷虛擬核心值所設定之限制內所要求的任何計算量。In general, serverless databases are run on a machine with sufficient capacity to satisfy resource demand without interruption for any amount of compute requested within limits set by the max vCores value. 有時候,如果電腦無法在幾分鐘內滿足資源需求,負載平衡就會自動發生。Occasionally, load balancing automatically occurs if the machine is unable to satisfy resource demand within a few minutes. 例如,如果資源需求為4虛擬核心,但只有2個虛擬核心可供使用,則可能需要幾分鐘的時間來進行負載平衡,然後才會提供4個虛擬核心。For example, if the resource demand is 4 vCores, but only 2 vCores are available, then it may take up to a few minutes to load balance before 4 vCores are provided. 捨棄連線後,除了在作業結束時的短暫期間,資料庫都會在負載平衡期間保持線上狀態。The database remains online during load balancing except for a brief period at the end of the operation when connections are dropped.

記憶體管理Memory management

無伺服器資料庫的記憶體回收頻率會比布建的計算資料庫更頻繁。Memory for serverless databases is reclaimed more frequently than for provisioned compute databases. 這種行為對於控制無伺服器的成本很重要,而且可能會影響效能。This behavior is important to control costs in serverless and can impact performance.

快取回收Cache reclamation

不同于已布建的計算資料庫,當 CPU 或快取使用率很低時,會從無伺服器資料庫回收 SQL 快取中的記憶體。Unlike provisioned compute databases, memory from the SQL cache is reclaimed from a serverless database when CPU or cache utilization is low.

  • 當最近使用的快取專案總大小低於一段時間的臨界值時,快取使用率會被視為低。Cache utilization is considered low when the total size of the most recently used cache entries falls below a threshold for a period of time.
  • 觸發快取回收時,目標快取大小會以累加方式縮減為其先前大小的一部分,而且只有在使用方式維持不變時,才會繼續進行回收。When cache reclamation is triggered, the target cache size is reduced incrementally to a fraction of its previous size and reclaiming only continues if usage remains low.
  • 當快取回收發生時,選取 [要收回的快取專案] 的原則,就是與已布建的計算資料庫相同的選取原則(當記憶體壓力偏高時)。When cache reclamation occurs, the policy for selecting cache entries to evict is the same selection policy as for provisioned compute databases when memory pressure is high.
  • 快取大小永遠不會縮減低於 min 虛擬核心所定義的最小記憶體限制,可加以設定。The cache size is never reduced below the min memory limit as defined by min vCores which can be configured.

在無伺服器和已布建的計算資料庫中,如果使用所有可用的記憶體,則可能會收回快取專案。In both serverless and provisioned compute databases, cache entries may be evicted if all available memory is used.

快取序列化Cache hydration

SQL 快取會隨著資料以相同的方式從磁片提取,而且速度與布建的資料庫相同。The SQL cache grows as data is fetched from disk in the same way and with the same speed as for provisioned databases. 當資料庫忙碌時,允許快取不受限制地成長到最大記憶體限制。When the database is busy, the cache is allowed to grow unconstrained up to the max memory limit.

Autopausing 和 autoresumingAutopausing and autoresuming

AutopausingAutopausing

如果下列所有條件都適用于自動暫停延遲的持續時間,則會觸發 Autopausing:Autopausing is triggered if all of the following conditions are true for the duration of the autopause delay:

  • 工作階段數 = 0Number sessions = 0
  • CPU = 0,適用于在使用者集區中執行的使用者工作負載CPU = 0 for user workload running in the user pool

如有需要,會提供選項來停用 autopausing。An option is provided to disable autopausing if desired.

下列功能不支援 autopausing。The following features do not support autopausing. 也就是說,如果使用下列任何一項功能,資料庫會保持線上狀態,而不論資料庫處於非使用狀態的持續時間:That is, if any of the following features are used, then the database remains online regardless of the duration of database inactivity:

  • 異地複寫(主動式異地複寫和自動容錯移轉群組)。Geo-replication (active geo-replication and auto-failover groups).
  • 長期備份保留(LTR)。Long-term backup retention (LTR).
  • SQL 資料同步中使用的同步資料庫。不同于同步資料庫,中樞和成員資料庫支援 autopausing。The sync database used in SQL data sync. Unlike sync databases, hub and member databases support autopausing.
  • 用於彈性作業的作業資料庫。The job database used in elastic jobs.

在部署某些需要線上資料庫的服務更新時,會暫時防止 Autopausing。Autopausing is temporarily prevented during the deployment of some service updates which require the database be online. 在這種情況下,服務更新完成後,就會再次允許 autopausing。In such cases, autopausing becomes allowed again once the service update completes.

AutoresumingAutoresuming

當下列任何一項條件為 true 時,就會觸發 Autoresuming:Autoresuming is triggered if any of the following conditions are true at any time:

功能Feature 自動繼續觸發程序Autoresume trigger
驗證和授權Authentication and authorization 登入Login
威脅偵測Threat detection 啟用/停用資料庫或伺服器層級的威脅偵測設定。Enabling/disabling threat detection settings at the database or server level.
修改資料庫或伺服器層級的威脅偵測設定。Modifying threat detection settings at the database or server level.
資料探索與分類Data discovery and classification 新增、修改、刪除或檢視敏感度標籤Adding, modifying, deleting, or viewing sensitivity labels
稽核Auditing 檢視稽核記錄。Viewing auditing records.
更新或查看稽核原則。Updating or viewing auditing policy.
資料遮罩Data masking 新增、修改、刪除或檢視資料遮罩處理規則Adding, modifying, deleting, or viewing data masking rules
透明資料加密Transparent data encryption 檢視透明資料加密的狀態View state or status of transparent data encryption
查詢 (效能) 資料存放區Query (performance) data store 修改或查看查詢存放區設定Modifying or viewing query store settings
自動微調Autotuning 自動微調建議的應用和驗證,例如自動編製索引Application and verification of autotuning recommendations such as auto-indexing
資料庫複製Database copying 建立資料庫為複本。Create database as copy.
匯出至 BACPAC 檔案。Export to a BACPAC file.
SQL 資料同步SQL data sync 按照可設定的排程執行或定期執行中樞與成員資料庫之間的同步Synchronization between hub and member databases that run on a configurable schedule or are performed manually
修改特定資料庫中繼資料Modifying certain database metadata 正在加入新的資料庫標記。Adding new database tags.
變更最大虛擬核心、最小虛擬核心或自動暫停延遲。Changing max vCores, min vCores, or autopause delay.
SQL Server Management Studio (SSMS)SQL Server Management Studio (SSMS) 使用早于18.1 的 SSMS 版本,並針對伺服器中的任何資料庫開啟新的查詢視窗,將會繼續相同伺服器中任何自動暫停的資料庫。Using SSMS versions earlier than 18.1 and opening a new query window for any database in the server will resume any auto-paused database in the same server. 如果使用 SSMS 18.1 版或更新版本,則不會發生此行為。This behavior does not occur if using SSMS version 18.1 or later.

在部署某些需要線上資料庫的服務更新期間,也會觸發 Autoresuming。Autoresuming is also triggered during the deployment of some service updates which require the database be online.

連線能力Connectivity

如果無伺服器資料庫暫停,第一次登入將會繼續資料庫,並傳回錯誤訊息,指出資料庫無法使用,錯誤碼40613。If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. 資料庫一旦繼續,則必須重試登入來建立連線。Once the database is resumed, the login must be retried to establish connectivity. 具有連線重試邏輯的資料庫用戶端應該不需要修改。Database clients with connection retry logic should not need to be modified.

延遲Latency

自動繼續和自動暫停無伺服器資料庫的延遲通常是從1分鐘到自動繼續,以及1-10 分鐘到自動暫停的順序。The latency to autoresume and autopause a serverless database is generally order of 1 minute to autoresume and 1-10 minutes to autopause.

上架到無伺服器計算層Onboarding into serverless compute tier

建立新的資料庫或將現有的資料庫移到無伺服器計算層級,會遵循與在布建計算層中建立新資料庫相同的模式,並包含下列兩個步驟。Creating a new database or moving an existing database into a serverless compute tier follows the same pattern as creating a new database in provisioned compute tier and involves the following two steps.

  1. 指定服務目標名稱。Specify the service objective name. 服務目標會規定服務層、硬體世代和最大虛擬核心。The service objective prescribes the service tier, hardware generation, and max vCores. 下表顯示服務目標選項:The following table shows the service objective options:

    服務目標名稱Service objective name 服務層級Service tier 硬體世代Hardware generation 最大虛擬核心數Max vCores
    GP_S_Gen5_1GP_S_Gen5_1 一般目的General Purpose Gen5Gen5 11
    GP_S_Gen5_2GP_S_Gen5_2 一般目的General Purpose Gen5Gen5 22
    GP_S_Gen5_4GP_S_Gen5_4 一般目的General Purpose Gen5Gen5 44
  2. (選擇性)指定最小虛擬核心和自動暫停延遲,以變更其預設值。Optionally, specify the min vCores and autopause delay to change their default values. 下表顯示這些參數的可用值。The following table shows the available values for these parameters.

    參數Parameter 值選擇Value choices 預設值Default value
    vCore 數下限Min vCores {0.5, 1, 2, 4} 中未超過最大虛擬核心數的任一項Any of {0.5, 1, 2, 4} not exceeding max vCores 0.5 個虛擬核心0.5 vCores
    自動暫停延遲Autopause delay 最小值:60分鐘(1小時)Minimum: 60 minutes (1 hour)
    最大值:10080 分鐘 (7 天)Maximum: 10080 minutes (7 days)
    增量:60 分鐘Increments: 60 minutes
    停用自動暫停:-1Disable autopause: -1
    60 分鐘60 minutes

注意

目前不支援使用 T-SQL 將現有資料庫移到無伺服器中或變更其計算大小,但可以透過 Azure 入口網站或 PowerShell 進行。Using T-SQL to move an existing database into serverless or change its compute size is not currently supported but can be done via the Azure portal or PowerShell.

在無伺服器計算層中建立新資料庫Create new database in serverless compute tier

使用 Azure 入口網站Use Azure portal

請參閱快速入門:使用 Azure 入口網站在 Azure SQL Database 中建立單一資料庫See Quickstart: Create a single database in Azure SQL Database using the Azure portal.

使用 PowerShellUse PowerShell

下列範例會在無伺服器計算層中建立新的資料庫。The following example creates a new database in the serverless compute tier. 此範例明確指定最小虛擬核心數、最大虛擬核心數和自動暫停延遲。This example explicitly specifies the min vCores, max vCores, and autopause delay.

New-AzSqlDatabase `
  -ResourceGroupName $resourceGroupName `
  -ServerName $serverName `
  -DatabaseName $databaseName `
  -ComputeModel Serverless `
  -Edition GeneralPurpose `
  -ComputeGeneration Gen5 `
  -MinVcore 0.5 `
  -MaxVcore 2 `
  -AutoPauseDelayInMinutes 720

將資料庫從已布建的計算層移到無伺服器計算層Move database from provisioned compute tier into serverless compute tier

使用 PowerShellUse PowerShell

下列範例會將資料庫從已布建的計算層移到無伺服器計算層。The following example moves a database from the provisioned compute tier into the serverless compute tier. 此範例明確指定最小虛擬核心數、最大虛擬核心數和自動暫停延遲。This example explicitly specifies the min vCores, max vCores, and autopause delay.

Set-AzSqlDatabase `
  -ResourceGroupName $resourceGroupName `
  -ServerName $serverName `
  -DatabaseName $databaseName `
  -Edition GeneralPurpose `
  -ComputeModel Serverless `
  -ComputeGeneration Gen5 `
  -MinVcore 1 `
  -MaxVcore 4 `
  -AutoPauseDelayInMinutes 1440

將資料庫從無伺服器計算層移至已布建的計算層Move database from serverless compute tier into provisioned compute tier

無伺服器資料庫可以移到佈建計算層級中,方法如同將佈建計算資料庫移到無伺服器計算層級中。A serverless database can be moved into a provisioned compute tier in the same way as moving a provisioned compute database into a serverless compute tier.

修改無伺服器設定Modifying serverless configuration

最大虛擬核心數Maximum vCores

使用 PowerShellUse PowerShell

修改 max 虛擬核心的執行方式是在 PowerShell MaxVcore中使用引數的 set-azsqldatabase 搭配命令。Modifying the max vCores is performed by using the Set-AzSqlDatabase command in PowerShell using the MaxVcore argument.

最小虛擬核心數Minimum vCores

使用 PowerShellUse PowerShell

修改 min 虛擬核心的執行方式是在 PowerShell MinVcore中使用引數的 set-azsqldatabase 搭配命令。Modifying the min vCores is performed by using the Set-AzSqlDatabase command in PowerShell using the MinVcore argument.

自動暫停延遲Autopause delay

使用 PowerShellUse PowerShell

修改自動暫停延遲是藉由在 PowerShell AutoPauseDelayInMinutes中使用引數的set-azsqldatabase 搭配命令來執行。Modifying the autopause delay is performed by using the Set-AzSqlDatabase command in PowerShell using the AutoPauseDelayInMinutes argument.

監視Monitoring

使用和計費的資源Resources used and billed

無伺服器資料庫的資源是由應用程式套件、SQL 實例和使用者資源集區實體所封裝。The resources of a serverless database are encapsulated by app package, SQL instance, and user resource pool entities.

應用程式套件App package

不論資料庫是在無伺服器或佈建計算層級中,應用程式套件都是資料庫的最外層資源管理界限。The app package is the outer most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. 應用程式套件包含 SQL 執行個體和外部服務,其可一起界定 SQL Database 中資料庫所用的所有使用者和系統資源。The app package contains the SQL instance and external services that together scope all user and system resources used by a database in SQL Database. 外部服務的範例包括 R 和全文檢索搜尋。Examples of external services include R and full-text search. SQL 執行個體通常會支配整個應用程式套件的整體資源使用率。The SQL instance generally dominates the overall resource utilization across the app package.

使用者資源集區User resource pool

不論資料庫是在無伺服器或佈建計算層級中,使用者資源集區都是資料庫的最內層資源管理界限。The user resource pool is the inner most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. 使用者資源集區會針對 DDL 查詢(例如,SELECT、INSERT、UPDATE 和 DELETE)所產生的使用者工作負載,建立其 CPU 和 IO 的範圍。The user resource pool scopes CPU and IO for user workload generated by DDL queries such as CREATE and ALTER and DML queries such as SELECT, INSERT, UPDATE, and DELETE. 這些查詢通常代表應用程式套件內很大的使用率比例。These queries generally represent the most substantial proportion of utilization within the app package.

計量Metrics

下表列出監視應用程式套件的資源使用量和無伺服器資料庫使用者集區的計量:Metrics for monitoring the resource usage of the app package and user pool of a serverless database are listed in the following table:

實體Entity 度量Metric 描述Description 單位Units
應用程式套件App package app_cpu_percentapp_cpu_percent 應用程式所使用的虛擬核心百分比,相對於應用程式所允許的最大虛擬核心數。Percentage of vCores used by the app relative to max vCores allowed for the app. 百分比Percentage
應用程式套件App package app_cpu_billedapp_cpu_billed 在報告期間內針對應用程式計費的計算數量。The amount of compute billed for the app during the reporting period. 在這段期間所支付的金額為此計量與虛擬核心單價的乘積。The amount paid during this period is the product of this metric and the vCore unit price.

彙總一段時間內每秒使用的最大 CPU 與記憶體,即可判斷此計量的值。Values of this metric are determined by aggregating over time the maximum of CPU used and memory used each second. 如果使用的數量小於依照最小虛擬核心數與最小記憶體所設定的最小佈建數量,就會收取最小佈建數量的費用。If the amount used is less than the minimum amount provisioned as set by the min vCores and min memory, then the minimum amount provisioned is billed. 為了比較 CPU 與記憶體以供計費用途,記憶體會依每個虛擬核心 3 GB 重新調整記憶體量,藉此規範成虛擬核心單位。 In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.
虛擬核心秒數vCore seconds
應用程式套件App package app_memory_percentapp_memory_percent 應用程式所使用的記憶體百分比,相對於應用程式所允許的最大記憶體。Percentage of memory used by the app relative to max memory allowed for the app. 百分比Percentage
使用者集區User pool cpu_percentcpu_percent 使用者工作負載所使用的虛擬核心百分比,相對於使用者工作負載所允許的最大虛擬核心數。Percentage of vCores used by user workload relative to max vCores allowed for user workload. 百分比Percentage
使用者集區User pool data_IO_percentdata_IO_percent 使用者工作負載所使用的資料 IOPS 百分比,相對於使用者工作負載所允許的最大資料 IOPS。Percentage of data IOPS used by user workload relative to max data IOPS allowed for user workload. 百分比Percentage
使用者集區User pool log_IO_percentlog_IO_percent 使用者工作負載所使用的記錄 MB/s 百分比,相對於使用者工作負載所允許的最大記錄 MB/s。Percentage of log MB/s used by user workload relative to max log MB/s allowed for user workload. 百分比Percentage
使用者集區User pool workers_percentworkers_percent 使用者工作負載所使用的背景工作角色百分比,相對於使用者工作負載所允許的最大背景工作角色數。Percentage of workers used by user workload relative to max workers allowed for user workload. 百分比Percentage
使用者集區User pool sessions_percentsessions_percent 使用者工作負載所使用的工作階段百分比,相對於使用者工作負載所允許的最大工作階段數。Percentage of sessions used by user workload relative to max sessions allowed for user workload. 百分比Percentage

暫停與繼續狀態Pause and resume status

在 Azure 入口網站中,資料庫狀態會顯示於伺服器的 [概觀] 窗格,其中列出它所包含的資料庫。In the Azure portal, the database status is displayed in the overview pane of the server that lists the databases it contains. 資料庫狀態也會顯示在資料庫的 [概觀] 窗格中。The database status is also displayed in the overview pane for the database.

使用下列 PowerShell 命令來查詢資料庫的暫停和繼續狀態:Using the following PowerShell command to query the pause and resume status of a database:

Get-AzSqlDatabase `
  -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

資源限制Resource limits

如需資源限制,請參閱無伺服器計算層For resource limits, see Serverless compute tier.

帳務Billing

計算數量的計費方式為每秒使用的最大 CPU 與記憶體。The amount of compute billed is the maximum of CPU used and memory used each second. 若使用的 CPU 與使用的記憶體數量小於各自的最小佈建數量,就會收取佈建數量的費用。If the amount of CPU used and memory used is less than the minimum amount provisioned for each, then the provisioned amount is billed. 為了比較 CPU 與記憶體以供計費用途,記憶體會依每個虛擬核心 3 GB 重新調整記憶體量,藉此規範成虛擬核心單位。In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.

  • 計費的資源:CPU 與記憶體Resource billed: CPU and memory
  • 計費金額: vCore 單價 * 最大值(最小虛擬核心,使用的虛擬核心,最小記憶體 gb * 1/3,使用的記憶體 gb * 1/3)Amount billed: vCore unit price * max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • 計費頻率:每秒Billing frequency: Per second

VCore 單位價格是每秒 vCore 的費用。The vCore unit price is the cost per vCore per second. 如需指定區域中的特定單位價格,請參閱 Azure SQL Database 定價頁面Refer to the Azure SQL Database pricing page for specific unit prices in a given region.

計費的計算數量會依下列度量公開:The amount of compute billed is exposed by the following metric:

  • 計量:app_cpu_billed (虛擬核心秒數)Metric: app_cpu_billed (vCore seconds)
  • 定義:最大值 (最小虛擬核心數, 使用的虛擬核心, 最小記憶體 GB * 1/3, 使用的記憶體 GB * 1/3)Definition: max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • 報告頻率:每分鐘Reporting frequency: Per minute

此數量會每秒計算,並彙總超過 1 分鐘。This quantity is calculated each second and aggregated over 1 minute.

請考慮使用1分鐘的 vCore 和4個最大虛擬核心設定的無伺服器資料庫。Consider a serverless database configured with 1 min vCore and 4 max vCores. 這對應到大約 3 GB 的記憶體和 12 GB 記憶體的最大值。This corresponds to around 3 GB min memory and 12-GB max memory. 假設 [自動暫停延遲] 設定為6小時,且資料庫工作負載在24小時期間的前2小時內為作用中,否則為非使用中。Suppose the auto-pause delay is set to 6 hours and the database workload is active during the first 2 hours of a 24-hour period and otherwise inactive.

在此情況下,在前8小時內,資料庫會以計算和儲存體計費。In this case, the database is billed for compute and storage during the first 8 hours. 即使在第二個小時之後,資料庫處於非使用中狀態,仍會根據資料庫上線時所布建的最小計算,在後續的6小時內支付計算費用。Even though the database is inactive starting after the second hour, it is still billed for compute in the subsequent 6 hours based on the minimum compute provisioned while the database is online. 當資料庫暫停時,只有儲存體會在24小時期間的剩餘時間內計費。Only storage is billed during the remainder of the 24-hour period while the database is paused.

更精確地說,在此範例中計算費用的計算方式如下:More precisely, the compute bill in this example is calculated as follows:

時間間隔Time Interval 每秒使用的虛擬核心vCores used each second 每秒使用的 GBGB used each second 計算維度已計費Compute dimension billed 依時間間隔計費的 vCore 秒數vCore seconds billed over time interval
0:00-1:000:00-1:00 44 99 使用的虛擬核心vCores used 4虛擬核心 * 3600 秒 = 14400 vCore 秒數4 vCores * 3600 seconds = 14400 vCore seconds
1:00-2:001:00-2:00 11 1212 使用的記憶體Memory used 12 GB * 1/3 * 3600 秒數 = 14400 vCore 秒數12 GB * 1/3 * 3600 seconds = 14400 vCore seconds
2:00-8:002:00-8:00 00 00 已布建的最小記憶體Min memory provisioned 3 GB * 1/3 * 21600 秒 = 21600 vCore 秒數3 GB * 1/3 * 21600 seconds = 21600 vCore seconds
8:00-24:008:00-24:00 00 00 暫停時不會計費計算No compute billed while paused 0 vCore 秒數0 vCore seconds
過去24小時內計費的總 vCore 秒數Total vCore seconds billed over 24 hours 50400 vCore 秒數50400 vCore seconds

假設計算單價為 $0.000073/虛擬核心/秒。Suppose the compute unit price is $0.000073/vCore/second. 然後,此24小時制費用的計算就是計算單位價格和 vCore 秒數的乘積: $ 0.000073/vCore/second * 50400 vCore 秒數 = $3.68Then the compute billed for this 24-hour period is the product of the compute unit price and vCore seconds billed: $0.000073/vCore/second * 50400 vCore seconds = $3.68

可用區域Available regions

無伺服器計算層級在全球可用,但下欄區域除外:澳大利亞中部、中國東部、中國北部、法國南部、德國中部、德國東北部、印度西部、南韓南部、南非西部、英國北部、英國南部、英國西部和美國中西部。The serverless compute tier is available worldwide except the following regions: Australia Central, China East, China North, France South, Germany Central, Germany Northeast, India West, Korea South, South Africa West, UK North, UK South, UK West, and West Central US.

後續步驟Next steps