In-Memory OLTP Internals - Pro SQL Server Internals - page 668

Figure 32-27. Merge process

In most cases, an automatic merge is sufficient to keep the number of files and performance at a manageable
level. You can trigger a manual merge, however, with the sys.sp_xtp_merge_checkpoint_files system stored
procedure if needed. The sys.dm_db_xtp_merge_requests view allows you to validate the status of a merge request.

■ you can read about the sys.sp_xtp_merge_checkpoint_files procedure at: http://msdn.microsoft.com/
en-us/library/dn198330.aspx . Information about the sys.dm_db_xtp_merge_requests view is available at:
http://msdn.microsoft.com/en-us/library/dn465868.aspx .

Note

After the merge process is completed, garbage collection will eventually remove old data and delta files and
reclaim the disk space. It does not happen immediately, however. SQL Server needs to make sure that the original files
are no longer needed for recovery in case of disaster.
In-memory OLTP CHECKPOINT is a separate process from the Storage Engine CHECKPOINT , and it has its own
truncation LSN, which can prevent the transaction log from being truncated. In addition to a manual CHECKPOINT
operation, which also closes all active data files, it can be triggered under the following conditions:

Transaction log growth since the last checkpoint exceeds 1GB.
The last automatic or manual CHECKPOINT occurred 6 hours previously.
A CHECKPOINT operation creates another transaction log record called checkpoint inventory . It includes
information about all of the active data and delta files and the current Global Transaction Timestamp value. It is also
worth mentioning that the background CHECKPOINT thread constantly analyzes the transaction log records generated
by in-memory OLTP and populates data and delta files in between checkpoints. This helps avoid bursts in I/O activity
for in-memory OLTP-related checkpoints.