SQLintersection Understanding Transaction Isolation Levels Randy Knight Wednesday, 3:45-5:00

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

© SQLintersection. All rights reserved. Overview  ACID Properties  ANSI Isolation Levels  READ COMMITTED  READ UNCOMMITTED  REPEATABLE READ  SERIALIZABLE  Versioning  SNAPSHOT ISOLATION LEVEL  Dangers of NOLOCK!

© SQLintersection. All rights reserved. ACID All Relational Databases  ATOMIC  CONSISTENT  ISOLATED  DURABLE

© SQLintersection. All rights reserved. Atomicity  Everything succeeds or nothing succeeds  Business Transaction  Classic Example: Transferring Funds Between Accounts

© SQLintersection. All rights reserved. Consistency  Data cannot be left in an inconsistent state  DBMS  According to all Business Rules  Business Rule Side is violated all over the place  Bugs  Incomplete and/or Inadequate Requirements

© SQLintersection. All rights reserved. Isolation  No transaction can interfere with any other transaction  Accomplished in one of two ways  Locking  Versioning  Also sometimes called multiversion concurrency  Snapshot isolation  RCSI

© SQLintersection. All rights reserved. Durability  Once a change is committed, it is permanent  Power Failure  Hardware Failure  User or Application Error

© SQLintersection. All rights reserved. Isolation Levels  ANSI Standard Levels  Level 0: Read Uncommitted  Level 1: Read Committed  Level 2: Repeatable Read  Level 3: Serializable  Snapshot / Versioning

© SQLintersection. All rights reserved. READ UNCOMMITTED  WITH (NOLOCK)  Can read Data that is “in-flight”  Has been modified but not committed  Could still be changing  Could be rolled back  “Dirty Reads”  i.e. “Who cares if it’s right”

© SQLintersection. All rights reserved. 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”

© SQLintersection. All rights reserved. REPEATABLE READ  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  Phantom Rows

© SQLintersection. All rights reserved. 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

© SQLintersection. All rights reserved. Versioning / Snapshot  Snapshot Isolation  Multi Version Concurrency  Two Levels  Statement Level (RCSI)  Transaction Level  Version Store Used to Maintain Committed Copy  Completely separate from writers  Does not block  No Shared Locks  This is the “snapshot”

© SQLintersection. All rights reserved. Statement Level Snapshot (RCSI)  ALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON  Becomes the default behavior of the database  Snapshot lives for the duration of a single statement  Can get inconsistent data in multi-statement transactions  Only guarantees consistency per statement  Great for long running statements  Large Data Sets  Reports  On or Off

© SQLintersection. All rights reserved. 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

Demo Impact of Isolation Levels

© SQLintersection. All rights reserved. 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)!

© SQLintersection. All rights reserved. Recommendations  Start with default behavior  Avoid READ UNCOMMITTED like the plague  If you think you need (nolock)  Implement snapshot

© SQLintersection. All rights reserved. Review  ACID Properties  ANSI Isolation Levels  READ COMMITTED  READ UNCOMMITTED  REPEATABLE READ  SERIALIZABLE  Versioning  SNAPSHOT ISOLATION LEVEL  Dangers of NOLOCK!

© SQLintersection. All rights reserved. References  White Papers  Row Versioning Based Isolation   Working with tempdb   Tempdb monitoring solutions   Twitter  #sqlhelp, #sqlblog

Don’t forget to complete an online evaluation on EventBoard! Your evaluation helps organizers build better conferences and helps speakers improve their sessions. Questions? Thank you! Understanding Transaction Isolation Levels Randy Knight