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'
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.