Accelerated Database Recovery in SQL Server 2019

Total: 1 Average: 5

An Overview of Traditional Recovery

As with all relational database systems, SQL Server guarantees the durability of data by implementing crash recovery. Durability in the acronym ACID which refers to the characteristics of transactions in relational databases means that we can be assured that if the database fails suddenly, our data is safe.

SQL Server implements this capability using the transaction log. Changes made by all Data Manipulation Operations in SQL Server are captured in the transaction log before being applied to data files (through the checkpoint process) in case it’s needed to roll back or roll forward.

The three-phase crash recovery process in SQL Server is as follows:

  • Analysis – SQL Server reads the transaction log from the latest checkpoint to the end of the transaction log

  • Redo – SQL Server replays the log from the oldest uncommitted transaction to the end of the log

  • Undo – SQL Server reads the log from the end of the log to the oldest uncommitted transaction and reverts all transactions that were active during the crash

Experienced DBAs would have at some point or the other in their careers had the disheartening experience of waiting helplessly for crash recovery to be completed on a very large database. Transaction ROLLBACK uses a similar mechanism as the crash recovery process. Microsoft has enhanced the recovery process significantly in SQL Server 2019.

Accelerated Database Recovery

Accelerated Database Recovery is a new feature based on versioning that significantly increases the rate of recovery in the case of a ROLLBACK or recovery from a crash.

In SQL Server 2019, three new mechanisms within the SQL Server engine modify the way in which recovery is handled and effectively reduce the time required to perform a rollback/rollforward.

  • Persistent Version Store (PVS) – Captures row versions within the database in question. The Persistent Version Store can be defined in a separate file group for performance or size reasons

  • Logical Revert – Uses the row versions stored in PVS to perform rollback when a rollback is invoked for a particular transaction or when the undo phase of crash recovery is invoked.

  • sLog – This possibly stands for secondary log. It’s an in-memory log stream used to capture operations that cannot be versioned. When ADR is enabled in the database, the sLog is always rebuilt during the analysis phase of crash recovery. During the redo phase, the sLog is used rather than the actual transaction log making the process faster since it sits in memory and contains fewer transactions. The traditional recovery process handles transactions from the last checkpoint. The sLog is also used during the undo phase.

  • Cleaner – Removes unnecessary row versions from the PVS. Microsoft also provides a stored procedure to manually force a cleanup of unnecessary row versions.

Accelerated Database Recovery is Turned OFF by Default

The fact that ADR is turned off in SQL Server 2019 by default might seem surprising to some DBAs given that it appears to be such a great feature. ADR uses versioning in the user database in which it is enabled. This can impact the database size significantly. In addition, you may need to plan for the database growth as well as the possible location of the PVS in order to ensure good performance if ADR is enabled. So it makes sense to deliberately enable this functionality.

The Experiment: Preparatory Phase

We set up an experiment to explore the new feature and see the impact of ADR on the size of the transaction log as well as on the speed of ROLLBACK. In our experiment, we create two identical databases using a single backup set and then we enable ADR only on one of these databases. Listing 2 shows the preparatory stages for the task.


Fig. 1 shows the output of the SQL statement in Listing 2 section 2c. We also captured the size of the database files and the transaction log file usage. (see Fig. 3).

Confirming that ADR is Configured

Fig. 1 Confirm ADR is Configured

Reviewing Database File Sizes

Fig. 2 Review Database Data File Sizes

Checking the Size of Transaction Logs

Fig. 3 Check the Size of Log Used for Both Databases

The Experiment: Execution Phase

Once we have captured the details we need to proceed, we then execute the SQL code from Listings 3 and 4 in stages. The two listings are equivalent, but we are executing them on two identical databases separately. First, we do an INSERT (Listing 3, 3a), then we perform a DELETE (Listing 3, 3b) which we will subsequently roll back. Notice that in both the INSERT and the DELETE, we have encapsulated the operations in transactions. Also, take note that the INSERT is executed 50 times. At each stage of execution, i.e. between 3a, 3b, and 3c, we capture the transaction log usage with the help of the code in Listing 2,2e. This is same for the sections 4a, 4b, and 4c.

Fig. 4 and 5 show us that the SELECT INTO operation took 6 milliseconds more in the TSQLV4_ADR database where we enabled Accelerated Database Recovery. We also see in Fig. 6 that we have greater transaction log usage in the TSQLV4_ADR database. I was particularly surprised at this, so I repeated the experiment several times to ensure I was getting this result consistently.

Inserting Execution Time for TSQLV4_NOADR

Fig. 4 Insert Execution Time for TSQLV4_NOADR

Inserting Execution Time for TSQLV4_ADR

Fig. 5 Insert Execution Time for TSQLV4_ADR

Transaction Log Usage After Inserts

Fig. 6 Transaction Log Usage After Inserts

Fig. 7 and 8 show us that the DELETE operation took considerably more time to be completed in the TSQLV4_ADR database where we enabled Accelerated Database Recovery even though the same number of rows was deleted in both databases. This time around, however, we have greater transaction log usage in the TSQLV4_NOADR database.

Deleting Execution Time for TSQLV4_NOADR

Fig. 7 Delete Execution Time for TSQLV4_NOADR

Deleting Execution Time for TSQLV4_ADR

Fig. 8 Delete Execution Time for TSQLV4_ADR

Transaction Log Usage After Deletes

Fig. 9 Transaction Log Usage After Deletes

By now it was becoming obvious that DML operations take longer in databases with ADR enabled. This partly explains why the feature is off in the first place. Deeply thinking about it, it makes sense since SQL Server must store the row versions in the PVS while an insert, update, or delete operation is running. Whatever amount of time the DML takes, we find that issuing a ROLLBACK with ADR turned ON takes less than 1 millisecond (see Figs. 10 – 13). In some cases, the quick rollback can compensate for the overhead of the DML itself, but not in all cases!

Execution Time for ROLLBACK (After DELETE) on TSQLV4_NOADR

Fig. 10 Execution Time for ROLLBACK (After DELETE) on TSQLV4_NOADR

Execution Time for ROLLBACK (After DELETE) on TSQLV4_ADR

Fig. 11 Execution Time for ROLLBACK (After DELETE) on TSQLV4_ADR

Execution Time for ROLLBACK (After INSERT) on TSQLV4_NOADR

Fig. 12 Execution Time for ROLLBACK (After INSERT) on TSQLV4_NOADR

Execution Time for ROLLBACK (After DELETE) on TSQLV4_ADR

Fig. 13 Execution Time for ROLLBACK (After DELETE) on TSQLV4_ADR


Accelerated Database Recovery is one of the great features released in SQL Server 2019. However, as with all extremely nice things in life, someone has to pay for it. ADR can have a negative performance impact in certain scenarios, so it’s important to evaluate your scenario carefully before implementing ADR in your production database. Microsoft specifically recommends Accelerated Database Recovery for databases supporting workloads with very long-running transactions, excessive transaction log growth, or frequent outages related to a long-running recovery.


  1. Accelerated Database Recovery

  2. How Does Accelerated Database Recovery Work?

  3. Accelerated Database Recovery

Kenneth Igiri

Kenneth Igiri is a Database Administrator with eProcess International S.A., Ecobank Group's Shared Services Centre. Kenneth has over eight years' experience with SQL Server and Oracle databases as well as related technologies. His interests include database performance, HADR, and recently, Cloud.
Also, Kenneth teaches at Children's Church and writes fiction. You can connect with Kenneth via his blog or social network account.
Kenneth Igiri

Latest posts by Kenneth Igiri (see all)