As you have already seen, transaction information is
recorded in each database’s transaction log. However, long-running
transactions can be a cause of consternation to a system administrator
who is attempting to back up and prune the transaction log. Only the
inactive portion of the log can be truncated during this operation. The
inactive portion of the log is the pages that contain log records for
all completed transactions prior to the first log record of the oldest
still-active transaction (see Figure 1).
Even if completed transactions follow the first record of the oldest
active transaction, they cannot be removed from the log until the oldest
active transaction completes. The reason is that the log is pruned by
clearing out entire pages of information prior to the oldest active
transaction. Pages after that point cannot be cleared because they might
contain records for the active transaction that would be needed in the
event of a rollback or database recovery.
In addition to preventing the log from being pruned,
long-running transactions can degrade concurrency by holding locks for
an extended period of time, preventing other users from accessing the
locked data.
To get information about the oldest active transaction in a database, you can use the DBCC OPENTRAN command, whose syntax is as follows:
DBCC OPENTRAN [('DatabaseName' | DatabaseId)]
[WITH TABLERESULTS [, NO_INFOMSGS]]
The following example displays a sample of the oldest active transaction for the bigpubs2008 database:
DBCC OPENTRAN (bigpubs2008)
go
Transaction information for database 'bigpubs2008'.
Oldest active transaction:
SPID (server process ID): 56
UID (user ID) : -1
Name : add_titles
LSN : (1926:170:6)
Start time : May 26 2009 12:17:09:220AM
SID : 0xe6810e075514c744bc8d03b34c27b004
DBCC execution completed. If DBCC printed error messages, contact your system
administrator.
DBCC OPENTRAN returns the server process ID
(SPID) of the process that initiated the transaction, user ID, name of
the transaction (naming transactions are helpful here because the names
might help you identify the SQL code that initiated the transaction),
LSN of the page containing the initial BEGIN TRAN statement for the transaction, and, finally, time the transaction was started.
If you specify the TABLERESULTS option, this information is returned in two columns that you can load into a table for logging or comparison purposes. The NO_INFOMSGS option suppresses the display of the 'DBCC execution completed...' message. The following example runs DBCC OPENTRAN and inserts the results into a temp table:
CREATE TABLE #opentran_results
( result_label VARCHAR(30), result_value VARCHAR(46))
insert #opentran_results
exec ('dbcc opentran (bigpubs2008) WITH TABLERESULTS, no_infomsgs')
select * from #opentran_results
go
result_label result_value
---------------------------------------------------------------------------
OLDACT_SPID 57
OLDACT_UID -1
OLDACT_NAME add_titles
OLDACT_LSN (1926:203:1)
OLDACT_STARTTIME May 26 2009 12:20:10:407AM
OLDACT_SID 0xe6810e075514c744bc8d03b34c27b004
If no open transactions exist for the database, you receive the following message from DBCC OPENTRAN:
No active open transactions.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
DBCC OPENTRAN provides a means for you to
identify which transactions are potential problems, based on their
longevity. If you capture the process information at the same time,
using sp_who, you can identify who or what application is
causing the longest-running transaction(s). Using this information, you
can terminate the process, if necessary, or you can just have a quiet
word with the user if the query is ad hoc or with the application
developers if it is SQL code generated by a custom application.