Transaction Durability

Microsoft’s SQL Server development team have added new features in the new version of SQL Server 2014, one of the noticeable changes is the ability to control transaction’s durability in the database or transaction level.

Database durability is an ACID property which guarantees the sustainability of transactions after the commit process. To fulfil full durability, SQL Server’s engine writes each and every operation made in the database to the log file located on a physical disk prior to the commit acknowledgment. Write operations are sequential, and therefore fast. But as you can probably imagine, fast is sometimes not fast enough.

A typical DML operation will consist of the following steps:

• Lock acquirement
• Writing the operation to the buffer pool
• Writing the operation to the log buffer
• Flushing the log pages to the disk
• Here comes the commit acknowledgment
• Within Asynchronous checkpoint, the buffer pool pages will be written to the disk

While the log buffer flashes to the physical disk, other operations which try to write to the log buffer are halted. In databases with a large number of transactions per second (tps), the latency of writing log records may increase with the number of tps, resulting in operation delays.

The most efficient way to diagnose those issues is to monitor the sys.dm_os_wait_stats DMV, or more specifically the WRITELOG wait type. Within that record you can find cumulative statistical information such as “waiting_tasks_count ” and “wait_time_ms” about Log Writes related waits since SQL Server was last restarted. Delta calculation on those two columns will reveal the evidence you need for diagnosis.

SQL Server 2014 gives a built in resolution to this “Big Data” scenario, delayed transaction durability. This new feature offers us DBAs the ability to control when the transaction log will be written to the disk. Choosing delayed transaction durability will reveal changes made by the transaction to other transactions on commit but will not write the log record to the disk. The described behavior will ensure durability only after the in memory log buffer will be flushed to the disk but, on the other hand, will minimize the commit time.

Configuration is quite simple and easy to use, we can define transactions with delayed durability in three different ways, at the commit statement, as a database property or within Natively Compiled Procedures. The three methods give us the freedom to choose whether all our transactions will be delayed durable or just specific operations.

ALTER DATABASE [PlayGround] SET DELAYED_DURABILITY = ALLOWED 
GO 

SELECT
	[name],
	[delayed_durability],
	[delayed_durability_desc] 
FROM 
	sys.databases

Delayed durability writes the log buffer to the disk asynchronously, and therefore speeds up performance. But an important question arise, when does the transaction become fully durable, or in other words, when does the log buffer flush to the disk?
There are three scenarios at which a log buffer flush can occur:

• A fully durable transaction in the same database successfully commits.
• The user executes the system stored procedure sp_flush_log successfully.
• The in-memory transaction log buffer fills up and automatically flushes to disk.

-- Open Performance Monitor 
--1.Transactios/sec,
--2.Log Bytes Flushed/Sec 
BEGIN TRANSACTION 
	[DelayedDurabilityOn]

INSERT INTO [dbo].[TestInsert]  
	VALUES (1,'Madeira')

COMMIT TRANSACTION 
	[DelayedDurabilityOn] WITH (DELAYED_DURABILITY = On  )
GO 

WAITFOR DELAY '00:00:10';
EXEC sp_flush_log

During the exploration of this new feature I wanted to evaluate the performance impact on insert statements.

In order to assess the insert capabilities of delayed durability and the impact on wait statistics, we must first clear the sys.dm_os_wait_stats table and log the current WRITELOG wait statistics as a reference.

DBCC SQLPERF('sys.dm_os_wait_stats','CLEAR')
GO 
INSERT INTO #Log(wait_type,wait_time_ms,waiting_tasks_count)
SELECT 
	wait_type,wait_time_ms,	waiting_tasks_count
FROM	sys.dm_os_wait_stats
WHERE	wait_type = 'WRITELOG'

The second step is to run a script which counts the number of records the system inserts with delayed VS full transaction durability within a full minute, the structure of the records consists of one column, NVARCHAR 50 (see the evaluation script below).

The performance impact is astonishing: delayed transaction durability on my laptop was able to insert records fifteen times as much as full transaction durability.

Delayed durability indeed sounds promising, but there are some limitations. Besides the obvious limitations on Replication, Log shipping, Log Backup and Crash recovery where only those transactions that have been made durable are replicated / shipped / backed up / restored, there are other guidelines. Transactions with Change Tracking and cross database or distributed transaction are always fully durable.

Delayed durability and SQL Server 2014 defines a new era in the SQL Server series, a version with new “Big Data” capabilities which prefers performance over ACID. I can already think about several companies that will benefit from using it.

The post Transaction Durability appeared first on .