I have received a case where customer wants to know the database scale up operation time. what will happen in the backend when database scale up operation begin in the Azure SQL DB and Azure SQL Managed instance?
https://docs.microsoft.com/en-us/azure/sql-database/sql-database-single-database-scale
As mentioned in the link,
Impact
Changing the service tier or compute size of mainly involves the service performing the following steps:
- Create new compute instance for the databaseA 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.
- Switch routing of connections to new compute instanceExisting 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.
Important
No data is lost during any step in the workflow. 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
The estimated latency to change the service tier, scale the compute size of a single database or elastic pool, move a database in/out of an elastic pool, or move a database between elastic pools 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 |
dditional considerations
- 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.
- 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. 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. So, the extra storage amount is 500 GB – 250 GB = 250 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.
- 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 edition, it is a requirement that the secondary database is upgraded first.
- 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, it is a requirement that the primary database is downgraded first.
- 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. See Azure SQL Database Backups.
- The new properties for the database are not applied until the changes are complete
Azure SQL Database 