HADR_SEEDING_LIMIT_BACKUPS is recorded during Availability Group automatic seeding operations, and its observed behaviour is long waits, thousands of seconds in reported cases, lasting for the duration of some seeding runs. The name suggests throttling around concurrent backup-style operations inside the seeding machinery (seeding streams a backup under the hood).
Documentation is thin; field evidence is that it accompanies seeding and resolves with it.
Is It a Problem?
It appears to be benign: a seeding-scoped wait that measures the operation’s own pacing rather than a fault. If automatic seeding is running and this wait is accumulating, the meaningful questions are about the seeding itself, is it progressing, and at what rate, which the seeding DMVs answer directly.
A seeding that has genuinely stalled shows as zero transfer progress in the DMVs, regardless of what this wait reads.
Common Causes
- Automatic seeding of AG replicas in progress.
- Long-running seedings of large databases carrying the wait for their duration.
What To Do
- Judge seeding by
sys.dm_hadr_automatic_seeding(state, failure reasons) andsys.dm_hadr_physical_seeding_stats(transfer and ETA), not by this wait. - For slow seedings, the levers are network throughput between replicas and I/O on both ends; compression for seeding (trace flag 9567) trades CPU for bandwidth where the network is the constraint.
- Filter the wait itself out of analysis.
How To See It
Rank waits with Get-WaitStatistics; expect it only during seeding windows, and read past it once the DMVs confirm progress.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply