1. Understanding Transaction Isolation Levels
Randy Knight
January 14, 2017

2. Randy Knight Microsoft Certified Master
20+Years of database experience, focusing on SQL Server since 1997.
Worked in a variety of settings, including six years as a Database Architect for match.com
Founder, SQL Solutions Group

3. Objectives ACID Properties ANSI Isolation Levels Versioning
READ COMMITTED
READ UNCOMMITTED
REPEATABLE READ
SERIALIZABLE
Versioning
SNAPSHOT ISOLATION LEVEL
Dangers of NOLOCK!
Don’t Press the Turbo Button!

4. ACID
Atomic
Consistent
Isolated
Durable

5. Atomicity Everything succeeds or nothing succeeds Business Transaction
Classic Example: Transferring Funds Between Accounts

6. Consistency Data cannot be left in an inconsistent state SQL Server
DBMS
Business Rules
SQL Server
Datatypes
Constraints (Check and FK)
Triggers
Other?

7. Isolation No transaction can interfere with any other transaction
Accomplished in one of two ways
Locking
Versioning
Also sometimes called multi-version concurrency
Snapshot isolation
RCSI

8. Durability Once a change is committed, it is permanent Power Failure
Hardware Failure
Transaction is Hardened

9. Isolation Levels ANSI Standard Levels Snapshot / Versioning TSQL
Level 0: Read Uncommitted
Level 1: Read Committed
Level 2: Repeatable Read
Level 3: Serializable
Snapshot / Versioning
TSQL
SET TRANSACTION ISOLATION LEVEL …

10. Lock Types Shared Exclusive Update Reads
Multiple connections at the same time
Exclusive
Writes
One connection at a time
Update
Intended Write
One Connection at a time

11. READ UNCOMMITTED WITH (NOLOCK) Query Directive
Can read Data that is “in-flight”
Has been modified but not committed
Could still be changing
Could be rolled back
NOLOCK is not really “No locks”
DML requires exclusive locking
Reads Still take a SCH-S lock
“Dirty Reads”
i.e. “Who cares if it’s right”

12. READ COMMITTED Default Behavior Only committed data is readable
Locks are released as data is read
Only have a lock on a page long enough to read that page
Not repeatable
Data may have changed since it was last read
Sometimes known as “non-repeatable reads”

13. REPEATABLE READS
Holds Shared Locks throughout the life of the transaction
Guaranteed consistent data for your entire result set
LOTS of blocking
Because we don’t release locks, rows can be “repeatably read”
Doesn’t guarantee new data won’t enter your set during the transaction

14. SERIALIZABLE Lock the entire set
Prevents new rows from entering the set
Tremendous Amount of Blocking
Quite Often Can Be a Table Lock
Filtered Indexes Can Help This

15. Optimistic vs. Pessimistic Concurrency
Readers Block Readers
Readers Block Writers x
Writers Block Readers
Writers Block Writers

16. Versioning Snapshot Isolation Multi Version Concurrency Two Levels
Statement Level
Transaction Level
Version Store Used to Maintain Committed Copy
Completely separate from writers
Does not block
No Shared Locks
This is the “snapshot”

17. Statement Level Snapshot
ALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON
Becomes the default behavior of the database
Snapshot lives for the duration of a single statement
Only guarantees consistency per statement
Great for long running statements
Large Data Sets
Reports

18. Transaction Level Snapshot
SET ALLOW_SNAPSHOT_ISOLATION ON
Turns on versioning
Default will still use locking
Key word is ALLOW
User can request snapshots
SET TRANSATION ISOLATION LEVEL SNAPSHOT
Data will be consistent throughout the entire transaction

19. Snapshot States RCSI ALLOW_SNAPSHOT No Snapshots (default behavior)
Statement Level Only x
Both
Transaction Level Only

20. Why not always use Snapshot?
No such thing as a free lunch
Version Store is in tempdb
Need to tune and monitor tempdb
Maybe not “always” but should be used a LOT more than it is now
Eradicate (NOLOCK)!

21. Recommendations Start with default behavior
Avoid READ UNCOMMITTED like the plague
If you think you need (nolock)
Test RCSI with your workload

22. Demo
Impact of different Isolation Levels
Dangers of NOLOCK

23. Resources White Papers Twitter Row Versioning Based Isolation
Working with tempdb
Tempdb monitoring solutions
Twitter
#sqlhelp, #sqlpass, #sqlblog, #sqlsat
@randy_knight

24. Thank You! Randy Knight SQL Solutions Group (801) 285-0251
Linked In:
Twitter: randy_knight
Skype: randy.knight2