Delayed Durability - Getting Started with SQL Server 2014 Administration - page 46

The following is true for delayed transaction durability:
• When a transaction commit completes successfully, any changes made by the
transaction are available and visible to other transactions in the system
• The durability of the transaction is only guaranteed when the in-memory
transaction log is flushed to disk. A flush to disk can happen when:
° A fully durable transaction in the same database commits successfully
° The user executes the sp_flush_log system-stored procedure
successfully
° The in-memory transaction log buffer fills up, and then transactions
are automatically flushed to disk
• It is only when the in-memory transaction is flushed to disk that the
transaction become durable
Full Durability versus Delayed Durability
There are some factors to consider when deciding on whether to use Full or Delayed
Durability. These include:
• Data loss : If you can accept some data loss and the performance of the
system is more important than the recoverability of certain transactions,
then Delayed Durability could be an option for you.
• Bottleneck on transaction log writes: After careful analysis of your system
wait stats, you concluded that you are suffering from performance issues.
This could be due to latency when writing to the transaction log, and you can
accept some data loss in the event of a system crash or restart. In which case,
Delayed Durability could be an option to solve this performance issue.
• A high contention workload : If your wait stat analysis shows that your
performance slowness is caused by the delay in locks being released, then
Delayed Durability could be an option. It helps remove the contention as it
reduces the commit time and as such locks will be released faster.
For additional information on Control Transaction Durability , see:
http://msdn.microsoft.com/en-us/library/dn449490(v=sql.120).aspx