PVS_PREALLOCATE is recorded by the background task that preallocates space in the Persistent Version Store (PVS) for databases with Accelerated Database Recovery (ADR) enabled. The task adapts to demand: on a quiet database it wakes every five minutes (accruing five-minute waits); under heavy versioning activity it runs far more often with much shorter waits, throttling itself up and down as the PVS consumes space.
Seeing it at all just means ADR is on, which from SQL Server 2022 onward is increasingly the norm and is always on in Azure SQL Database.
Is It a Problem?
No; it has not been a contention point, and its rhythm is the preallocation task pacing itself as designed. Filter it out.
The ADR topic worth actually monitoring is PVS size: long-running transactions prevent version cleanup, and a bloated PVS grows the database and can degrade performance. That story is told by sys.dm_tran_persistent_version_store_stats, not by this wait.
Common Causes
- ADR enabled on one or more databases, with the preallocation task on its adaptive schedule.
- Heavy update workloads making the task run more frequently (still benign).
What To Do
- Filter it out of wait analysis.
- Watch PVS health where it matters:
sys.dm_tran_persistent_version_store_statsfor size and the oldest active transaction holding cleanup back. - Keep transactions short, the same discipline ADR rewards everywhere else.
How To See It
Rank waits with Get-WaitStatistics; its cadence (five-minute waits when quiet) makes it easy to recognise and dismiss.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply