CHECK_TABLES_INITIALIZATION is recorded when a parallel thread belonging to a DBCC CHECKDB (or CHECKTABLE/CHECKFILEGROUP) command initialises and has to wait on a mutex that another initialising thread currently holds. Parallel DBCC spins up a set of worker threads at the start of each check, and they take turns through this small critical section while setting up.
It is startup coordination inside the integrity check machinery, nothing more.
Is It a Problem?
No; it has not been a contention point, and its footprint is a brief blip at the start of each parallel DBCC run. Its totals scale with how many integrity checks you run and their degree of parallelism, both of which you already control.
If integrity checks are slow overall, the time is in the actual checking (reading pages, building facts, the internal snapshot’s copy-on-write), which shows up under OLEDB, PAGEIOLATCH_*, and WRITE_COMPLETION, not in this initialisation mutex.
Common Causes
- Parallel DBCC CHECKDB runs initialising their worker threads.
- Frequent scheduled checks across many databases multiplying the blips.
What To Do
- Filter it from wait analysis; it is DBCC housekeeping.
- For slow integrity checks, tune the real levers: run off-peak, use
PHYSICAL_ONLYwhere the trade-off fits, or offload checks to a restored copy. - Nothing else; there is no knob behind this wait.
How To See It
Rank waits with Get-WaitStatistics; expect traces aligned exactly with your DBCC schedule.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply