Update ADR best practices

Author: dimitri-furman

docs/database-engine/configure-windows/adr-preallocation-factor-server-configuration-option.md

@@ -4,30 +4,31 @@ description: "Explains the SQL Server instance configuration setting for ADR pre
 author: MikeRayMSFT
 ms.author: mikeray
 ms.reviewer: randolphwest, dfurman
-ms.date: 02/03/2025
+ms.date: 03/28/2025
 ms.service: sql
 ms.subservice: configuration
 ms.topic: conceptual
 helpviewer_keywords:
   - "ADR Preallocation Factor"
 ---
+
 # Server configuration: ADR Preallocation Factor
 
 [!INCLUDE [SQL Server](../../includes/applies-to-version/sqlserver.md)]
 
 [!INCLUDE [sssql19-starting-md](../../includes/sssql19-starting-md.md)], this configuration setting is used by [accelerated database recovery](../../relational-databases/accelerated-database-recovery-concepts.md).
 
-Accelerated database recovery (ADR) uses row versions for transaction management and database recovery purposes. These versions are generated as part of various data manipulation language (DML) operations. Versions are stored in an internal table called the persistent version store (PVS).
+Accelerated database recovery (ADR) uses row versions for transaction management and database recovery purposes. These versions are generated as part of various data manipulation language (DML) operations. Versions are stored either in-row, or off-row in an internal table called the persistent version store (PVS).
 
 ## Remarks
 
-Performance can degrade if pages are allocated for persistent version store (PVS) as part of foreground user DML operations. A background thread preallocates pages, and keeps them readily available for DML transactions. Performance is optimal when the background thread preallocates enough pages that the percentage of foreground PVS allocations is close to 0. The error log contains entries with the tag `PreallocatePVS` if the percentage gets high enough to affect performance.
+Performance can degrade if pages are allocated for persistent version store (PVS) as part of foreground user DML operations. A background thread preallocates pages, and keeps them readily available for inserts into PVS. Performance is optimal when the background thread preallocates enough pages that the percentage of foreground PVS allocations is close to 0.
 
 The number of pages the background thread preallocates is based on various workload heuristics. Commonly, the background thread allocates chunks of 512 pages. The ADR preallocation factor is a multiple of the chunk. By default, the factor is `4`, which means that 2048 pages are preallocated at once when required.
 
-While the background thread takes workload patterns into consideration, this factor can be increased if necessary to improve performance.
+While the background thread takes workload patterns into consideration, this factor can be increased if necessary to improve performance. The `tx_version_optimized_insert_stats` extended event fires every few minutes and includes the `foreground_allocation_percent` field. If the value in this field is significantly higher than zero, consider increasing the `ADR Preallocation Factor` setting.
 
-> [!CAUTION]
+> [!WARNING]
 > If PVS preallocation factor is increased too much, it can contend with other allocations in the system and might actually reduce overall performance. Before you modify this setting, obtain a baseline of the system performance for tracking and comparison purposes.
 
 ::: moniker range="= sql-server-linux-ver15 || = sql-server-ver15"

docs/relational-databases/accelerated-database-recovery-concepts.md

@@ -4,7 +4,7 @@ description: "Learn about accelerated database recovery (ADR), which redesigned
 author: MashaMSFT
 ms.author: mathoma
 ms.reviewer: wiassaf, derekw, randolphwest, dfurman
-ms.date: 02/05/2025
+ms.date: 03/28/2025
 ms.service: sql
 ms.subservice: backup-restore
 ms.topic: conceptual
@@ -145,7 +145,7 @@ The four key components of ADR are:
 
 ## Workloads that benefit from ADR
 
-ADR is particularly beneficial for workloads that have: 
+ADR benefits most workloads, and is particularly beneficial for workloads that have: 
 
 - Long-running transactions.
 - Active transactions that cause the transaction log to grow significantly.
@@ -155,15 +155,15 @@ ADR isn't supported in databases using [database mirroring](../database-engine/d
 
 ## Best practices for ADR
 
-- Avoid unnecessary long-running transactions. Though ADR speeds up database recovery even with long-running transactions, such transactions can delay version cleanup and increase the size of the PVS.
+- Avoid unnecessary long-running transactions. Though ADR speeds up database recovery even with long-running transactions, such transactions can delay version cleanup and increase PVS size.
 
 - Avoid large transactions that include DDL operations. ADR uses the secondary log stream (SLOG) mechanism to track DDL operations used in recovery. SLOG is only used while the transaction is active. SLOG is checkpointed, so avoiding large transactions that use SLOG can help the overall performance. These scenarios can cause the SLOG to take up more space:
    - Many DDLs are executed in one transaction. For example, in one transaction, rapidly creating and dropping temp tables.
    - A table has very large number of partitions/indexes that are modified. For example, a `DROP TABLE` operation on such table would require a large reservation of SLOG memory, which would delay truncation of the transaction log and delay undo/redo operations. As a workaround, drop the indexes individually and gradually, then drop the table.
 
    For more information about SLOG, see [ADR recovery components](#adr-recovery-components).
 
-- Prevent or reduce unnecessary aborted transactions. A high transaction abort rate puts pressure on the PVS cleaner and lower ADR performance. The aborts might come from a high rate of deadlocks, duplicate keys, constraint violations, or query timeouts.
+- Prevent or reduce unnecessary aborted transactions. A high transaction abort rate puts pressure on the PVS cleaner and lowers ADR performance. The aborts might come from a high rate of deadlocks, duplicate keys, constraint violations, query timeouts, or other exceptions.
    The [sys.dm_tran_aborted_transactions](system-dynamic-management-views/sys-dm-tran-aborted-transactions.md) DMV shows all aborted transactions on the database engine instance. The `nested_abort` column indicates that the transaction committed but there are portions that aborted (savepoints or nested transactions) which can also delay the PVS cleanup process.
 
 - Ensure there's sufficient space in the database to account for PVS usage. If the database doesn't have enough room for PVS to grow, ADR might fail to generate versions, causing DML statements to fail.
@@ -174,9 +174,7 @@ ADR isn't supported in databases using [database mirroring](../database-engine/d
 
    If using [CDC](/azure/azure-sql/database/change-data-capture-overview) or [change feed](/azure/synapse-analytics/synapse-link/sql-database-synapse-link) in Azure SQL Database, you might need to increase your service tier or compute size to ensure that sufficient transaction log space is available for the needs of all your workloads. Similarly, in Azure SQL Managed Instance you might need to increase your instance maximum storage size.
 
-- For [!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)], isolate the PVS version store on a filegroup on higher tier storage, such as high-end SSD or advanced SSD or Persistent Memory (PMEM), sometimes referred to as Storage Class Memory (SCM). For more information, see [Change the location of the PVS to a different filegroup](accelerated-database-recovery-management.md#change-the-pvs-filegroup).
-
-- For [!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)], monitor the error log for `PreallocatePVS` entries. If `PreallocatePVS` entries are present, you might need to increase the ADR ability to preallocate pages using a background task. Preallocating PVS pages in background improves ADR performance by reducing more expensive foreground PVS allocations. You can use the `ADR Preallocation Factor` server configuration to increase this amount. For more information, see [Server configuration: ADR Preallocation Factor](../database-engine/configure-windows/adr-preallocation-factor-server-configuration-option.md).
+- For [!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)], when tiered performance storage is available, consider placing the PVS filegroup on higher tier storage. For more information, see [Change the PVS filegroup](accelerated-database-recovery-management.md#change-the-pvs-filegroup).
 
 - For [!INCLUDE[sssql22-md](../includes/sssql22-md.md)] and later, consider enabling multi-threaded PVS cleanup if the single-threaded cleaner performance is insufficient. For more information, see [Server configuration: ADR Cleaner Thread Count](../database-engine/configure-windows/adr-cleaner-thread-count-configuration-option.md).
 

docs/relational-databases/accelerated-database-recovery-management.md

@@ -4,7 +4,7 @@ description: "Best practices for managing and configuring accelerated database r
 author: MashaMSFT
 ms.author: mathoma
 ms.reviewer: wiassaf, derekw, dfurman, randolphwest
-ms.date: 02/03/2025
+ms.date: 03/28/2025
 ms.service: sql
 ms.subservice: backup-restore
 ms.topic: how-to
@@ -25,11 +25,11 @@ This article teaches you to enable and disable [accelerated database recovery (A
 
 ## Who should consider accelerated database recovery
 
-Many customers find accelerated database recovery (ADR) a valuable technology to improve database recovery time.
+Many customers find accelerated database recovery (ADR) a valuable technology to improve database recovery time and avoid lengthy rollbacks.
 
-If your database workloads frequently encounter the following scenarios, you might benefit from ADR:
+If your database workloads frequently encounter the following scenarios, you can benefit from ADR:
 
-- Long running transactions that can't be avoided. For example, in cases where long-running transactions are at risk of being rolled back, ADR can help.
+- Long running transactions that can't be avoided. For example, ADR helps in cases where long-running transactions are at risk of being rolled back.
 - Active transactions that cause the transaction log to grow significantly.
 - Long-running database recovery that impacts the availability of the database (for example, after an unexpected SQL Server restart or manual transaction rollback).