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

本文說明如何在布建的計算層級調整 Azure SQL Database 的計算和儲存體資源。This article describes how to scale the compute and storage resources available for an Azure SQL Database in the provisioned compute tier. 或者,無伺服器計算層會為使用的計算提供計算自動調整和每秒計費。Alternatively, the serverless compute tier provides compute auto-scaling and bills per second for compute used.

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

一開始挑選虛擬核心或 Dtu 數之後,您可以根據使用Azure 入口網站transact-sqlPowerShellAzure CLIREST API的實際經驗,以動態方式相應增加或相應減少單一資料庫。After 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 mainly involves the service performing the following steps:

  1. 為資料庫建立新的計算實例Create new compute instance for the database

    使用要求的服務層級和計算大小建立新的計算實例。A new compute instance 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. 無論如何,在資料庫無法使用時,此參數可能會導致短暫的服務中斷,通常只有幾秒鐘的時間。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. 請確定您已在服務層級變更時,使用 Azure SQL Database 的應用程式和元件中,執行了一些重試邏輯Make sure that you have implemented some retry logic in the applications and components that are using Azure SQL Database while the service tier is changed.

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

變更服務層級或重新調整單一資料庫或彈性集區之計算大小的預估延遲會參數化,如下所示:The estimated 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 或 Business Critical 單一資料庫或彈性集區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
•  通常是每 GB 使用的空間少於1分鐘•  Typically, less than 1 minute per GB of space used
• 與由於資料複製而使用的資料庫空間成正比  延遲•  Latency proportional to database space used due to data copying
•  通常是每 GB 使用的空間少於1分鐘•  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
•  通常是每 GB 使用的空間少於1分鐘•  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
•  通常是每 GB 使用的空間少於1分鐘•  Typically, less than 1 minute per GB of space used
Premium 或 Business Critical 單一資料庫或彈性集區Premium or Business Critical single database or elastic pool • 與由於資料複製而使用的資料庫空間成正比  延遲•  Latency proportional to database space used due to data copying
•  通常是每 GB 使用的空間少於1分鐘•  Typically, less than 1 minute per GB of space used
• 與由於資料複製而使用的資料庫空間成正比  延遲•  Latency proportional to database space used due to data copying
•  通常是每 GB 使用的空間少於1分鐘•  Typically, less than 1 minute per GB of space used
• 與由於資料複製而使用的資料庫空間成正比  延遲•  Latency proportional to database space used due to data copying
•  通常是每 GB 使用的空間少於1分鐘•  Typically, less than 1 minute per GB of space used

提示

若要監視進行中的作業,請參閱:使用 SQL REST API 管理作業使用 CLI 管理作業、使用 t-sql 監視作業和這兩個 PowerShell 命令: get-azsqldatabaseactivityGet-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 支援的大小上限為 1 TB,而其內含的儲存體數量只有 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 1 TB 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.

當大小上限大於 1 TB 時的 P11 和 P15 條件約束P11 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.