在 Azure SQL Database 中調整單一資料庫資源Scale single database resources in Azure SQL Database

本文說明如何在佈建的計算層中調整適用於單一資料庫的計算和儲存體資源。This article describes how to scale the compute and storage resources available for a single database in the provisioned compute tier. 或者,無伺服器 (預覽) 計算層次提供計算自動調整和每秒使用的計算的帳單。Alternatively, the serverless (preview) compute tier provides compute auto-scaling and bills per second for compute used.

注意

本文已更新為使用新的 Azure PowerShell Az 模組。This article has been updated to use the new Azure PowerShell Az module. AzureRM 模組在至少 2020 年 12 月之前都還會持續收到錯誤 (Bug) 修正,因此您仍然可以持續使用。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. 若要深入了解新的 Az 模組和 AzureRM 的相容性,請參閱新的 Azure PowerShell Az 模組簡介To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. 如需 Az 模組安裝指示,請參閱安裝 Azure PowerShellFor Az module installation instructions, see Install Azure PowerShell.

重要

PowerShell Azure 资源管理器模块仍受 Azure SQL 数据库的支持,但所有未来的开发都是针对 Az.Sql 模块的。The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. 若要了解这些 cmdlet,请参阅 AzureRM.SqlFor these cmdlets, see AzureRM.Sql. Az 模块和 AzureRm 模块中的命令参数大体上是相同的。The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

變更計算大小 (虛擬核心或 Dtu)Change compute size (vCores or DTUs)

一開始選取的虛擬核心或 Dtu 數目之後, 您可以單一資料庫相應增加或相應減少以動態方式根據實際經驗,使用Azure 入口網站TRANSACT-SQLPowerShell,則Azure CLI,或有REST APIAfter initially picking the number of vCores or DTUs, you can scale a single database up or down dynamically based on actual experience using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.

下列影片示範如何動態變更服務層與計算大小,以提高單一資料庫的可用 DTU。The following video shows dynamically changing the service tier and compute size to increase available DTUs for a single database.

重要

在某些情況下,您可能需要壓縮資料庫來回收未使用的空間。Under some circumstances, you may need to shrink a database to reclaim unused space. 如需詳細資訊,請參閱管理 Azure SQL Database 中的檔案空間For more information, see Manage file space in Azure SQL Database.

變更服務層或重新調整計算大小的影響Impact of changing service tier or rescaling compute size

變更服務層,或計算的單一資料庫的大小主要牽涉的服務,執行下列步驟:Changing the service tier or compute size of a single database mainly involves the service performing the following steps:

  1. 建立新的計算執行個體資料庫Create new compute instance for the database

    新的計算執行個體,資料庫會建立要求的服務層與計算大小。A new compute instance for the database is created with the requested service tier and compute size. 服務層和計算的大小變更的一些組合,資料庫的複本必須建立新的計算執行個體這牽涉到將資料複製,並會強烈影響的整體延遲。For some combinations of service tier and compute size changes, a replica of the database must be created in the new compute instance which involves copying data and can strongly influence the overall latency. 不論如何,在此步驟中,在資料庫保持上線,連接可以繼續以導向至原始的計算執行個體中的資料庫。Regardless, the database remains online during this step, and connections continue to be directed to the database in the original compute instance.

  2. 切換到新的計算執行個體的連線的路由Switch routing of connections to new compute instance

    會卸除現有的連線至原始的計算執行個體中的資料庫。Existing connections to the database in the original compute instance are dropped. 資料庫會建立任何新的連線,新的計算執行個體中。Any new connections are established to the database in the new compute instance. 服務層和計算的大小變更的一些組合,資料庫檔案中斷連結,並在切換期間重新附加上。For some combinations of service tier and compute size changes, database files are detached and reattached during the switch. 不論如何,此參數可能會導致短暫服務中斷時資料庫是無法使用,通常對小於 30 秒,而且通常只有幾秒鐘的時間。Regardless, the switch can result in a brief service interruption when the database is unavailable generally for less than 30 seconds and often for only a few seconds. 如果有長時間執行交易時的連接會中斷執行,此步驟的持續時間可能更久才能復原中止的交易。If there are long running transactions running when connections are dropped, the duration of this step may take longer in order to recover aborted transactions. 加速資料庫復原可以減少從中止長時間執行交易的影響。Accelerated Database Recovery can reduce the impact from aborting long running transactions.

重要

在工作流程中的任何步驟期間,不會遺失任何資料。No data is lost during any step in the workflow.

變更服務層或重新調整計算大小的延遲Latency of changing service tier or rescaling compute size

若要變更服務層,或重新調整單一資料庫或彈性集區的計算大小的延遲是經過參數化,如下所示:The latency to change the service tier or rescale the compute size of a single database or elastic pool is parameterized as follows:

服務層Service tier 基本的單一資料庫,Basic single database,
標準 (S0 S1)Standard (S0-S1)
基本的彈性集區Basic elastic pool,
標準 (S2-S12)Standard (S2-S12),
超大規模Hyperscale,
一般用途的單一資料庫或彈性集區General Purpose single database or elastic pool
進階或業務關鍵的單一資料庫或彈性集區Premium or Business Critical single database or elastic pool
基本的單一資料庫,
標準 (S0 S1)
Basic single database,
Standard (S0-S1)
•  獨立的空間使用的常數時間延遲•  Constant time latency independent of space used
•  一般而言,小於 5 分鐘•  Typically, less than 5 minutes
•  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used
•  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used
基本的彈性集區
標準 (S2-S12)
超大規模
一般用途的單一資料庫或彈性集區
Basic elastic pool,
Standard (S2-S12),
Hyperscale,
General Purpose single database or elastic pool
•  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used
•  獨立的空間使用的常數時間延遲•  Constant time latency independent of space used
•  一般而言,小於 5 分鐘•  Typically, less than 5 minutes
•  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used
進階或業務關鍵的單一資料庫或彈性集區Premium or Business Critical single database or elastic pool •  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used
•  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used
•  使用複製資料的資料庫空間成正比的延遲•  Latency proportional to database space used due to data copying
•  一般而言,小於 1 分鐘,每 GB 的可用空間•  Typically, less than 1 minute per GB of space used

提示

若要監視進行中的作業,請參閱:使用 SQL REST API 管理作業使用 CLI 管理作業使用 T-SQL 監視作業,以及下列兩個 PowerShell 命令:取得 AzSqlDatabaseActivity停止 AzSqlDatabaseActivityTo monitor in-progress operations, see: Manage operations using the SQL REST API, Manage operations using CLI, Monitor operations using T-SQL and these two PowerShell commands: Get-AzSqlDatabaseActivity and Stop-AzSqlDatabaseActivity.

取消服務層變更計算或重新調整作業Cancelling service tier changes or compute rescaling operations

計算可以取消重新調整作業或變更服務層。A service tier change or compute rescaling operation can be canceled.

Azure 入口網站Azure portal

在 [資料庫概觀] 刀鋒視窗中,瀏覽至通知,然後按一下 [] 圖格,指出有進行中的作業:In the database overview blade, navigate to Notifications and click on the tile indicating there is an ongoing operation:

進行中作業

接下來,按一下 [] 按鈕取消此作業Next, click on the button labeled Cancel this operation.

取消進行中作業

PowerShellPowerShell

在 PowerShell 命令提示字元中,設定$ResourceGroupName$ServerName,和$DatabaseName,然後執行下列命令:From a PowerShell command prompt, set the $ResourceGroupName, $ServerName, and $DatabaseName, and then run the following command:

$OperationName = (az sql db op list --resource-group $ResourceGroupName --server $ServerName --database $DatabaseName --query "[?state=='InProgress'].name" --out tsv)
if(-not [string]::IsNullOrEmpty($OperationName))
    {
        (az sql db op cancel --resource-group $ResourceGroupName --server $ServerName --database $DatabaseName --name $OperationName)
        "Operation " + $OperationName + " has been canceled"
    }
    else
    {
        "No service tier change or compute rescaling operation found"
    }

其他考量事項變更服務層或重新調整運算大小Additional considerations when changing service tier or rescaling compute size

  • 如果您要升級到較高服務層或計算大小,除非明確指定較大的大小 (大小上限),否則資料庫大小上限不會增加。If you are upgrading to a higher service tier or compute size, the database max size does not increase unless you explicitly specify a larger size (maxsize).
  • 若要將資料庫降級,資料庫已用的空間必須小於目標服務層和計算大小允許的大小上限。To downgrade a database, the database used space must be smaller than the maximum allowed size of the target service tier and compute size.
  • 進階降級至標準層時,如果發生下列情況,將會產生額外的儲存體成本:(1) 以目標計算大小支援資料庫的大小上限,而且 (2) 大小上限超過目標計算大小的內含儲存體數量。When downgrading from Premium to the Standard tier, an extra storage cost applies if both (1) the max size of the database is supported in the target compute size, and (2) the max size exceeds the included storage amount of the target compute size. 例如,如果大小上限為 500 GB 的 P1 資料庫縮減為 S3,即會產生額外的儲存體成本,因為 S3 可支援 500 GB 的大小上限,而且其內含儲存體數量只有 250 GB。For example, if a P1 database with a max size of 500 GB is downsized to S3, then an extra storage cost applies since S3 supports a max size of 500 GB and its included storage amount is only 250 GB. 因此,額外的儲存體數量為 500 GB – 250 GB = 250 GB。So, the extra storage amount is 500 GB – 250 GB = 250 GB. 如需額外儲存體的價格詳細資訊,請參閱 SQL Database 定價For pricing of extra storage, see SQL Database pricing. 如果實際的使用空間量小於內含的儲存體數量,則可將資料庫大小上限降低至內含量,以避免造成額外成本。If the actual amount of space used is less than the included storage amount, then this extra cost can be avoided by reducing the database max size to the included amount.
  • 升級資料庫時,若已啟用異地複寫,您必須先將其次要資料庫升級為所需的服務層與計算大小,然後再升級主要資料庫 (最佳效能的一般指引)。When upgrading a database with geo-replication enabled, upgrade its secondary databases to the desired service tier and compute size before upgrading the primary database (general guidance for best performance). 升級至不同的版本時,必須先升級次要資料庫。When upgrading to a different, upgrading the secondary database first is required.
  • 當您在啟用異地複寫的情況下將資料庫降級時,必須先將其主要資料庫降級為所需的服務層與計算大小,然後再將次要資料庫降級 (最佳效能的一般指引)。When downgrading a database with geo-replication enabled, downgrade its primary databases to the desired service tier and compute size before downgrading the secondary database (general guidance for best performance). 降級至不同的版本時,必須先降級主要資料庫。When downgrading to a different edition, downgrading the primary database first is required.
  • 還原服務會針對各種服務層提供不同的供應項目。The restore service offerings are different for the various service tiers. 如果降級至基本層,會有較短的備份保留期。If you are downgrading to the Basic tier, there is a lower backup retention period. 請參閱 Azure SQL Database 備份See Azure SQL Database Backups.
  • 完成變更之前,不會將新屬性套用至資料庫。The new properties for the database are not applied until the changes are complete.

計費期間重新調整計算Billing during compute rescaling

您需要支付使用最高服務層資料庫存在的時數 + 在該小時適用的計算大小,不論使用狀況或資料庫是否在作用中少於一小時。You are billed for each hour a database exists using the highest service tier + compute size that applied during that hour, regardless of usage or whether the database was active for less than an hour. 例如,假設您建立了單一資料庫並在五分鐘後刪除,您的帳單就會反映一個資料庫時數的費用。For example, if you create a single database and delete it five minutes later your bill reflects a charge for one database hour.

變更儲存體大小Change storage size

以虛擬核心為基礎的購買模型vCore-based purchasing model

  • 可以使用 1GB 為增量單位,將儲存體佈建到大小上限。Storage can be provisioned up to the max size limit using 1GB increments. 資料儲存體的最小可設定值是 5 GBThe minimum configurable data storage is 5 GB
  • 藉由使用 Azure 入口網站Transact-SQLPowerShellAzure CLIREST API 增加或減少其大小上限,即可佈建單一資料庫的儲存體。Storage for a single database can be provisioned by increasing or decreasing its max size using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.
  • SQL Database 會自動為記錄檔配置 30% 的額外儲存體,為 TempDB 的每個虛擬核心配置 32GB 儲存體,但不超過 384GB。SQL Database automatically allocates 30% of additional storage for the log files and 32GB per vCore for TempDB, but not to exceed 384GB. TempDB 位於所有服務層中的已連結 SSD 上。TempDB is located on an attached SSD in all service tiers.
  • 單一資料庫的儲存體價格為資料儲存體和記錄儲存體數量的總和乘以服務層的儲存體單價。The price of storage for a single database is the sum of data storage and log storage amounts multiplied by the storage unit price of the service tier. TempDB 的成本包含在虛擬核心價格內。The cost of TempDB is included in the vCore price. 如需有關額外儲存體的價格詳細資訊,請參閱 SQL Database 定價For details on the price of extra storage, see SQL Database pricing.

重要

在某些情況下,您可能需要壓縮資料庫來回收未使用的空間。Under some circumstances, you may need to shrink a database to reclaim unused space. 如需詳細資訊,請參閱管理 Azure SQL Database 中的檔案空間For more information, see Manage file space in Azure SQL Database.

以 DTU 為基礎的購買模型DTU-based purchasing model

  • 單一資料庫的 DTU 價格包含一定數量不額外收費的儲存體。The DTU price for a single database includes a certain amount of storage at no additional cost. 佈建超過內含量的額外儲存體會產生額外費用,以 250 GB 為單位最多增加到大小上限 1 TB,超過 1 TB 則以 256 GB 為單位增加。Extra storage beyond the included amount can be provisioned for an additional cost up to the max size limit in increments of 250 GB up to 1 TB, and then in increments of 256 GB beyond 1 TB. 如需了解內含儲存體數量與大小上限,請參閱單一資料庫:儲存體大小與計算大小For included storage amounts and max size limits, see Single database: Storage sizes and compute sizes.
  • 可以透過使用 Azure 入口網站、Transact-SQLPowerShellAzure CLIREST API 增加其大小上限,以佈建單一資料庫的額外儲存體。Extra storage for a single database can be provisioned by increasing its max size using the Azure portal, Transact-SQL, PowerShell, the Azure CLI, or the REST API.
  • 單一資料庫之額外儲存體的價格為額外儲存體數量乘以服務層的額外儲存體單價。The price of extra storage for a single database is the extra storage amount multiplied by the extra storage unit price of the service tier. 如需有關額外儲存體的價格詳細資訊,請參閱 SQL Database 定價For details on the price of extra storage, see SQL Database pricing.

重要

在某些情況下,您可能需要壓縮資料庫來回收未使用的空間。Under some circumstances, you may need to shrink a database to reclaim unused space. 如需詳細資訊,請參閱管理 Azure SQL Database 中的檔案空間For more information, see Manage file space in Azure SQL Database.

P11 和 P15 的限制時最大大小大於 1 TBP11 and P15 constraints when max size greater than 1 TB

所有區域目前均可使用進階層中超過 1 TB 的儲存體,但下列區域除外:中國東部、中國北部、德國中部、德國東北部、美國中西部、美國 DoD 區域和美國政府中部。More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, Germany Northeast, West Central US, US DoD regions, and US Government Central. 在這些區域中,進階層中的儲存空間上限為 1 TB。In these regions, the storage max in the Premium tier is limited to 1 TB. 下列考量與限制適用於大小上限大於 1 TB 的 P11 和 P15 資料庫:The following considerations and limitations apply to P11 and P15 databases with a maximum size greater than 1 TB:

  • 如果 P11 或 P15 資料庫大小上限曾經設定為值大於 1 TB,則它只能還原或複製到 P11 或 P15 資料庫。If the max size for a P11 or P15 database was ever set to a value greater than 1 TB, then can it only be restored or copied to a P11 or P15 database. 接下來,資料庫可以會重新調整為不同的計算大小重新調整作業的時間在配置的空間數量未超過大小上限,新的計算大小的提供。Subsequently, the database can be rescaled to a different compute size provided the amount of space allocated at the time of the rescaling operation does not exceed max size limits of the new compute size.
  • 若是作用中異地複寫案例:For active geo-replication scenarios:
    • 設定異地複寫關聯性:如果 P11 或 P15 為主要資料庫,則次要資料庫也必須是 P11 或 P15;系統會拒絕使用較低的計算大小作為次要資料庫,因為這些資料庫無法支援 1 TB 以上的大小。Setting up a geo-replication relationship: If the primary database is P11 or P15, the secondary(ies) must also be P11 or P15; lower compute size are rejected as secondaries since they are not capable of supporting more than 1 TB.
    • 在異地複寫關聯性中升級主要資料庫:將主要資料庫的大小上限變更為 1 TB 以上會在次要資料庫中觸發相同的變更。Upgrading the primary database in a geo-replication relationship: Changing the maximum size to more than 1 TB on a primary database triggers the same change on the secondary database. 這兩種升級方式都必須成功,在主要資料庫中的變更才會生效。Both upgrades must be successful for the change on the primary to take effect. 適用於大於 1-TB 選項的區域限制。Region limitations for the more than 1-TB option apply. 如果次要資料庫位於不支援大於 1 TB 的區域,就無法升級主要資料庫。If the secondary is in a region that does not support more than 1 TB, the primary is not upgraded.
  • 不支援使用匯入/匯出服務載入具有 1 TB 以上之 P11/P15 資料庫的功能。Using the Import/Export service for loading P11/P15 databases with more than 1 TB is not supported. 使用 SqlPackage.exe 來匯入匯出資料。Use SqlPackage.exe to import and export data.

後續步驟Next steps

如需整體資源限制,請參閱SQL Database 以虛擬核心為基礎的資源限制 - 單一資料庫SQL Database 以 DTU 為基礎的資源限制 - 彈性集區For overall resource limits, see SQL Database vCore-based resource limits - single databases and SQL Database DTU-based resource limits - elastic pools.