Azure SQL Database 無伺服器Azure SQL Database serverless

適用於: Azure SQL Database

無伺服器是 Azure SQL Database 中單一資料庫的計算層,可根據工作負載需求和每秒使用的計算量,自動調整計算規模。Serverless is a compute tier for single databases in Azure SQL Database 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

Azure SQL Database 中單一資料庫的無伺服器計算層是由計算自動調整範圍和自動暫停延遲參數化。The serverless compute tier for single databases in Azure SQL Database is parameterized by a compute autoscaling range and an autopause delay. 這些參數的設定會以資料庫效能體驗和計算成本為圖形。The configuration of these parameters shapes 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

一般而言,無伺服器資料庫會在具有足夠容量的機器上執行,以滿足資源需求,而不會中斷 [max 虛擬核心] 值所設定的限制內所要求的任何計算量。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 active cache utilization is low.

  • 當最近使用的快取專案大小總計低於閾值一段時間時,使用中的快取使用率會被視為低。Active 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.

請注意,當 CPU 使用率偏低時,使用中的快取使用率可能會根據使用模式而維持很高,並防止記憶體回收。Note that when CPU utilization is low, active cache utilization can remain high depending on the usage pattern and prevent memory reclamation. 此外,在進行記憶體回收之前,使用者活動可能會有額外的延遲,因為定期背景進程會回應先前的使用者活動。Also, there can be additional delay after user activity stops before memory reclamation occurs due to periodic background processes responding to prior user activity. 例如,「刪除作業」和「QDS 清除工作」會產生標示為刪除的准刪除記錄,但在准刪除清除程式執行時,可能需要將資料頁面讀入快取中,否則不會實際刪除。For example, delete operations and QDS cleanup tasks generate ghost records that are marked for deletion, but are not physically deleted until the ghost cleanup process runs which can involve reading data pages into cache.

快取序列化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, but do support auto-scaling. 如果使用下列任何一項功能,則應該停用 autopausing,而且不論資料庫閒置的持續時間,資料庫都將保持上線狀態:If any of the following features are used, then autopausing should be disabled and the database will remain 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.
  • DNS 別名DNS aliasing
  • 彈性工作中使用的工作資料庫 (預覽) 。The job database used in Elastic Jobs (preview).

在部署需要資料庫上線的某些服務更新期間,會暫時防止 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

當下列任何條件成立時,就會觸發 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
弱點評估Vulnerability assessment 臨機操作掃描和定期掃描(如果已啟用)Ad hoc scans and periodic scans if enabled
查詢 (效能) 資料存放區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.

執行上述任何作業的監視、管理或其他解決方案將會觸發自動繼續。Monitoring, management, or other solutions performing any of the operations listed above will trigger auto-resuming.

在部署某些需要線上資料庫的服務更新期間,也會觸發 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.

LatencyLatency

自動繼續和自動暫停無伺服器資料庫的延遲通常是從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.

客戶管理的透明資料加密 (BYOK) Customer managed transparent data encryption (BYOK)

如果使用 客戶管理的透明資料加密 (BYOK) 而且當刪除或撤銷金鑰時,無伺服器資料庫會自動暫停,則資料庫會保持在自動暫停狀態。If using customer managed transparent data encryption (BYOK) and the serverless database is auto-paused when key deletion or revocation occurs, then the database remains in the auto-paused state. 在此情況下,在資料庫下次繼續之後,資料庫會在大約10分鐘內變成無法存取。In this case, after the database is next resumed, the database becomes inaccessible within approximately 10 minutes. 一旦資料庫變成無法存取,復原程式就會與布建的計算資料庫相同。Once the database becomes inaccessible, the recovery process is the same as for provisioned compute databases. 如果在刪除或撤銷金鑰時,無伺服器資料庫在線上,則資料庫也會在大約10分鐘內變成無法存取,與布建的計算資料庫相同。If the serverless database is online when key deletion or revocation occurs, then the database also becomes inaccessible within approximately 10 minutes in the same way as with provisioned compute databases.

上架到無伺服器計算層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. 服務目標會規定服務層級、硬體世代和最大虛擬核心。The service objective prescribes the service tier, hardware generation, and max vCores. 如需服務目標選項,請參閱 無伺服器資源限制For service objective options, see serverless resource limits

  2. (選擇性)指定 min 虛擬核心和自動暫停 delay 來變更其預設值。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
    最小虛擬核心Min vCores 取決於設定的最大虛擬核心-請參閱 資源限制Depends on max vCores configured - see resource limits. 0.5 個虛擬核心0.5 vCores
    自動暫停延遲Autopause delay 最小值:60分鐘 (1 小時) Minimum: 60 minutes (1 hour)
    最大值:10080分鐘 (7 天) Maximum: 10080 minutes (7 days)
    增量:10分鐘Increments: 10 minutes
    停用自動暫停:-1Disable autopause: -1
    60 Minuten60 minutes

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

下列範例會在無伺服器計算層中建立新的資料庫。The following examples create a new database in the serverless compute tier.

使用 Azure 入口網站Use the Azure portal

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

使用 PowerShellUse PowerShell

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

使用 Azure CLIUse the Azure CLI

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose -f Gen5 -min-capacity 0.5 -c 2 --compute-model Serverless --auto-pause-delay 720

使用 Transact-sql (T-sql) Use Transact-SQL (T-SQL)

使用 T-sql 時,會針對 min 虛擬核心和自動暫停 delay 套用預設值。When using T-SQL, default values are applied for the min vcores and autopause delay.

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

如需詳細資訊,請參閱 建立資料庫For details, see CREATE DATABASE.

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

下列範例會將資料庫從已布建的計算層移至無伺服器計算層。The following examples move a database from the provisioned compute tier into the serverless compute tier.

使用 PowerShellUse PowerShell

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

使用 Azure CLIUse the Azure CLI

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --min-capacity 1 --capacity 4 --family Gen5 --compute-model Serverless --auto-pause-delay 1440

使用 Transact-sql (T-sql) Use Transact-SQL (T-SQL)

使用 T-sql 時,會針對 min 虛擬核心和自動暫停 delay 套用預設值。When using T-SQL, default values are applied for the min vcores and autopause delay.

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

如需詳細資訊,請參閱 ALTER DATABASEFor details, see ALTER DATABASE.

將資料庫從無伺服器計算層移至布建的計算層Move a database from the serverless compute tier into the 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

使用 PowerShellUse PowerShell

使用Set-AzSqlDatabase MaxVcoreMinVcore 和引數,在 PowerShell 中使用 >set-azsqldatabase 命令來修改最大或最小虛擬核心,以及自動暫停延遲 AutoPauseDelayInMinutesModifying the maximum or minimum vCores, and autopause delay, is performed by using the Set-AzSqlDatabase command in PowerShell using the MaxVcore, MinVcore, and AutoPauseDelayInMinutes arguments.

使用 Azure CLIUse the Azure CLI

使用az sql db update capacitymin-capacity 和引數,即可在 Azure CLI 中使用 az sql db update 命令來修改最大或最小虛擬核心,以及自動暫停延遲 auto-pause-delayModifying the maximum or minimum vCores, and autopause delay, is performed by using the az sql db update command in Azure CLI using the capacity, min-capacity, and auto-pause-delay arguments.

監視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.

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

使用 PowerShellUse PowerShell

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

使用 Azure CLIUse the Azure CLI

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

資源限制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 unit price * max (min 虛擬核心、虛擬核心 used、MIN memory GB * 1/3、memory gb used * 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 unit price 是每個 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.

最小計算帳單Minimum compute bill

如果無伺服器資料庫已暫停,則計算帳單為零。If a serverless database is paused, then the compute bill is zero. 如果無伺服器資料庫未暫停,則最小計算帳單的最小值是根據最大 (最小值虛擬核心、最小記憶體 GB * 1/3) 的虛擬核心量。If a serverless database is not paused, then the minimum compute bill is no less than the amount of vCores based on max (min vCores, min memory GB * 1/3).

範例:Examples:

  • 假設無伺服器資料庫未暫停,並設定最多8個虛擬核心和1分鐘的 vCore,對應至 3.0 GB 的最小記憶體。Suppose a serverless database is not paused and configured with 8 max vCores and 1 min vCore corresponding to 3.0 GB min memory. 然後,最小計算費用是根據 max (1 vCore、3.0 GB * 1 vCore/3 GB) = 1 vCore。Then the minimum compute bill is based on max (1 vCore, 3.0 GB * 1 vCore / 3 GB) = 1 vCore.
  • 假設無伺服器資料庫未暫停,並設定 4 max 虛擬核心和 0.5 min 虛擬核心,對應至 2.1 GB 的最小記憶體。Suppose a serverless database is not paused and configured with 4 max vCores and 0.5 min vCores corresponding to 2.1 GB min memory. 然後,最小計算費用是根據 max (0.5 虛擬核心、2.1 GB * 1 vCore/3 GB) = 0.7 虛擬核心。Then the minimum compute bill is based on max (0.5 vCores, 2.1 GB * 1 vCore / 3 GB) = 0.7 vCores.

適用于無伺服器的 Azure SQL Database 定價計算機 ,可用來根據設定的最大和最小虛擬核心數,判斷可設定的最小記憶體。The Azure SQL Database pricing calculator for serverless can be used to determine the min memory configurable based on the number of max and min vCores configured. 作為規則,如果設定的最小虛擬核心大於0.5 虛擬核心,則最小計算帳單與設定的最小記憶體無關,而且只會根據設定的最小虛擬核心數。As a rule, if the min vCores configured is greater than 0.5 vCores, then the minimum compute bill is independent of the min memory configured and based only on the number of min vCores configured.

範例案例Example scenario

請考慮設定為1分鐘 vCore 和 4 max 虛擬核心的無伺服器資料庫。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
總 vCore 秒數(以24小時計費)Total vCore seconds billed over 24 hours 50400 vCore 的秒數50400 vCore seconds

假設計算單位價格是 $ 0.000145/vCore/second。Suppose the compute unit price is $0.000145/vCore/second. 然後,此24小時期間的計算費用是計算單位價格和 vCore 秒數的乘積: $ 0.000145/vCore/second * 50400 vCore 秒 ~ $7.31Then the compute billed for this 24-hour period is the product of the compute unit price and vCore seconds billed: $0.000145/vCore/second * 50400 vCore seconds ~ $7.31

Azure Hybrid Benefit 和保留容量Azure Hybrid Benefit and reserved capacity

Azure Hybrid Benefit (AHB) 與保留容量折扣並不適用于無伺服器計算層級。Azure Hybrid Benefit (AHB) and reserved capacity discounts do not apply to the serverless compute tier.

可用區域Available regions

無伺服器計算層級可于全球使用,但下欄區域除外:中國東部、中國北部、德國中部、德國東北部和 US Gov 中部 (愛荷華州) 。The serverless compute tier is available worldwide except the following regions: China East, China North, Germany Central, Germany Northeast, and US Gov Central (Iowa).

後續步驟Next steps