RESTORE_MSDA_THREAD_BARRIER is recorded during restores from multiple backup devices (striped backups). Threads restoring parts of a single data block from the multiple streams synchronise at a barrier: all must finish their piece before the group advances to the next block. The wait is that rendezvous.
Striped restores live at this barrier constantly, in small doses.
Is It a Problem?
Routinely, no; it is the coordination cost of parallel restore streams, and its total tracks restore duration. The historical sharp edge is worth knowing: before SQL Server 2019, an error on one thread (a failed read from a backup file, a failed write to a database file) could leave all the other threads hung at this barrier, producing a restore that never finishes and must be manually killed. SQL Server 2019 catches that case and fails the restore cleanly.
A striped restore stuck far past its expected duration with threads parked here, on an older version, is that bug’s signature.
Common Causes
- Normal striped-restore synchronisation, proportional to restore size.
- The pre-2019 hang-after-error case on affected versions.
What To Do
- For a suspected hang on pre-2019: check the error log for a read/write error around when progress stopped; kill and retry the restore, and investigate the failing device or file.
- Balance stripe performance: equal-speed destinations keep barrier waits small; one slow device gates all streams.
- On 2019+, errors surface properly; treat barrier time as ordinary restore mechanics.
How To See It
Rank waits with Get-WaitStatistics during restore windows; duration anomalies matter more than totals.
Part of the SQL Server Wait Types Library.
Related deep dive: BACKUPIO and BACKUPBUFFER Wait Types.
Leave a Reply