1. SQLintersection Understanding Transaction Isolation Levels Randy Knight randy@sqlsolutionsgroup.com Wednesday, 3:45-5:00

2. © SQLintersection. All rights reserved. http://www.SQLintersection.com Randy Knight  Microsoft Certified Master in SQL Server  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. © SQLintersection. All rights reserved. http://www.SQLintersection.com Overview  ACID Properties  ANSI Isolation Levels  READ COMMITTED  READ UNCOMMITTED  REPEATABLE READ  SERIALIZABLE  Versioning  SNAPSHOT ISOLATION LEVEL  Dangers of NOLOCK!

4. © SQLintersection. All rights reserved. http://www.SQLintersection.com ACID All Relational Databases  ATOMIC  CONSISTENT  ISOLATED  DURABLE

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

6. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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

7. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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

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

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

10. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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”

11. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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”

12. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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

13. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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

14. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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”

15. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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

16. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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

17. Demo Impact of Isolation Levels

18. © SQLintersection. All rights reserved. http://www.SQLintersection.com 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)!

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

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

21. © SQLintersection. All rights reserved. http://www.SQLintersection.com References  White Papers  Row Versioning Based Isolation  http://msdn.microsoft.com/en-us/library/ms345124(v=sql.90).aspx http://msdn.microsoft.com/en-us/library/ms345124(v=sql.90).aspx  Working with tempdb  http://technet.microsoft.com/en-us/library/cc966545.aspx http://technet.microsoft.com/en-us/library/cc966545.aspx  Tempdb monitoring solutions  http://www.sqlservercentral.com/articles/tempdb+utilization/65149/ http://www.sqlservercentral.com/articles/tempdb+utilization/65149/  Twitter  #sqlhelp, #sqlblog  @randy_knight  @SQLGroup

22. 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