ASYNC_DISKPOOL_LOCK is recorded when a thread synchronises with the worker threads that manage long-duration file operations: creating and deleting files, zero-initialising new file space, and encrypting files for Transparent Data Encryption. Those operations run through a pool of workers, and coordinating with that pool produces this wait.
It travels with the file-heavy moments of a DBA’s calendar.
Is It a Problem?
Not as contention; it has not been a noticeable bottleneck. Its value is as a timeline marker: accumulation lines up with database creation, restores laying out files, file growth doing zero-fill (no instant file initialization), and TDE encryption scans working through files. If one of those operations is slow, this wait keeps its threads company, but the actual time sink is the underlying file work.
The fixes therefore belong to the operations, not the lock.
Common Causes
- Database creation and restores building out files.
- File growth zero-filling without instant file initialization.
- TDE encryption or decryption scans processing database files.
What To Do
- Map its spikes to the file operations in flight at the time.
- Apply the standard accelerators: instant file initialization for data files, pre-sized files so growth is rare, TDE scans scheduled off-peak.
- Measure the storage under the operation; long file work on slow volumes is the whole story.
How To See It
Rank it against everything else with Get-WaitStatistics; read it as a marker of long file operations rather than a tuning target.
ASYNC_DISKPOOL_LOCK is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply