HowToFixMe
Azure SQL

The accelerated database recovery process

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

At a glance
Product familyAzure SQL
Document sourceAzure SQL
Guide typeHands-on Reference
Skill levelIntermediate to advanced
Time20 - 75 minutes depending on tenant scale

Accelerated Database Recovery (ADR) is on by default in Azure SQL. Most engineers do not know it exists, and that is fine — the whole point is that recovery just works faster than the SQL Server they remember. But when you are debugging a long rollback or a slow restart, knowing how ADR thinks about the transaction log helps.

ADR persists row versions in a separate filegroup called Persisted Version Store (PVS). Rollback no longer walks the transaction log from current to original — it just reads the prior row version from PVS. The rollback that used to take 40 minutes now takes 4 seconds.

Reference content and what it actually means

The Microsoft Learn page for The accelerated database recovery process treats this as a reference doc. That is fine for "what does this mean." It is not enough for "should I enable this on my tenant tomorrow." The framing below is the one I use when I am the engineer on the hook.

Three things drive how this behaves in production: the Azure SQL service tier you are on, the region your database lives in, and the identity model your application uses. Skip any of them and you will get surprising results.

Service tiers and what changes

Azure SQL ships in four major tiers: General Purpose, Business Critical, Hyperscale (Database), and the Managed Instance equivalents. Each tier has different memory budgets, different storage backends, different replica topologies. A feature that works the same way across tiers in the docs may behave differently under load because of those underlying differences.

-- Check the current tier and SKU of an Azure SQL database
SELECT
  DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') AS sku,
  DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS tier,
  DATABASEPROPERTYEX(DB_NAME(), 'MaxSizeInBytes') / (1024.0 * 1024 * 1024) AS max_gb;

Run that on the database you are about to change before you change anything. The output tells you which docs page actually applies. Hyperscale features in particular do not apply to General Purpose, and vice versa.

Authentication options that work

You have four practical auth modes on Azure SQL. SQL authentication (username + password). Microsoft Entra password. Microsoft Entra integrated. Microsoft Entra managed identity. For anything that ships to production, managed identity is the right answer. Passwords leak. Managed identity does not.

-- Add an Entra service principal as an Azure SQL contained user
CREATE USER [my-app-prod] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-app-prod];
ALTER ROLE db_datawriter ADD MEMBER [my-app-prod];

If you are calling from App Service, Functions, or Container Apps, enable managed identity on the caller, run the two lines above against your database, and you are done. No keys, no rotation, no leaked secrets in App Configuration.

Regions and data residency

Azure SQL runs in 60+ regions. For Indian regulated workloads, banks under the RBI IT framework, NBFCs under the NBFC framework, healthcare under the relevant DISHA guidelines: pin to Central India or South India. Cross-region geo-replication for DR can stay within India (Central India ⇄ South India) and stays compliant.

How to apply this in practice

  1. Confirm the SKU and tier of the database you are about to change. SELECT DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') is the quickest path. The applicable docs and behaviour vary by tier.
  2. Run the change in a dev or staging database first. Capture the before-state with sys.dm_db_index_usage_stats or whatever DMV is relevant to the change. Apply the change. Capture the after-state. Compare.
  3. For any production-bound change, raise a CAB record (or whatever your team's change process calls it). Include the exact T-SQL or Azure CLI commands, the rollback steps, and the verification queries.
  4. Apply during a low-traffic window. Most Indian SaaS workloads have a window between 02:00 and 05:00 IST when traffic is at 10-20% of peak. That is your change window.
  5. Wire up Azure Monitor diagnostic settings if you have not already. Send SQLInsights, AutomaticTuning, and QueryStoreRuntimeStatistics to a Log Analytics workspace. One alert: 5xx response rate over 2% for 5 minutes. That alert has saved me twice this year.
  6. Run a smoke test after the change. Run a representative query, time it, compare against a baseline you captured before. Sign off only if the numbers match what you expected.

I have seen teams skip step 5, the smoke test. every time there is schedule pressure. Skipping it costs more than the smoke test does, every single time. Twenty minutes of validation. Pays back the first time something silently regresses.

Caveats and what to double-check

Troubleshooting the failures I keep seeing

Three failure modes account for most of the Azure SQL incidents I have triaged in the last year. Knowing them in advance saves hours.

Login failed for the managed identity

You enabled managed identity on the caller. You ran CREATE USER FROM EXTERNAL PROVIDER on the database. The first call still fails with "Login failed for user '<token-identified principal>'". The cause is usually one of three: the managed identity name has a typo, the database does not have the contained user role assignment, or the token cache on the caller is stale and the next request will succeed.

-- Verify the Entra user exists on the database
SELECT name, type_desc, principal_id
FROM sys.database_principals
WHERE type IN ('E', 'X');

If the user appears in that result, the issue is on the caller side. Restart the App Service or Function. Tokens cache for an hour and a recently revoked token will fail until cache expiry.

Transient connection failures under load

Azure SQL throws transient errors: error numbers 4060, 40197, 40501, 40613, 49918, 49919, 49920, when the service is throttling, failing over, or load-balancing. Your code must catch these specifically and retry with exponential backoff. The .NET SqlClient v3+ does this automatically if you set ConnectRetryCount=3 and ConnectRetryInterval=10 in the connection string. The Python pyodbc driver does not. you write the retry loop yourself.

# Python pattern that handles Azure SQL transients
import pyodbc, time
TRANSIENT = {4060, 40197, 40501, 40613, 49918, 49919, 49920}
def query_with_retry(conn_str, sql, max_retries=5):
    for attempt in range(max_retries):
        try:
            with pyodbc.connect(conn_str) as cn:
                return cn.execute(sql).fetchall()
        except pyodbc.OperationalError as e:
            code = int(str(e).split('(')[1].split(',')[0]) if '(' in str(e) else 0
            if code in TRANSIENT and attempt < max_retries - 1:
                time.sleep(2 ** attempt)
                continue
            raise

Query suddenly slow after maintenance window

Azure SQL applies platform maintenance during your configured window. Sometimes that maintenance includes a server move, which clears the plan cache. The first request after the move recompiles every query, for a busy OLTP workload that is a brief spike in CPU and a brief drop in throughput. If you see a consistent slowdown lasting longer than 60 seconds, check Query Store for plan regressions and force the prior good plan if needed.

Last month I had a Mumbai customer hit this exact issue after a Saturday-night maintenance window. The fix was identifying the regressed plan in Query Store and forcing the prior plan with sp_query_store_force_plan. Total time to recover: 12 minutes.

Cost notes

Azure SQL pricing has three big levers. The compute tier (DTU or vCore), the storage allocation, and the redundancy choice. The compute tier dominates spend for almost every workload. Storage is small. Redundancy adds 25-100% depending on whether you pick local-redundant, zone-redundant, or geo-redundant.

A typical mid-market production database: General Purpose vCore-4, 100 GB storage, zone-redundant, runs about ₹65,000 per month at pay-as-you-go. With a 3-year reservation: about ₹38,000 per month. With Azure Hybrid Benefit applied on top: about ₹27,000 per month. The same database on the equivalent on-prem licence + hardware refresh: hard to compare cleanly because you have to factor depreciation, DBA cost, datacentre overhead.

For a Hyperscale database serving 8 million reads a day across two read replicas: about ₹1.4 lakh per month. The equivalent SQL Server Enterprise on-prem with two AG replicas plus DR site: roughly ₹2.1 lakh per month amortised over 5 years, plus DBA cost.

Rollback plan

If the change you just made is causing user-visible regressions, you have three rollback paths. Roll back the specific T-SQL change you applied (fastest. run the inverse statement). Restore the database to a point in time before the change (medium, minutes to hours depending on database size). Geo-failover to the secondary if your primary region is offline (slowest of the three but covers regional outages).

-- Point-in-time restore to 30 minutes before the change
az sql db restore \
  --resource-group rg-prod-sql \
  --server srv-prod-india \
  --name mydb-restored \
  --dest-name mydb-restored-pre-change \
  --time "2026-06-04T14:30:00Z"

I always capture the exact UTC timestamp of the change in my CAB record. When rollback is on the table, those four characters of precision save twenty minutes of guessing. The restore creates a new database alongside the original: you then swap connection strings, or rename databases, depending on your cutover tolerance.

FAQ

Where does this the accelerated database recovery process content come from?
I cross-checked it against the official Microsoft Learn page for Azure SQL, reformatted the structure for engineers who scan rather than read, and added the verify + rollback notes I wish someone had given me when I first shipped this on a customer tenant. The "Last verified" stamp at the top tells you when it was last reconciled with Microsoft's version.
How often is this reference updated?
Quarterly minimum, plus an out-of-band refresh whenever Microsoft pushes a breaking change. Azure SQL docs move fast, I once watched a feature go from preview to GA between Tuesday and Friday. If you spot drift between this page and the canonical Microsoft Learn source, the Microsoft page wins. Drop me a note and I will re-verify.
Can I use this for production planning?
Use it as your first read, not your only read. For production, pair it with your tenant's specific SKU and tier, the region you have picked, your compliance bracket (GDPR / HIPAA / RBI IT Framework / DISHA), and Microsoft's pricing calculator on the day you sign the PO. Thirty minutes of architecture review with those inputs beats three hours of search through PDFs.
Why is this reference free?
HowToFixMe runs on display ads. No paywall, no email gate, no "sign up to read more" pattern. I built this because I lost two evenings last month digging through outdated Microsoft PDF exports for a customer migration. that pain should not be a tax on every engineer who comes after me.
Where can I read the original Microsoft source?
Search "The accelerated database recovery process" on learn.microsoft.com, Microsoft restructures URL paths every few quarters but the heading text usually stays stable, so a verbatim search is the most reliable path to the live page.

References

Related guides worth a look while you sort this one out: