CHECK_TABLES_THREAD_BARRIER is recorded when a parallel thread in a DBCC CHECKDB (or related) command waits at a barrier for its sibling threads, either while they finish initialising, or while they finish exiting after certain unexpected errors terminate the command. Every parallel DBCC run produces some of it; barriers are how the workers stay in step.
Killing a DBCC manually does not go through this path; it is the error-termination path that does.
Is It a Problem?
Usually not; it is normal parallel-DBCC coordination and safe to ignore in routine analysis. The one scenario worth knowing: there is anecdotal evidence of a bug where a DBCC CHECKDB fails for some reason and then hangs, with one or more threads stuck waiting on this wait type indefinitely. A CHECKDB that has been “running” far past its normal duration, showing this wait and making no progress, fits that picture.
In that case the command is wedged, not slow.
Common Causes
- Normal barrier synchronisation in every parallel DBCC run.
- Threads draining after an error terminated the check.
- The known hang-after-failure edge case on some builds.
What To Do
- Ignore routine amounts; they track your DBCC schedule.
- For a suspected hang: compare against the check’s normal duration, look for an error in the error log around when progress stopped, and check whether the session’s wait time just grows forever.
- A wedged check needs the session killed and the check re-run; if it reproduces, capture details and check for fixes in your build’s CU history.
How To See It
Rank waits with Get-WaitStatistics, and judge it against DBCC run durations rather than in isolation.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply