WAIT_XTP_OFFLINE_CKPT_NEW_LOG is recorded by an In-Memory OLTP (XTP) offline checkpoint thread waiting for new log records to scan. In-Memory OLTP durability works by continuously scanning the transaction log and folding changes into checkpoint file pairs (data and delta files); when the scanner catches up to the end of the log, it parks in this wait until more log arrives. SQL Server 2014 ran one such thread; 2016 onward runs several.
A caught-up log scanner is the healthy state, so this wait mostly measures quiet time.
Is It a Problem?
No; it is expected and filtered as benign wherever In-Memory OLTP is enabled, and it appears as soon as a database has a memory-optimized filegroup, even one created incidentally or barely used. Its totals track how often the checkpoint scanner has nothing new to read, which is good news, not a symptom.
Genuine In-Memory OLTP checkpoint concerns look different: checkpoint file pairs accumulating beyond expectation, merge operations falling behind, or the log growing because XTP checkpointing stalls, all visible through sys.dm_db_xtp_checkpoint_files and related DMVs.
Common Causes
- A memory-optimized filegroup existing in any database, with the offline checkpoint threads idling between log bursts.
- Low write volume to memory-optimized tables.
What To Do
- Filter it out of wait analysis; our
Get-WaitStatisticsscript excludes it by default. - For real XTP checkpoint health, review
sys.dm_db_xtp_checkpoint_files(file counts and states) and log truncation behaviour on the databases involved. - Do not remove memory-optimized filegroups just to silence the wait; judge the feature on its own merits.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered. Its presence simply documents that In-Memory OLTP structures exist on the instance.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply