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

You can update individual statistics with the UPDATE STATISTICS command. Alternatively, you can use
sp_updatestats stored procedure to update all statistics in the database. The sp_updatestats stored procedure
always updates all statistics on memory-optimized tables, which is different from how it works for on-disk tables,
where such a stored procedure skips statistics that do not need to be updated.
It is also worth noting that SQL Server always performs a full scan while updating statistics on memory-optimized
tables. This behavior is also different from on-disk tables, whereas SQL Server samples the data by default.

■ you can read more about statistics on memory-optimized tables at:
http://msdn.microsoft.com/en-us/library/dn232522.aspx .

Note

Garbage Collection
In-memory OLTP is a row-versioning system. Data modifications generate new versions of rows rather than updating
row data. Every row has two timestamps ( BeginTs and EndTs ) that indicate row lifetime: when the row was created and
when it was deleted. Transactions can only see the versions of rows that were valid at the time when the transaction
started. In practice, this means that the Global Transaction Timestamp value at the start of the transaction is between
the BeginTs and EndTs timestamps of the row.
At some point, when the EndTs timestamp of a row is older than the Global Transaction Timestamp of the Oldest
Active Transaction in the system, the row becomes stale. Stale rows are invisible for active transactions in the system,
and eventually they need to be deallocated to reclaim system memory and speed up index chain navigation.
This process is called a garbage collection .
SQL Server has a dedicated system thread to perform garbage collection; however, the user sessions' threads
do most of the work. When a user thread is scanning a row chain in the index and it detects a stale row, the thread
unlinks that row from the chain and decrements the reference counter ( IdxLinkCount ) in the row header. As already
discussed, this counter indicates the number of chains in which the row is present. The row can be deallocated only
after it is removed from all of the chains.
The user thread does not deallocate stale rows immediately, however. When a transaction is completed, the
thread puts information about this transaction to the queue used by the garbage collector. Every transaction keeps
information about the rows it created or deleted, which is available to the garbage collector thread.
The garbage collector thread periodically goes through that queue and analyzes stale rows and builds work items,
which are collections of rows that need to be deallocated. Those work items, in turn, are inserted into other queues
partitioned on a per-Logical CPU basis. Users (and sometimes system garbage collector) threads pick up work items
and deallocate the rows, reclaiming system memory in the process.
You can monitor statistics about the garbage collection process with the sys.dm_xtp_gc_stats view. This view
returns various pieces of information about stale rows, statistics about garbage collection scans, and a few other metrics.
The sys.dm_xtp_gc_queue_stats view provides information about the garbage collection work item queue,
including how many work items have been enqueued and dequeued, how many items are still in the queue, and a
couple other attributes.

■ you can read more about the sys.dm_xtp_gc_stats view at: http://msdn.microsoft.com/en-us/library/
dn133196.aspx and about the sys.dm_xtp_gc_queue_stats view at: http://msdn.microsoft.com/en-us/library/
dn268336.aspx .

Note