Database Reference
In-Depth Information
In-memory OLTP uses a row-versioning concurrency model. Row data is never updated; a new version of a row
is created instead. Every row has two timestamps indicating its lifetime. Transactions never see uncommitted data or
versions of rows deleted before or created after a transaction has started.
In-memory OLTP supports three transaction isolation levels:
SNAPSHOT
,
REPEATABLE READ
, and
SERIALIZABLE
.
In contrast to on-disk tables where data consistency is supported with locking, in-memory OLTP transactions validate
REPEATABLE READ
and
SERIALIZABLE
data consistency rules at the time of
COMMIT
, aborting transactions if needed.
SQL Server uses a pair of checkpoint files to provide data durability. Data files contain inserted versions of rows.
Delta files contain information about deleted rows. Each pair of files covers a particular time range using a streaming
append-only mechanism to maintain the files. SQL Server merges files that cover adjacent time ranges as the
percentage of deleted rows grows.
Memory-optimized tables can be either durable or non-durable. Data modifications of the data from durable
tables are logged in the transaction log and saved in checkpoint files. That data is included in database backups and
is synchronized with secondary nodes in AlwaysOn Availability Groups. Data from non-durable tables is not saved in
checkpoint files, nor are data modifications logged in the transaction log.
You should monitor memory usage of memory-optimized tables. Transactions in the in-memory OLTP engine
will fail if SQL Server cannot allocate memory. Neither SQL Server nor the database would start if it does not have
enough memory to load memory-optimized data.
