Merge pull request MicrosoftDocs#29383 from SvenAelterman/patch-12

Attempted to make a few clarifications

articles/sql-database/sql-database-accelerated-database-recovery.md

@@ -36,11 +36,11 @@ Database recovery in SQL Server follows the [ARIES](https://people.eecs.berkeley
 
 - **Analysis phase**
 
-  Forward scan of the transaction log from the beginning of the last successful checkpoint (or the oldest page LSN) until the end, to determine the state of each transaction at the time SQL Server stopped.
+  Forward scan of the transaction log from the beginning of the last successful checkpoint (or the oldest dirty page LSN) until the end, to determine the state of each transaction at the time SQL Server stopped.
 
 - **Redo phase**
 
-  Forward scan of the transaction log from the oldest uncommitted transaction until the end, to bring the database to the state it was at the time of the crash by redoing all operations.
+  Forward scan of the transaction log from the oldest uncommitted transaction until the end, to bring the database to the state it was at the time of the crash by redoing all committed operations.
 
 - **Undo phase**
 
@@ -50,13 +50,13 @@ Based on this design, the time it takes the SQL database engine to recover from
 
 Also, cancelling/rolling back a large transaction based on this design can also take a long time as it is using the same Undo recovery phase as described above.
 
-In addition, the SQL database engine cannot truncate the transaction log when there are long running transactions because their corresponding log records are needed for the recovery and rollback processes. As a result of this design of the SQL database engine, some customers face the problem that the size of the transaction log grows very large and consumes huge amounts of log space.
+In addition, the SQL database engine cannot truncate the transaction log when there are long running transactions because their corresponding log records are needed for the recovery and rollback processes. As a result of this design of the SQL database engine, some customers face the problem that the size of the transaction log grows very large and consumes huge amounts of drive space.
 
 ## The Accelerated Database Recovery process
 
 ADR addresses the above issues by completely redesigning the SQL database engine recovery process to:
 
-- Make it constant time/instant by avoiding having to scan the log from/to the beginning of the oldest active transaction. With ADR, the transaction log is only processed from the last successful checkpoint (or oldest dirty page Log Sequence Number(LSN). As a result, recovery time is not impacted by long running transactions.
+- Make it constant time/instant by avoiding having to scan the log from/to the beginning of the oldest active transaction. With ADR, the transaction log is only processed from the last successful checkpoint (or oldest dirty page Log Sequence Number (LSN)). As a result, recovery time is not impacted by long running transactions.
 - Minimize the required transaction log space since there is no longer a need to process the log for the whole transaction. As a result, the transaction log can be truncated aggressively as checkpoints and backups occur.
 
 At a high level, ADR achieves fast database recovery by versioning all physical database modifications and only undoing logical operations, which are limited and can be undone almost instantly. Any transaction that was active as of the time of a crash are marked as aborted and, therefore, any versions generated by these transactions can be ignored by concurrent user queries.
@@ -67,16 +67,19 @@ The ADR recovery process has the same three phases as the current recovery proce
 
 - **Analysis phase**
 
-  The process remains the same as today with the addition of reconstructing sLog and copying log records for non-versioned ops.
+  The process remains the same as today with the addition of reconstructing sLog and copying log records for non-versioned operations.
+
 - **Redo** phase
 
   Broken into two phases (P)
   - Phase 1
 
       Redo from sLog (oldest uncommitted transaction up to last checkpoint). Redo is a fast operation as it only needs to process a few records from the sLog.
+
   - Phase 2
 
      Redo from Transaction Log starts from last checkpoint (instead of oldest uncommitted transaction)
+
 - **Undo phase**
 
    The Undo phase with ADR completes almost instantaneously by using sLog to undo non-versioned operations and Persisted Version Store (PVS) with Logical Revert to perform row level version-based Undo.
@@ -91,7 +94,7 @@ The four key components of ADR are:
 
 - **Logical Revert**
 
-  Logical revert is the asynchronous process responsible for performing row level version based Undo - providing instant transaction rollback and undo for all versioned operations.
+  Logical revert is the asynchronous process responsible for performing row-level version-based Undo - providing instant transaction rollback and undo for all versioned operations.
 
   - Keeps track of all aborted transactions
   - Performs rollback using PVS for all user transactions