Search This Blog

2010-05-31

Different Isolation Level in SQL Server 2005

There are four types of isolation level as followsREAD UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE

Read uncommitted:When it's used, SQL Server not issue shared locks while reading data. So, you can read an uncommitted transaction that might get rolled back later. This isolation level is also called dirty read. This is the lowest isolation level. It ensures only that a physically corrupt data will not be read.

Read committed:This is the default isolation level in SQL Server. When it's used, SQL Server will use shared locks while reading data. It ensures that a physically corrupt data will not be read and will never read data that another application has changed and not yet committed, but it does not ensure that the data will not be changed before the end of the transaction.

Repeatable read:When it's used, the dirty reads and nonrepeatable reads cannot occur. It means that locks will be placed on all data that is used in a query, and another transactions cannot update the data.

Serializable:Most restrictive isolation level. When it's used, then phantom values cannot occur. It prevents other users from updating or inserting rows into the data set until the transaction is complete.

Nonrepeatable readWhen a transaction reads the same row more than one time, and between thetwo (or more) reads, a separate transaction modifies that row. Because therow was modified between reads within the same transaction, each readproduces different values, which introduces inconsistency.Nonrepeatable read—Nonrepeatable reads happen when a transaction performs the same query two or more times and each time the data is different. This is usually due to another concurrent transaction updating the databetween the queries.

Dirty read—Dirty reads occur when one transaction reads data that has been written but not yet committed by another transaction. If the changes are later rolled back, the data obtained by the first transaction will be invalid.

phantomPhantom behavior occurs when a transaction attempts to select a row thatdoes not exist and a second transaction inserts the row before the firsttransaction finishes. If the row is inserted, the row appears as a phantomto the first transaction, inconsistently appearing and disappearing.