30.06.2013 Views

Performance Tuning with SQL Server Dynamic Management Views

Performance Tuning with SQL Server Dynamic Management Views

Performance Tuning with SQL Server Dynamic Management Views

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 4: Transactions<br />

Simply by un-commenting the calculation of the transaction duration in Listing 4.14, and<br />

swapping the ORDER BY clause, we can investigate the activity of long-running transactions<br />

that may be bloating the transaction log file, or preventing it from being truncated.<br />

Snapshot Isolation and the tempdb Version Store<br />

The snapshot isolation level was introduced in <strong>SQL</strong> <strong>Server</strong> 2005 and eliminates<br />

blocking and deadlocking by using row versioning in the tempdb database to maintain<br />

concurrency, rather than establishing locks on database objects. As such, the goal of<br />

snapshot isolation is increased performance through greater concurrency. Snapshot<br />

isolation is a huge topic and we can do little more than provide a brief overview here.<br />

Please see Microsoft Books Online or MSDN for further details on isolation levels,<br />

concurrency, and locking models.<br />

Each time a row is modified in a database running under snapshot isolation, a version<br />

of the row from prior to the modification is stored <strong>with</strong>in tempdb in a version store. In<br />

other words, this version store is populated <strong>with</strong> versions of data rows as they existed<br />

before the initialization of an explicit transaction. The version store is shared by all<br />

databases that are running under snapshot isolation on the <strong>SQL</strong> <strong>Server</strong> instance.<br />

Read transactions targeting the affected rows will use the row version(s) from the<br />

tempdb, while the writing transaction will modify the actual table data. Update locks<br />

are issued for writes, and when a read transaction encounters such a lock, it is diverted<br />

to the version store.<br />

This row-versioning mechanism ensures that write transactions do not block reads. It<br />

is no longer necessary to take exclusive locks on data being modified, to prevent dirty<br />

reads, because the reads are made against versions of the rows that were in a committed<br />

state from prior to the transaction or statement initialization. It also means that<br />

readers do not block writers, since read transactions will no longer take shared read locks.<br />

148

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!