VDI_CLIENT_OTHER is recorded by threads involved in copying database data through the Virtual Device Interface, most commonly automatic seeding of a new Availability Group replica, and in Azure whenever something triggers a database copy (service tier changes, geo-replication setup).
The quirk that earns it a page: the system threads created for seeding, on the primary and the other replicas, stay alive until the instance restarts, even long after seeding completes. They sit doing nothing and keep accruing this wait forever.
Is It a Problem?
No. During an active seeding, high wait times just mean copy threads waiting for more data to move, which is normal pipeline behaviour. After seeding, the leftover idle threads make the number grow without meaning anything at all; that by-design thread persistence is why this wait can top a raw ranking months after anyone seeded anything.
Genuine seeding performance questions (slow seeding, stalled seeding) are answered by sys.dm_hadr_automatic_seeding and sys.dm_hadr_physical_seeding_stats, not by this wait.
Common Causes
- Automatic seeding of AG replicas, active or long finished.
- Azure database copies (tier changes, geo-replication).
- The persistent post-seeding idle threads accruing time until the next restart.
What To Do
- Filter it out of wait analysis.
- For live seeding progress and throughput, use the seeding DMVs; they show transfer rates and remaining work directly.
- Do not restart an instance just to clear the idle threads; they are harmless.
How To See It
Rank waits with Get-WaitStatistics; treat it as background noise, especially on instances that have ever run automatic seeding.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply