DEEP INTO

ISOLATION LEVELS

Boris HristovSQLBits, Superheroes, 2015

That’s not a Hekaton Talk! (In-Memory OLTP)

So who am I?

@BorisHristov

Isolation Levels time

com

ple

xity

Fundamentals

?

Session’s Timeline

The Fundamentals

Pessimistic Concurrency Optimistic Concurrency

Locks

Blocking

Versions

Version Store

Update Conflicts

Locks

Locking

Blocking

Deadlocks

Lock Escalations

Common lock types

Intent

Used for: Preventing incompatible locksDuration: End of the transaction

Shared (S)

Used for: ReadingDuration: Released almost immediately

(depends on the isolation level)

Update (U)

Used for: Preparing to modifyDuration: End of the transaction or until

converted to exclusive (X)

Exclusive (X)

Used for: ModifyingDuration: End of the transaction

Lock Compatibility

Lock Shared Update Exclusive

Shared (S) X

Update (U) X X

Exclusive (X) X X X

Lock Hierarchy

Database

Table

Page

Row

Let’s update a row. What do we need?

USE AdventureWorks2012GOUPDATE [Person].[Address]SET AddressLine1=‘London, UK'WHERE AddressID=2

S

IX

Header

Row

Row

Row

Row

Row

IX

X

A query!

Methods to View Locking Information

Dynamic Management

Views

SQL Server Profiler or

Extended Events

Performance monitor or Activity

Monitor

DEMO Locking and Locking Hierarchies

Transaction isolation levels(pessimistic concurrency)

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED (NOLOCK?)

Transaction 1

Transaction 2

Suggestion: Better offload the reads or go with optimistic level concurrency!

Select

Update

eXclusive lock

Read Uncommitted(pessimistic concurrency control)

Dirty read

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

Transaction 1 rows

Non-repeatable reads possible (updates during Transaction 1)

Phantom records possible (inserts during Transaction 1)

What else? (that’s a Pluralsight voucher right here!)

Updates and Inserts

Transaction 2

Read Committed(pessimistic concurrency control)

S

S

S

S

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

Transaction 1 S(hared) lock

select

No non-repeatable reads possible (updates during Transaction 1)

Phantom records still possible (inserts during Transaction 1)

Update

Transaction 2

Repeatable Read(pessimistic concurrency control)

Transaction 1 S(hared) lock

select

Even phantom records are not possible!

Highest pessimistic level of isolation, lowest level of concurrency

Oh, yeah, TransactionScope in C# and MSDTC transactions default to this level too

Insert

Transaction 2

Serializable(pessimistic concurrency control)

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

DEMO Playing with Isolation levels (Pessimistic Concurrency)

Transaction isolation levels(optimistic concurrency)

Read Committed and Snapshot Isolation levels

RCSI – Read Committed Snapshot Isolation Level

Statement level versioning

Requires ALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON

Snapshot Isolation Level

Transaction level versioning

Requires ALTER DATABASE SET ALLOW_SNAPSHOT_ISOLATION ON

Requires SET TRANSACTION ISOLATION LEVEL SNAPSHOT

V1 V2Transaction 1

Transaction 2

Select in RCSISelect

Select in SI

DEMO Playing with Isolation levels (Optimistic Concurrency)

… and Azure DB too

Just before we end…

Isolation levels can have dramatic impact on your application

As such, isolation levels must also be a business decision

The behavior of the readers changes in the various levels

Writers, though, will always block. No matter what!

And one more thing – please be careful with ORMs

Summary

Thank you!

Contacts:brshristov@live.comwww.borishristov.com@BorisHristov