WAIT_XTP_OFFLINE_CKPT_LOG_IO is recorded when an In-Memory OLTP offline checkpoint thread waits for a log read I/O to complete. The XTP checkpoint mechanism continuously scans the transaction log for changes to memory-optimized tables and folds them into checkpoint file pairs; when the scanner has to physically read log from disk, the read time lands here.
Its sibling WAIT_XTP_OFFLINE_CKPT_NEW_LOG is the same scanner with nothing to read; this one is the scanner reading, slowly or otherwise.
Is It a Problem?
Not usually; it has not been a contention point, and moderate amounts just mean the checkpoint scanner sometimes reads log from disk rather than cache. Where it earns a glance: consistently large values indicate the scanner is doing a lot of physical log reading, which combines log volume with log-drive read latency, the same disk your commits depend on.
If XTP checkpointing genuinely lags (visible as checkpoint file backlog and log truncation delays), slow log reads are one contributing suspect.
Common Causes
- XTP checkpoint scanning reading log physically after cache misses (catch-up after bursts, restarts).
- High log generation on memory-optimized tables giving the scanner more to read.
- Log storage with poor read performance stretching each read.
What To Do
- Filter it in routine analysis; act only alongside real XTP checkpoint symptoms.
- If those symptoms exist, measure log-file read latency in
sys.dm_io_virtual_file_statsand checksys.dm_db_xtp_checkpoint_filesfor backlog. - Log storage that serves both writes and XTP scans well is the underlying requirement.
How To See It
Rank waits with Get-WaitStatistics, reading it with its NEW_LOG sibling and the XTP checkpoint DMVs.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply