Overview:
We sometimes see customers cannot move their SQL database from provisioned compute tier to serverless while the scaling operation fails with error signature like:
Failed to scale from General Purpose: Gen5, 2 vCores, 32 GB storage, zone redundant disabled to General Purpose: Serverless, Gen5, 2 vCores, 32 GB storage, zone redundant disabled for database: <database-name>.
Error code: .
Error message: An unexpected error occured while processing the request. Tracking ID: 'xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx'
Resolution:
In the beginning, you can switch to serverless compute tier only under the vCore model which provides a wide range of configuration controls and offers Hyperscale/Serverless to automatically scale your database based on your workload needs.
When the scaling operation is failing with aforementioned error, this most likely due to a serverless limitation. For instance, enabling auto-pause for a serverless database is not supported if long-term retention (LTR backups) or geo-replication is enabled.
The following features do not support auto-pausing, but do support auto-scaling:
- Geo-replication (active geo-replication and auto-failover groups).
- Long-term backup retention (LTR).
- The sync database used in SQL Data Sync. Unlike sync databases, hub and member databases support auto-pausing.
- DNS alias created for the logical server containing a serverless database.
- Elastic Jobs, when the job database is a serverless database. Databases targeted by elastic jobs support auto-pausing, and will be resumed by job connections.
In case any of these features are in-use, then auto-pausing must be disabled and the database will remain online regardless of the duration of database inactivity.
For more information regarding Serverless, you can refer to Azure SQL DB documentation: Serverless compute tier - Azure SQL Database | Microsoft Docs
I hope you find this article helpful. If you have any feedback please do not hesitate to provide it in the comment section below.
Ahmed S. Mazrouh
