You can watch the replay for this Geek Sync webcast in the IDERA Resource Center: http://ow.ly/sbap50AJw6b Learn the good, the bad, and the ugly of blocking. Join IDERA and Hilary Cotter for this Geek Sync to understand how to monitor locking and blocking. The goals of this session are: -To discover what is the difference between locking, blocking and deadlocking -To understand how to minimize blocking during OLTP operations, batch processing, bulk inserts, and large scale deletes -To study how to use the appropriate isolation levels to reduce/increase blocking and partitioning and blocking Attend this webinar to detect, analyze, and minimize SQL Server blocking and locking. The session will also discuss what Snapshot and Read Committed Snapshot Isolation levels are all about and when you should use them. Finally, we will go over In-Memory Tables and learn how to monitor and troubleshoot blocking processes. Speaker: Hilary Cotter is a 20 year IT veteran who has answered over 20,000 questions on the forums. Some of them correctly. He specializes in HA technologies, especially replication, performance tuning, full-text search, and SQL Server Service Broker. Hilary is also an author, or contributor on a number of books on SQL Server.

1. SQL Server Locking and Blocking
Hilary Cotter
Hilary.cotter@gmail.com

2. • Thought Experiment
• How can I tell if blocking is a problem?
• How SQL Server works
• Transactions
• Isolation models
• Dirty Reads & Repeatable reads
• Snapshot Isolation Levels
• Hints
• In Memory
• Monitoring
Agenda

3. Thought experiment
• How long does blocking last for?
• Forever
• 20 seconds
• Until the blocking process resolves
• Until the transaction completes
• Unpredictable

4. How SQL Server works
• WAL
• Checkpoint
• 4 ms Quanta/Timeslice - wait stats are logged
• Processors
– SELECT * from sys.dm_os_schedulers where status='VISIBLE ONLINE’
• MAXDOP
• Runnable queue
– select * from sys.dm_exec_requests where session_id >= 50 and session_id
<> @@spid and status=‘suspended’;
• Waiting queue
– select * from sys.dm_os_waiting_tasks
• Running queue
– select * from sys.dm_exec_requests where session_id >= 50 and session_id
<> @@spid and status='running’

5. How SQL Server works
• Wait your turn
• We call this blocking
• Serialized ownership
• We call this locking
• Concurrency
• maximizes users
• Goal of every RDBMS

6. How SQL Server works
• Protecting a row to provide serial access
• Think checking account/selling a limited resource
• Seats
• Shoes
• How long?
• Set Lock_Timeout 30000 ( process will give up after waiting 30s), -1
waits forever

7. How can I tell if locking is a
problem?
• Deadlocking
• Applications timing out
• Slow/sluggish/unpredictable performance
• Large numbers of lock escalations
• Most common wait types are LCK_M_<lock type>
• Select * from sys.sysprocesses where blocked<>0
order by waittime desc
• Sp_who2
• Sp_whoIsActive

8. • Data Access
– Always serial and in isolation
– Minimum level of granularity
– row basis
– too expensive to do column level locking
• Demo
• Visual Studio
Data Access

9. Transactions
• Unit of work
• Think checking account (debit one account,
credit another).
• Begin tran(saction), rollback tran(saction),
commit tran(saction)
• Implicit and explicit

10. Transactions – lost updates
• Beware of lost updates – history of column values is not recorded
• Select quantity_on_hand where pk=1
• 60
• --correct (two simultaneous sessions)
• Update stock set quantity_on_hand= quantity_on_hand-50
• Update stock set quantity_on_hand= quantity_on_hand-40 --
should be a >0 constraint
• --incorrect (two simultaneous sessions)
• Update stock set quantity_on_hand=10—sold 50 (session 1)
• Update stock set quantity_on_hand=20—sold 40 (session 2)

11. Transactions – lost updates
• --better
• Select quantity_on_hand, dtstamp where pk=1
• 60, 2017-02-10 14:46:14.410
• Begin tran
• Update stock set quantity_on_hand=quantity_on_hand-
50, dtstamp=getdate()
• And dtstamp=‘2017-02-10 14:46:14.410’—sold 50
• If @@Rowcount=0
• Begin
• Raiserror…
• Rollback tran
• end

12. Deadlocking

13. Two types of concurrency models

14. Pessimistic Optimistic
Use Case Competition for same resource Little competition for same resource
Think Ticket Sales Think Wikipedia
Writers block readers and vice versa Writers don’t block readers, readers
don’t block writes, writers block writers
(conflict)
Ugly tempdb contention
Hidden column
minimizes concurrency Need to handle conflicts
Optimistic vs Pessimistic
Optimistic is the default for Azure SQL Database, and
AlwaysON

15. Isolation Levels
Allows you to
control the level
of isolation of
your data from
other
processes

16. • How sensitive your application is to changes made
by other users' transactions
• How long SQL Server must hold locks to protect
against these changes
1) Read Committed (default)
2) Read Uncommitted (maximizes concurrency at the
cost of accuracy)
3) Repeatable Read (the same data has the same
values, but may see new data)
4) Serializable (the same data has the same values, do
not see new data)
Isolation Levels

17. Isolation Levels
Transaction
Isolation Level
Dirty Read Non-Repeatable
Read
Phantoms Blocks other
transactions
Concurrency
Model
Read
Uncommitted
Yes Yes Yes No Pessimistic
Read Committed No Yes Yes Yes Pessimistic
Read Committed
(RSCI)
No Yes Yes No Optimistic
Repeatable Read No No Yes Yes Pessimistic
Snapshot No No No No Optimistic
Serializable No No No Yes Pessimistic

18. Isolation Levels
Transaction Isolation Level Lock Behavior Table Hint
Read Uncommitted (S) locks are not acquired NOLOCK
Read Committed S) locks are acquired and
released immediately
READCOMMITTED
Repeatable Read (S) locks are held until the end
of transaction
REPEATABLEREAD
Serializable Range (S) locks are held until
the end of transaction
HOLDLOCK
READ COMMITTED
SNAPSHOT, SNAPSHOT
(S) locks are not acquired
(except for FK checks)
No

19. Dirty Reads

20. Dirty Reads
• WAL
• Transactions written to log
• Pages in buffer are dirtied
• On checkpoint dirty pages are hardened to disk
• On server restart – last checkpoint is consulted
• transactions committed in log, but not on disk
are replayed on data files
• transactions not committed in log, but on disk
are removed from data files.
• Key to this is that a dirty read will read dirty
pages in the buffer. Minimal locking is held

21. Dirty Reads – why is this bad?
• Maximizing concurrency – at the cost of
consistency
• Reading data in flight
• Demo 1 – data movement with failure
(Msg 601, Level 12, State 3, Line 1
• Could not continue scan with NOLOCK due to
data movement.)
• Problem 2 missing rows
• Problem 3 additional rows (phantoms)

22. RCSI vs Snapshot
RCSI Snapshot
High Concurrency High Concurrency
Variant of Read Committed Variant of Serializable
Absolute accuracy when query starts and single statement Absolute accuracy when query starts and multi-statement
Ideal for ledger queries/reports Ideal for long running transactions
Only writer/writer blocking Only writer/writer blocking
Optimistic Reads and Optimistic writes Optimistic reads and Pessimistic writes
You get conflicts
Sees data at the state the statement started Sees data at the state when the transaction started
ALTER DATABASE AdventureWorks
SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE AdventureWorks SET
ALLOW_SNAPSHOT_ISOLATION ON;
SET TRANSACTION ISOLATION
LEVEL SNAPSHOT

23. Locking
• Lock types – row, page, table, application
• Lock modes
• shared - reading
• exclusive (X, full)– writing. Held till the end of a transaction
• update – used to find data to lock exclusively, will convert to X
• intent – used to tell the data engine that a process is going to
modify data. Must find the data to modify and claims it.
• schema stability – ensures that the schema does not change
during data modification or reads
• BU – bulk update locks
•

24. Lock Modes
Requested Lock Mode Existing Granted Lock Mode
IS S U IX X
Intent Shared (IS) Yes Yes Yes Yes No
Shared (S) Yes Yes Yes No No
Update (U) Yes Yes Yes No No
Intent Exclusive(IX) Yes No No No Yes
Exclusive(X) No No No No No
Lock Compatibility –
if Yes access
if no wait.

25. Lock Modes
• Sch-S: schema stability lock
• Sch-M: schema modification lock
• Range Locks (LCK_M_Range*) - Protect
interval of the rows in SERIALIZABLE isolation
• BU: bulk update lock

26. Lock Escalation• Row
• Page
• Extent
• Table

27. Disabling lock escalation
• Deactivate the escalation for the server by using the Trace
Flags:
• 1211 – Disables Lock Escalation completely – allows to use
60% of the allocated memory – if 60% of memory is used and
more locking is needed you will get an out-of-memory error.
• 1224 – Disables Lock Escalation until the memory threshold
of 40% allocated memory is reached – after that Lock
Escalation is enabled.
• ALTER TABLE – table option:
• SET ( LOCK_ESCALATION = { AUTO | TABLE | DISABLE } )
• SQL 2008 and above

28. Monitoring
• Now:
• sys.dm_tran_locks– currently lock requests
and their statuses•
• sys.dm_os_waiting_tasks– wait_type
(LCK_M_*), blocking_session_id•
• sys.dm_exec_requests– wait_type
(LCK_M_*), blocking_session_id
• Later: Analyze blocked process report.

29. Monitoring
• Extended Events
• Event Notifications

30. In Memory
• Uses a lock free algorithm
• Writes minimal data to tlog
• Can be configured not to survive a restart
• Indexes are in main memory and not
persisted to disk
• Durability
– schema only
– schema and data

31. In Memory
• Uses a lock free algorithm
• Writes minimal data to tlog
• Can be configured not to survive a restart
• Indexes are in main memory and not
persisted to disk
• Durability schema only
• schema and data

32. Trouble shooting using WaitStats
•
• Consult sys.dm_db_index_operational_stats, look at lock_count,
lock_wait_count, lock_wait_ms on row and page levels, look at lock
escalation statistics.
Wait Type Cause
LCK_M_SCH_* Index and/or partition maintenance, frequent schema modifications (app
issues)
LCK_M_I* Lock escalation, schema modifications (see LCK_M_SCH*)
LCK_M_RS* SERIALIZABLE transactions, IGNORE_DUP_KEY option in NCI
LCK_M_U Nonoptimized DML queries. Perform query tuning. Analyze transaction
managemen
LCK_M_S Nonoptimized SELECT queries. Perform query tuning. Consider RCSI to
hide the problem.

33. Reducing locking
• Minimize indexes
• Avoid clustered indexes on frequently updated columns
• Monitor page splits
• Use covering indexes
• Partitioning a contended table
• Optimize the queries
• minimize the transaction length/footprint
• Reduce the isolation level
• Set LockTimeout
• --danger – may not rollback transaction
• Use set xabort on
• Check transaction state – if @@Trancount>0 rollback
• Snapshot isolation