Database Reference
In-Depth Information
Transaction Logging
Any data modification operations on durable, memory-optimized tables are logged in the database transaction log.
However, logging works differently as compared to on-disk tables.
The first major difference is that in-memory OLTP generates and saves log records at the time of the transaction
COMMIT rather than during each data row modification. There is a guarantee, however, that transactions without
delayed durability will receive COMMIT acknowledgement only after log records are hardened in the log.
The format of a log record is also different. Log records do not include any undo information. Dirty data from
uncommitted transactions would never materialize on disk and, therefore, in-memory OLTP log data does not need to
support the undo stage of crash recovery.
In-memory OLTP generates log records based on the transactions write set. All data modifications are combined
together in one or very few log records based on the write set and inserted rows' size.
Let's examine this behavior and run the code shown in Listing 32-9. It starts a transaction and inserts 500 rows
into a memory-optimized table. As a next step, it examines the content of the transaction log using the undocumented
sys.fn_dblog system function.
Listing 32-9. Transaction logging in in-memory OLTP: Memory-optimized table logging
declare
@I int = 1
begin tran
while @I <= 50
begin
insert into dbo.HKData with (snapshot)
(ID, Col)
values(@I, @I)
set @I += 1
end
commit
go
select *
from sys.fn_dblog(NULL, NULL)
order by [Current LSN];
Figure 32-21 illustrates the content of the transaction log. You can see the single transaction record for the
in-memory OLTP transaction.
Figure 32-21. Transaction log content after in-memory OLTP transaction
Let's repeat this test with an on-disk table of similar structure. Listing 32-10 shows the code that creates a table
and populates it with data.
 
Search WWH ::




Custom Search