Database Reference
In-Depth Information
Listing 32-11. Analyzing an in-memory OLTP log record
select [Current LSN], object_name(table_id) as [Table]
,operation_desc, tx_end_timestamp, total_size
from sys.fn_dblog_xtp('0x0000001f:0000593b:0002', '0x0000001f:0000593b:0002')
Figure 32-23. In-memory OLTP log record
Finally, it is worth stating again that any data modification on non-durable tables ( DURABILITY=SCHEMA_ONLY ) is
not logged in the transaction log nor is it data persisted on disk.
Data Durability and Recovery
The data from durable memory-optimized tables is stored separately from on-disk tables. SQL Server uses a streaming
mechanism to store in-memory OLTP data, which is based on FILESTREAM technology and is optimized for sequential
I/O operations. In fact, in-memory OLTP does not use random I/O operations at all; that is, all in-memory OLTP I/O
operations are sequential.
even though in-memory OLtP uses a FILESTREAM streaming mechanism under the hood, the data is stored
separately from the FILESTREAM data filegroup. you should have two filegroups: one for in-memory OLtP and another for
FILESTREAM data when the database uses both technologies.
Note
In-memory OLTP stores data in multiple file pairs: data files and delta files, often referenced as checkpoint
files . Each pair of data and delta files covers operations for a range of Global Transaction Timestamp values and
logs operations on the rows that have BeginTs in this range. Every time you insert a row, it is saved into a data file.
Every time you delete a row, the information about the deleted row is saved into a delta file. Update generates two
operations—insert and delete—and it saves this information to both files.
 
 
Search WWH ::




Custom Search