In-Memory Optimized Tables - Getting Started with SQL Server 2014 Administration - page 32

Memory-optimized tables
The following quote is from the SQL Server 2014 documentation:
"SQL Server In-Memory OLTP helps improve performance of OLTP applications
through efficient, memory-optimized data access, native compilation of business
logic, and lock- and latch free algorithms. The In-Memory OLTP feature includes
memory-optimized tables and table types, as well as native compilation of Transact-
SQL stored procedures for efficient access to these tables."
Much like traditional tables, memory-optimized tables offer fully durable
transactions and meet ACID ( Atomic Consistent Independent and Durable ) by
default and are designed to help databases that require really fast performance.
Much like the name suggests, memory-optimized tables are stored in the main
memory (RAM) and therefore not on the hard disk. In fact, internally, SQL Server
does keep a second copy on disk but this is for durability purposes and is only read
from the hard disk during database recovery. A set of checkpoint files, data, and
delta file pairs are used for recovery purposes.
The insert , update , and delete statements make use of the same transaction log
that is used for the hard disk-based tables, so in the event of a server reboot, a crash,
or the SQL Service being restarted, the transaction and the checkpoint can be used
to repopulate the memory-optimized table.
In-Memory OLTP ( Online Transaction Processing ) supports delayed transaction
durability, which means that soon after the transaction is committed, the transaction is
written to the disk. This again offers a performance gain to the database administrator.
There is no gain without pain though. To utilize this feature and to offset the
performance gain, all the transactions that have not been written to the disk will
be lost if the server crashes.
SQL Server 2014 also supports nondurable OLTP In-Memory Optimized tables. The
data in the table is stored in memory but the data is not persisted to disk and data
manipulation statements are not logged in the transaction log. Only the table schema
is stored. This again can lead to dramatic performance gains but as always there is
a trade-off and the downside is that the data will be lost in the event of a server
restart. The database will also be lost in the event of an AlwaysOn Availability
group failover.