Scribd
Upload
130 views

Transaction Isolation Level

Transactions in SQL Server occur within transaction isolation levels that control locking and concurrency. There are different types of locks that protect shared resources and ensure reliable transactions. Issues can arise from lock contention, long-term blocking when locks are held too long, and deadlocks between dependent transactions. Transaction isolation levels determine how transactions accept inconsistent data from "dirty reads" or other transactions, ranging from read uncommitted to serializable isolation.

Uploaded by

rajakumari
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
130 views

Transaction Isolation Level

Transactions in SQL Server occur within transaction isolation levels that control locking and concurrency. There are different types of locks that protect shared resources and ensure reliable transactions. Issues can arise from lock contention, long-term blocking when locks are held too long, and deadlocks between dependent transactions. Transaction isolation levels determine how transactions accept inconsistent data from "dirty reads" or other transactions, ranging from read uncommitted to serializable isolation.

Uploaded by

rajakumari
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

TRANSACTION ISOLATION LEVEL:

Controls transactions & behavior in SQL server . Everything happens in SQL Server in terms of
transactions.

 DB locking
 Concurrency, locking that occurs in DB , how locking can lead to blocking , how to troubleshoot
blocking issues.

Why DBs lock?

Serves to protect shared resources or objects.

Types of Locks:

 Shared Locks
 Exclusive Locks
 Transaction Locks
 DML Locks
 Backup- Recovery Locks

Transactional Locking:

Relates to the ability of DBMS to ensure reliable transactions that adhere to ACID properties.

Issues that can occur:

1. LOCK CONTENTION ( Hot Locks)


When many DB sessions require frequent access to the same lock.
2. LONG TERM BLOCKING:
One session does not release the lock immediately. The lock is held for long time & while
that lock is held, all dependant sessions will be blocked.
3. DATABASE DEADLOCKS:
When two or more transactions hold dependant locks & neither can continue until the other
releases.

Transaction Isolation:

Level at which the transaction is prepared to accept inconsistent data.

Eg., Dirty Read- Cheating on a test

Types of Transaction Isolation Levels:

 Read Uncommitted
 Read Committed
 Repeatable Read
 Snapshot
 Serializable
Read Uncommitted:

 Allows dirty reads and phantom reads.


 Lets a transaction read any data currently on a data page , whether or not that data has been
committed.
 Eg., If we specify this in transaction 1, the transaction 2 can read the data that has been
modified by transaction 1 but yet not committed.

Read Committed:

 Default isolation level


 Does not allow dirty read and phantom read. i.e., we can never read uncommitted data
 Transaction 2 can read the data that has been modified by transaction 1 and committed.

Repeatable Read:

 If we want the Read operations to be repeatable, we can choose this isolation level.
 Issuing the same query twice within a transaction won’t pickup any changes to data values that
another user’s transaction has made.
 No other user can modify the data that your transaction visits as long as you have not yet
committed or rolled back your transaction.

Snapshot:

 Here, the transaction 2 will read only the data that has been the state of the data before the
transaction 1 started.
 So, it will get the snapshot of the data before the transaction 1 started.
 So, the transaction 2 can get the snapshot before any modifications done.

Serializable:

 High level of Isolation level


 Ensures all transactions are completely isolated from each other.
 Ensures that if a query is reissued, no data will have changed and no new rows will appear in
the interim. In other words, you won't see phantoms if the same query is issued twice within a
transaction.

You might also like