The Role of the Persistent Version Store (PVS)

The PVS is the heart of ADR. It acts as a dedicated storage area for data versions used for faster recovery. Imagine a timeline for your data – ADR captures snapshots at specific points in this timeline, allowing you to restore to any of these points quickly. As data is modified (INSERT, UPDATE, DELETE), ADR creates new versions within the PVS. This process is crucial for recovery, but it requires efficient storage management.

Introducing the ADR Preallocation Factor

The ADR Preallocation Factor in SQL Server 2019+ plays a crucial role in optimizing recovery performance by managing the allocation of pages for the Persistent Version Store (PVS). As the PVS needs space to store data versions, it pre-allocates storage pages in chunks, with the default value set to 4, meaning the PVS allocates 2048 pages (4 x 512) at a time. A background thread pre-allocates these pages to ensure they are readily available for DML transactions, improving performance by reducing the need for foreground user DML operations to allocate pages. The ADR Preallocation Factor determines the number of pages the background thread pre-allocates at once. While it dynamically adjusts based on workload patterns, you can manually adjust this factor using the sp_configure stored procedure to suit your specific needs better.

Why You Might Need to Adjust the ADR Preallocation Factor

While the default setting works well for most scenarios, consider adjusting it under specific circumstances. Here’s when you might explore changing the default setting:

  • High Transaction Workloads: If your database experiences frequent data modifications (heavy INSERT, UPDATE, and DELETE operations), the default pre-allocation size might need to be increased. Increasing the factor helps the background thread keep up with the rapid version creation, improving recovery performance.
  • Slow Recovery Times: If you encounter unusually long recovery times during rollbacks or point-in-time restores, it could indicate the PVS is struggling to keep up with version creation due to insufficient pre-allocation.
  • Error Messages: Reviewing the SQL Server error log for entries related to “PreallocatePVS” might indicate a need for adjustment. These messages suggest the background thread is encountering difficulties in pre-allocating space.

Assessing the Optimal Preallocation Factor Configuration

Before adjusting the ADR Preallocation Factor, assessing your situation is crucial. Here are some steps to consider:

  • Analyze Workload Patterns: Monitor your database activity to understand the frequency and volume of data modification operations. This helps determine if the default pre-allocation size is sufficient for your workload.
  • Review Existing Configuration: Use the sp_configure stored procedure to view the current ADR Preallocation Factor value.
  • Monitor Performance: Monitor recovery times during rollbacks and point-in-time restores.

Best Practices for Adjusting the ADR Preallocation Factor

If you decide to adjust the ADR Preallocation Factor, exercise caution. Here are some best practices to follow:

  • Start with Small Increments: Only make drastic changes at a time. Begin by increasing the factor by a small value (e.g., 1) and monitor the impact on performance.
  • Thorough Testing: After any adjustment, conduct thorough testing to ensure recovery speed has improved without introducing resource contention issues.
  • Consult Microsoft Documentation: Refer to official Microsoft documentation for detailed information on the ADR Preallocation Factor and its configuration.

Monitoring and Troubleshooting

Regularly monitor the size of the PVS and establish cleanup procedures to prevent it from consuming excessive storage space. You can use the DMV sys.dm_tran_persistent_version_store_stats to monitor if the size of the PVS is growing larger than expected and determine which factors are preventing cleanup.

Conclusion

The ADR Preallocation Factor offers a valuable tool for fine-tuning ADR performance in SQL Server 2019 and later versions. Although this can provide you with efficiency improvements, it is still essential to test the overall performance of your system when making any changes to the ADR Preallocation Factor.

Please contact us for more info!

Share This