Performance Tuning with SQL Server Dynamic Management Views

163
Chapter 4: Transactions
In short, this script is very useful in allowing the DBA to identify transactions that will
rely upon the version store if other transactions, competing for the same resources/rows,
make modifications to those rows. High count of versions in the version store may point
to a row/resource that is in high demand, i.e. a lot of other transactions are also hitting
the same row/resource and the version store needs to spawn frequent versions of it to
maintain concurrency under snapshot isolation. You may find yourself needing to adjust
the size of your tempdb in order to accommodate this situation.
Finally, in order to observe the difference in behavior between the two SNAPSHOT
and READ_COMMITTED_SNAPSHOT queries, return to Tab 1 (Listing 4.19) and Tab 2
(Listing 4.20) and commit the modifications. Go to Tab 3 (Listing 4.21), which is running
in SNAPSHOT mode, highlight only the SELECT query and rerun it. Since the initial
transaction in this session started before the addition of the fourth row was committed,
only the three rows committed before the transaction began are returned.
Now go to Tab 4 (Listing 4.22), which is running in SNAPSHOT_READ_COMMITTED mode,
and rerun the query. Since the INSERT and UPDATE transactions were committed before
the statement was run, all four rows will be returned, as shown in Figure 4.13.
Figure 4.13: Demonstrating the difference in behavior between SNAPSHOT and
READ_COMMITTED_SNAPSHOT.
As a final clean up, commit or roll back all outstanding transactions.