Detailed explanation of MSSQL transaction isolation level (SET TRANSACTION ISOLATION LEVEL)

Controls locking and row versioning behavior for SQL Server statements issued by connections to Transact-SQL .

Topic link icon Transact-SQL syntax conventions

grammar

-- Syntax for SQL Server and Azure SQL Database

SET TRANSACTION ISOLATION LEVEL
    { READ UNCOMMITTED
    | READ COMMITTED
    | REPEATABLE READ
    | SNAPSHOT
    | SERIALIZABLE
    }

-- Syntax for Azure SQL Data Warehouse and Parallel Data Warehouse

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

parameter

READ UNCOMMITTED
specifies that the statement can read rows that have been modified by other transactions but not yet committed.

Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks, which prevent the current transaction from reading rows that have been modified but not yet committed by other transactions. When this option is set, uncommitted modifications can be read, which is called a dirty read. Values in the data can be changed and rows can appear or disappear from the dataset until the transaction ends. This option has the same effect as setting NOLOCK on all tables in all SELECT statements within a transaction. This is the least restrictive of the isolation levels.

In SQL Server, you can also use any of the following methods to minimize lock contention while protecting transactions from dirty reads of uncommitted data modifications:

READ COMMITTED isolation level and set the READ_COMMITTED_SNAPSHOT database option to ON.
SNAPSHOT isolation level.

READ COMMITTED
specifies that the statement cannot read data that has been modified by other transactions but not yet committed. This avoids dirty reads. Other transactions can change data between statements in the current transaction, resulting in non-repeatable reads and dummy data. This option is the default setting for SQL Server.

The behavior of READ COMMITTED depends on the setting of the READ_COMMITTED_SNAPSHOT database option:
If READ_COMMITTED_SNAPSHOT is set to OFF (the default setting), the database engine uses shared locks to prevent other transactions from modifying rows while the current transaction is performing a read operation. Shared locks also prevent statements from reading rows modified by other transactions until those transactions complete. The shared lock type determines when it will be released. Row locks are released before the next row is processed. Page locks are released when the next page is read, and table locks are released when the statement completes.

Remark

If READ_COMMITTED_SNAPSHOT is set to ON, the database engine uses row versioning to provide each statement with a transactionally consistent snapshot of the data as it existed at the beginning of the statement. Locks are not used to prevent other transactions from updating data.

Snapshot isolation supports FILESTREAM data. In snapshot isolation mode, FILESTREAM data read by any statement in a transaction will be a transactionally consistent version of the data that existed at the beginning of the transaction.

When the READ_COMMITTED_SNAPSHOT database option is set to ON, you can use the READCOMMITTEDLOCK table hint to request shared locks instead of row versioning for individual statements in transactions running at the READ COMMITTED isolation level.

Remark

When the READ_COMMITTED_SNAPSHOT option is set, only connections executing the ALTER DATABASE command are allowed in the database. No other open connections are allowed in the database until ALTER DATABASE has completed. The database does not have to be in single-user mode.

REPEATABLE READ
specifies that a statement cannot read rows that have been modified by other transactions but not yet committed, and specifies that no other transaction can modify data read by the current transaction until the current transaction completes.

A shared lock is set on all data read by each statement in the transaction, and the shared lock is held until the transaction completes. This prevents other transactions from modifying any rows read by the current transaction. Other transactions can insert new rows that match the search criteria of the statement issued by the current transaction. If the current transaction subsequently retries the statement, it retrieves the new row, resulting in a virtual read. Because shared locks are held until the end of the transaction, rather than being released at the end of each statement, the concurrency level is lower than the default READ COMMITTED isolation level. Use this option only when necessary.

SNAPSHOT
specifies that the data read by any statement in the transaction will be a transactionally consistent version of the data that existed at the beginning of the transaction. A transaction can only recognize data modifications committed before it started. Statements executed in the current transaction will not see data modifications made by other transactions after the current transaction began. The effect is as if the statements in the transaction get a snapshot of the committed data because that data existed at the beginning of the transaction.

SNAPSHOT transactions do not request locks when reading data unless the database is being recovered. A SNAPSHOT transaction that reads data does not prevent other transactions from writing data. Transactions that write data also do not prevent SNAPSHOT transactions from reading data.

During the rollback phase of database recovery, the SNAPSHOT transaction will request a lock if it attempts to read data locked by another transaction that is being rolled back. The SNAPSHOT transaction will block until the transaction is rolled back. The lock is released immediately after the transaction is authorized.

The ALLOW_SNAPSHOT_ISOLATION database option must be set to ON to start a transaction using the SNAPSHOT isolation level. If you use transactions at the SNAPSHOT isolation level to access data in multiple databases, you must set ALLOW_SNAPSHOT_ISOLATION to ON in each database.

Transactions started at other isolation levels cannot be set to the SNAPSHOT isolation level, as doing so will cause the transaction to abort. If a transaction started at the SNAPSHOT isolation level, it can be changed to another isolation level and then back to SNAPSHOT. A transaction starts when the data is accessed for the first time.

Transactions running under the SNAPSHOT isolation level can view changes made by that transaction. For example, if a transaction performs an UPDATE on a table and then issues a SELECT statement on the same table, the modified data will be included in the result set.

Remark

In snapshot isolation mode, FILESTREAM data read by any statement in a transaction will be a transactionally consistent version of the data that existed at the start of the transaction, not the start of the statement.

SERIALIZABLE
Please specify the following:

Statements cannot read data that has been modified by other transactions but not yet committed.
No other transaction can modify data read by the current transaction until the current transaction completes.
Other transactions cannot insert new rows with key values read by any statement in the current transaction until the current transaction is complete.

Scope locks are within the range of key values that match the search criteria of each statement executed in the transaction. This prevents other transactions from updating or inserting any rows, thereby qualifying any statements executed by the current transaction. This means that if any of the statements in the transaction are executed again, those statements read the same set of rows. The range lock will be held until the transaction completes. This is the most restrictive isolation level because it locks the entire range of keys and holds the range lock until the transaction completes. Because of the low level of concurrency, this option should only be used when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements within a transaction.

Remarks

Only one isolation level option can be set at a time, and the option set will remain in effect for that connection until the option is explicitly changed. All read operations performed within a transaction operate under the rules of the specified isolation level, unless a table hint in the statement's FROM clause specifies other locking or versioning behavior for the table.

The transaction isolation level defines the types of locks that can be acquired for read operations. Shared locks acquired for READ COMMITTED or REPEATABLE READ are usually row locks, although row locks can be escalated to page or table locks when the read references a large number of rows in the page or table. If a row is modified by a transaction after it was read, the transaction acquires an exclusive lock protecting the row, and the exclusive lock is held until the transaction completes. For example, if a REPEATABLE READ transaction has a shared lock on a row, and the transaction subsequently modifies the row, the shared row lock is converted to an exclusive row lock.

A transaction can be switched from one isolation level to another at any time during the transaction, with one exception. That is, when changing from either isolation level to SNAPSHOT isolation, the above operations cannot be performed. Failure to do so will cause the transaction to fail and be rolled back. However, transactions started in SNAPSHOT isolation can be changed to any other isolation level.

After a transaction is changed from one isolation level to another, the resources read after the change are protected according to the rules of the new level. Resources read before the change will continue to be protected according to the rules of the previous level. For example, if a transaction changes from READ COMMITTED to SERIALIZABLE, shared locks acquired after the change are held until the transaction ends.

If SET TRANSACTION ISOLATION LEVEL is issued in a stored procedure or trigger, when the object returns control, the isolation level is reset to the level in effect at the time the object was called. For example, if REPEATABLE READ is set in a batch, and the batch calls a stored procedure with the isolation level set to SERIALIZABLE, when the stored procedure returns control to the batch, the isolation level reverts to REPEATABLE READ.

Remark

User-defined functions and common language runtime (CLR) user-defined types cannot perform SET TRANSACTION ISOLATION LEVEL. However, the isolation level can be overridden using table hints. For more information, see Table Hints (Transact-SQL) .

When you bind two sessions using sp_bindsession, each session retains its own isolation level setting. Using SET TRANSACTION ISOLATION LEVEL to change a session's isolation level setting does not affect the settings of any other sessions bound to that session.

SET TRANSACTION ISOLATION LEVEL takes effect at execution or run time, not at analysis time.

Optimized bulk load operations against the heap block queries running under the following isolation levels:

SNAPSHOT
READ UNCOMMITTED
READ COMMITTED with row versioning

Instead, queries running below these isolation levels block optimized bulk load operations for the heap. For more information about bulk load operations, see Importing and Exporting Data in Bulk (SQL Server) .

The following transaction isolation levels are supported for FILESTREAM-enabled databases.

isolation level	Transact SQL access	file system access
uncommitted read	SQL Server 2017	not support
Submitted for read	SQL Server 2017	SQL Server 2017
repeatable read	SQL Server 2017	not support
Serializable	SQL Server 2017	not support
read committed snapshot	SQL Server 2017	SQL Server 2017
snapshot	SQL Server 2017	SQL Server 2017

Example

The following example is set for the session TRANSACTION ISOLATION LEVEL. For each subsequent Transact-SQL statement, SQL Server holds all shared locks until the end of the transaction.

USE AdventureWorks2012;  
GO  
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;  
GO  
BEGIN TRANSACTION;  
GO  
SELECT *   
    FROM HumanResources.EmployeePayHistory;  
GO  
SELECT *   
    FROM HumanResources.Department;  
GO  
COMMIT TRANSACTION;  
GO