Performance Tuning with SQL Server Dynamic Management Views

117
Chapter 4: Transactions
unique transaction_id in our result sets. All statements executed within an explicit
transaction will be reported with a single transaction_id.
SQL Server will attempt to ensure that each unit of work, be it a single-statement implicit
transaction, or any number of individual SQL statements within an explicit transaction,
conforms to the ACID test characteristics.
What we hope to demonstrate in this chapter is how to observe these units of work via
the DMOs. Since the lifespan of these transactions is measured in milliseconds, when
everything is going right the focus will be on those transactions that are having difficulty
completing in a timely fashion, whether due to contention for resources, poor tuning, or
other issues.
Investigating Locking and Blocking
Locking is an integral aspect of any RDBMS. Locks control how transactions are allowed
to interact, impact, and impede one another when running simultaneously against
common objects. Unless you restrict data access to one user at a time, clearly not a
viable option, locks are necessary to the smooth functioning of any RDBMS.
Locks are to be neither feared nor shunned but they can, nevertheless, cause problems
for the reckless or unwary. When using SQL Server's default isolation level, READ
COMMITTED, shared read locks are acquired during data reads. These locks prevent
another transaction from modifying that data while the query is in progress, but do not
block other readers. Furthermore, "dirty reads" are forbidden, so SQL Server acquires
exclusive locks during updates, to prevent a transaction from reading data that has been
modified by another transaction, but not committed. Of course, this means that if one
transaction (A) encounters data that is being modified by another transaction (B), then
transaction A is blocked; it needs access to a resource that is locked by B and cannot
proceed until B either commits or rolls back.