DPT_ENTRY_LOCK is recorded when a thread waits for access to individual entries in the dirty page list on an Availability Group readable secondary, with parallel redo threads and read queries as the contending parties. It is the finer-grained sibling of DIRTY_PAGE_TABLE_LOCK: that one is the list itself, this one is specific entries in it.
The distinction carries diagnostic weight.
Is It a Problem?
Same conditions as its sibling, heavy secondary reads plus heavy primary writes, but with one sharpening detail: DPT_ENTRY_LOCK becomes prevalent when the reads and the updates involve the same tables, because redo and readers are then contending for the same pages’ entries. DIRTY_PAGE_TABLE_LOCK rises even for unrelated tables; this one says your reporting queries and your primary’s hot writes overlap on the same objects.
That points the fix at workload separation rather than general capacity.
Common Causes
- Reporting on the secondary against exactly the tables the primary is hammering.
- Real-time dashboards reading hot operational tables through a readable replica.
- Redo bursts on those same tables during maintenance windows.
What To Do
- Identify the overlapping tables: what the secondary’s queries read versus what the primary’s write workload churns.
- Break the overlap: pre-aggregated reporting tables, or a small ETL step that copies hot data into read-optimised structures the redo stream does not fight over.
- Apply the general remedies too (scheduling separation, reduced write amplification on the primary), as with
DIRTY_PAGE_TABLE_LOCK.
How To See It
Rank it against everything else with Get-WaitStatistics on the secondary; read the two dirty-page waits together to tell same-table contention from list-level contention.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply