eG Monitoring
 

Measures reported by MsSqlTransTest

This test reports the number of transactions active in an instance of the Database Engine, and the effects of those transactions on resources such as the snapshot isolation row version store in tempdb.

Transactions are logical units of work; a set of operations that must either all succeed or all be erased from a database in order to maintain the logical integrity of the data. All modifications of data in SQL Server databases are made in transactions.

When a database is set to allow snapshot isolation level, SQL Server must maintain a record of the modifications made to each row in a database. Each time a row is modified, a copy of the row as it existed before the modification is recorded in a row version store in tempdb. Many of the measures of the MsSqlTransTest monitor the size and rate of growth of the following row version stores in tempdb:

  • The online index build version store is used for online index builds in all databases.
  • The common version store is used for all other data modification operations in all databases.

Note:

This test reports measures only for Microsoft SQL Server version 2005 and above.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Free_space_in_tempdb Indicates the amount of space that is currently free in tempdb. KB There must be enough free space in tempdb to hold both the snapshot isolation level version store and all new temporary objects created in this instance of the Database Engine.

When the value of this measure decreases, the Database Engine forces the version stores to shrink. During the shrink process, the longest running transactions that have not yet generated row versions are marked as victims. A message 3967 is generated in the error log for each victim transaction. If a transaction is marked as a victim, it can no longer read the row versions in the version store. When it attempts to read row versions, message 3966 is generated and the transaction is rolled back. If the shrinking process succeeds, space becomes available in tempdb. Otherwise tempdb runs out of space and the following occurs:

  • Write operations continue to execute but do not generate versions. An information message (3959) appears in the error log, but the transaction that writes data is not affected.
  • Transactions that attempt to access row versions that were not generated because of a tempdb full rollback terminate with an error 3958.
Version_store_size Indicates the amount of space in tempdb that is currently being used to store snapshot isolation level row versions. KB This information helps determine the amount of space needed in the tempdb database for the version store. Monitoring this measure over a period of time provides a useful estimate of additional space needed for tempdb.
Version_generation_rate Indicates the rate at which new row versions are added to the snapshot isolation version store in tempdb. KB/Sec The values of the Version_generation_rate and Version_cleanup_rate measures can be used to predict tempdb space requirements.
Version_cleanup_rate Indicates the rate at which row versions are removed from the snapshot isolation version store in tempdb. KB/Sec Once every minute, a background thread removes row versions that are no longer needed and frees up the version space in tempdb. A long-running transaction prevents space in the version store from being released if it meets any of the following conditions:
  • It uses row versioning-based isolation
  • It uses triggers, MARS, or online index build operations
  • It generates row versions
Version_store_units Indicates the number of allocation units currently active in the snapshot isolation version store in tempdb. Number  
Version_store_units_creation Indicates the number of new version store units created in the version store since the last measurement period. Number  
Version_store_units_deletion Indicates the number of version store units that were truncated since the last measurement period. Number A version store unit is truncated when SQL Server determines that none of the version rows stored in the version store unit are needed to run active transactions.
Update_conflict_ratio Indicates the percentage of transactions using the snapshot isolation level that have encountered update conflicts within the last second. Percent An update conflict occurs when a snapshot isolation level transaction attempts to modify a row that last was modified by another transaction that was not committed when the snapshot isolation level transaction started.
Longest_trans_running_time Indicates the length of time since the start of the transaction that has been active longer than any other current transaction. Secs Row versions are stored in tempdb for as long as an active transaction needs to access it. If the value of this measure is very high, then it indicates that a transaction has been running for an unreasonable period of time, and is thus preventing the database engine from freeing space from tempdb. If the Free_space_on_tempdb measure touches alarmingly low levels, then you might have to identify the long running transaction and terminate it. Use fn_transactions() to identify the transaction.
Active_transactions Indicates the number of currently active transactions. Number This measure is a good indicator of the current workload on the database server.
Snapshot_transactions Indicates the number of currently active transactions using the snapshot isolation level. Number The value of this measure changes when the first data access occurs, not when the BEGIN TRANSACTION statement is issued. Also, note that this measure does not include system transactions.
Update_snapshot_transactions Indicates the number of currently active transactions using the snapshot isolation level that perform update operations. Number The sum of Update_snapshot_transactions and Non_snapshot_version_transactions represents the total number of transactions that participate in version generation. The difference of Snapshot_transactions and Update_snapshot_transactions reports the number of read-only snapshot transactions.
Non_snapshot_version_transactions Indicates the total number of currently active non-snapshot transactions that generate version records. Number
Temp_tables_creation Indicates the number of temporary tables/table variables created per second. Creations/sec Temporary tables are created in tempdb. They are backed by physical disk and are even logged into the transaction log. They act like regular tables in that you can query their data via SELECT queries and modify their data via UPDATE, INSERT, and DELETE statements. If created inside a stored procedure they are destroyed upon completion of the stored procedure. Furthermore, the scope of any particular temporary table is the session in which it is created; meaning it is only visible to the current user. You can create indexes and statistics on temporary tables. You can also apply Data Definition Language (DDL) statements against temporary tables to add constraints, defaults, and referential integrity such as primary and foreign keys. You can also add and drop columns from temporary tables.

The syntax for creating table variables is quite similar to creating either regular or temporary tables. The only differences involve a naming convention unique to variables in general, and the need to declare the table variable as you would any other local variable in Transact SQL.

Unlike temporary or regular table objects, table variables have certain clear limitations.

  • Table variables can not have Non-Clustered Indexes
  • You can not create constraints in table variables
  • You can not create default values on table variable columns
  • Statistics can not be created against table variables

Temporary tables are usually preferred over table variables for a few important reasons: they behave more like physical tables in respect to indexing and statistics creation and lifespan.