| title | description | services | ms.service | ms.subservice | ms.custom | ms.devlang | ms.topic | author | ms.author | ms.reviewer | ms.date |
|---|---|---|---|---|---|---|---|---|---|---|---|
Scale elastic pool resources |
This page describes scaling resources for elastic pools in Azure SQL Database. |
sql-database |
sql-database |
elastic-pools |
sqldbrb=1 |
conceptual |
oslake |
moslake |
carlrab |
3/14/2019 |
This article describes how to scale the compute and storage resources available for elastic pools and pooled databases in Azure SQL Database.
After initially picking the number of vCores or eDTUs, you can scale an elastic pool up or down dynamically based on actual experience using the Azure portal, PowerShell, the Azure CLI, or the REST API.
Changing the service tier or compute size of an elastic pool follows a similar pattern as for single databases and mainly involves the service performing the following steps:
-
Create new compute instance for the elastic pool
A new compute instance for the elastic pool is created with the requested service tier and compute size. For some combinations of service tier and compute size changes, a replica of each database must be created in the new compute instance which involves copying data and can strongly influence the overall latency. Regardless, the databases remain online during this step, and connections continue to be directed to the databases in the original compute instance.
-
Switch routing of connections to new compute instance
Existing connections to the databases in the original compute instance are dropped. Any new connections are established to the databases 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 databases are 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.
Important
No data is lost during any step in the workflow.
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, Standard (S0-S1) |
Basic elastic pool, Standard (S2-S12), Hyperscale, General Purpose single database or elastic pool |
Premium or Business Critical single database or elastic pool |
|---|---|---|---|
| Basic single database, Standard (S0-S1) |
• Constant time latency independent of space used • Typically, less than 5 minutes |
• Latency proportional to database space used due to data copying • Typically, less than 1 minute per GB of space used |
• Latency proportional to database space used due to data copying • Typically, less than 1 minute per GB of space used |
| Basic elastic pool, Standard (S2-S12), Hyperscale, General Purpose single database or elastic pool |
• Latency proportional to database space used due to data copying • Typically, less than 1 minute per GB of space used |
• Constant time latency independent of space used • Typically, less than 5 minutes |
• Latency proportional to database space used due to data copying • 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 • Typically, less than 1 minute per GB of space used |
• Latency proportional to database space used due to data copying • Typically, less than 1 minute per GB of space used |
• Latency proportional to database space used due to data copying • Typically, less than 1 minute per GB of space used |
Note
- In the case of changing the service tier or rescaling compute for an elastic pool, the summation of space used across all databases in the pool should be used to calculate the estimate.
- In the case of moving a database to/from an elastic pool, only the space used by the database impacts the latency, not the space used by the elastic pool.
[!TIP] To 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.
- When downsizing vCores or eDTUs for an elastic pool, the pool used space must be smaller than the maximum allowed size of the target service tier and pool eDTUs.
- When rescaling eDTUs for an elastic pool, an extra storage cost applies if (1) the storage max size of the pool is supported by the target pool, and (2) the storage max size exceeds the included storage amount of the target pool. For example, if a 100 eDTU Standard pool with a max size of 100 GB is downsized to a 50 eDTU Standard pool, then an extra storage cost applies since target pool supports a max size of 100 GB and its included storage amount is only 50 GB. So, the extra storage amount is 100 GB – 50 GB = 50 GB. 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.
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.
Important
Under some circumstances, you may need to shrink a database to reclaim unused space. For more information, see Manage file space in Azure SQL Database.
-
Storage can be provisioned up to the max size limit:
- For storage in the standard or general purpose service tiers, increase or decrease size in 10-GB increments
- For storage in the premium or business critical service tiers, increase or decrease size in 250-GB increments
-
Storage for an elastic pool can be provisioned by increasing or decreasing its max size.
-
The price of storage for an elastic pool is the storage amount multiplied by the storage unit price of the service tier. 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. For more information, see Manage file space in Azure SQL Database.
- The eDTU price for an elastic pool includes a certain amount of storage at no additional cost. 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 Elastic pool: storage sizes and compute sizes.
- Extra storage for an elastic pool can be provisioned by increasing its max size using the Azure portal, PowerShell, the Azure CLI, or the REST API.
- The price of extra storage for an elastic pool is the extra storage amount multiplied by the extra storage unit price of the service tier. 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. For more information, see Manage file space in Azure SQL Database.
For overall resource limits, see SQL Database vCore-based resource limits - elastic pools and SQL Database DTU-based resource limits - elastic pools.