在 Azure SQL 数据库中缩放单一数据库资源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.

Note

本文进行了更新,以便使用新的 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.

Important

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.

更改计算大小(vCore 或 DTU)Change compute size (vCores or DTUs)

最初选择 vCore 或 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.

Important

在某些情况下,可能需要收缩数据库来回收未使用的空间。Under some circumstances, you may need to shrink a database to reclaim unused space. 有关详细信息,请参阅管理 Azure SQL 数据库中的文件空间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.

Important

执行工作流中的任何步骤期间都不会丢失数据。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
•  对于每 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 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

Tip

若要监视正在进行的操作,请参阅:使用 SQL REST API 管理操作使用 CLI 管理操作使用 T-SQL 监视操作及以下两个 PowerShell 命令:Get-AzSqlDatabaseActivityStop-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 数据库定价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 数据库备份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 的购买模型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 数据库会自动为日志文件额外分配 30% 的存储,并为 TempDB 的每个 vCore 分配 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. vCore 价格已包括 TempDB 费用。The cost of TempDB is included in the vCore price. 有关额外存储价格的详细信息,请参阅 SQL 数据库定价For details on the price of extra storage, see SQL Database pricing.

Important

在某些情况下,可能需要收缩数据库来回收未使用的空间。Under some circumstances, you may need to shrink a database to reclaim unused space. 有关详细信息,请参阅管理 Azure SQL 数据库中的文件空间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. 超出附送的量后,可花费额外的费用预配额外的存储,但不能超过存储上限,不超过 1 TB 时,以 250 GB 为增量进行预配,超出 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 数据库定价For details on the price of extra storage, see SQL Database pricing.

Important

在某些情况下,可能需要收缩数据库来回收未使用的空间。Under some circumstances, you may need to shrink a database to reclaim unused space. 有关详细信息,请参阅管理 Azure SQL 数据库中的文件空间For more information, see Manage file space in Azure SQL Database.

后续步骤Next steps

有关总体资源限制,请参阅 SQL 数据库基于 vCore 的资源限制 - 单一数据库SQL 数据库基于 DTU 的资源限制 - 弹性池For overall resource limits, see SQL Database vCore-based resource limits - single databases and SQL Database DTU-based resource limits - elastic pools.