Microsoft's October 16 Azure Database Support guidance explains why apparently similar Azure SQL Database scale operations can finish at different times. A change can involve preparing new compute, copying data for applicable configurations, and switching connections, rather than simply changing a CPU allocation. Microsoft's scaling investigation.
For an on-call engineer, the useful update is a better way to interpret the waiting period. Monitor the operation's state and the application's behavior instead of estimating a finish time from another database's previous change.
Read the Percentage in Its Documented Context
For sys.dm_operation_status, Microsoft documents 0, 50, and 100 as not started, in progress, and complete. Restore operations can expose intermediate values. For an ordinary scale operation, 50 should not become an estimate that half the time remains. DMV reference.
My recommendation is to communicate the observed state, elapsed time, and next investigation step separately. If no evidence supports an ETA, say that plainly.
Keep the measurement source attached to every progress value. A field from a different API or operation type should not inherit the DMV's interpretation without checking its own documentation.
Capture the Operation While It Is Available
The reference places this DMV in the server's master database, available to the server-level principal login, and describes approximately one hour of retention. Have an already-authorized DBA collect the evidence; do not broaden access merely to populate a status display. Access and retention.
This read-only example limits the result to recent operations for one database. Replace the sample name before use:
SELECT TOP (20)
session_activity_id,
operation,
state_desc,
percent_complete,
start_time,
last_modify_time,
error_code,
error_desc
FROM sys.dm_operation_status
WHERE major_resource_id = N'your-database'
ORDER BY start_time DESC;Retain the result with the approved change record and its collection time. Treat an unchanged observation as a reason to investigate, not automatic proof that the operation is stuck.
Separate Waiting from Failure
The DMV defines PENDING as waiting for resource or quota availability and exposes error details for failed operations. Operation states.
I would keep the operation identifier, state, current and requested configuration, and relevant workload window together. Confirm the target database and change request before comparing results from different tools.
When an operation fails, preserve the returned error rather than immediately submitting the same request again. When it remains in progress, follow the team's escalation criteria with the evidence already captured.
Cancellation should be a deliberate change decision, not a reaction to an unhelpful percentage display.
Keep Application Recovery in the Check
Microsoft's support article notes that connections transition during scaling and recommends transient-error handling. It also highlights long-running transactions as relevant to the switchover. Availability considerations.
Before a planned change, I would identify the application owner and agree on a small set of health checks. Watch successful business operations, connection failures, and recovery behavior during the window.
Afterward, confirm both the requested service configuration and application acceptance. A completed control-plane change and a healthy user workflow are related but different results.
For the next maintenance window, retain what this run established without treating its duration as a platform guarantee.
Practical Cloud Engineer Takeaway
Interpret progress using the documentation for the specific operation and source.
Capture the operation record before short-lived diagnostic data disappears.
Distinguish pending, in-progress, completed, and failed outcomes.
Escalate or cancel through an explicit decision with supporting evidence.
Confirm application recovery as well as the final database configuration.
Who Should Care?
Azure SQL administrators, application SREs, and platform teams planning compute changes or explaining a long-running scale request.
Bottom Line
The latest guidance makes scaling a more observable investigation. Use state, configuration, and application evidence to explain what is happening. A percentage without its semantics is not a completion forecast.
The query is illustrative and was not executed against a database for this article. No Azure SQL configuration was changed.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments