Mark Broadbent Principal Consultant SQLCloud SQLCLOUD.CO.UK

Size: px

Start display at page:

Download "Mark Broadbent Principal Consultant SQLCloud SQLCLOUD.CO.UK"

Jonah Carter
5 years ago
Views:

1 lock, block & two smoking barrels Mark Broadbent Principal Consultant SQLCloud SQLCLOUD.CO.UK

Certified Master/ Certified Solutions Master: SQL Server Microsoft Data

2 About Mark Broadbent. 30 billion times more intelligent than a live mattress Microsoft Certified Master/ Certified Solutions Master: SQL Server Microsoft Data Platform MVP Owner/ Principal at SQLCloud mark.broadbent@sqlcambs.org.uk Twitter: Blog: Event Lead to the UK s first ever SQLSaturday (Cambridge) Event #4 in Sept 2016 (pre-cons & Community day)

3 Agenda X X 1 Theory 2 Locking 3 Isolation 4 Optimistic Concurrency 5 The best part of the presentation Gin O Clock

4 Theory (aka whatcha talkin bout Willis)

5 A C I D

6 Transaction Log the D in ACID Log Buffer 1 Log Buffer n Log writes are first written to log buffers. Flush on fill or on commit. Control returned to spid on commit. Log file (.ldf) async Log Writer Signal to flush Delayed Durability is a compromise. VLF header Log file Header Version FseqNo Size Log Block Header Record 1 Record 2 Record n Slot Array 512 bytes to 60KB Virtual Log Files (VLFs) Inactive VLFS Record has unique LSN LSN has 3 part name consisting of: VLF Number + Log Block Offset + Slot Number Log growth size <=64MB then 4 VLFs > 64MB AND <= 1GB 8 VLFs > 1GB 16 VLFS Think about how big your log needs to be from the beginning

7 Concurrency-versus-Correctness 1st law of Concurrency Control: Concurrent execution should not cause application programs to malfunction. 2nd law of Concurrency Control: Concurrent execution should not have lower throughput or much higher response times than serial execution. Jim Gray and Andreas Reuter I s o l a t i o n i s a b a l a n c e b e t w e e n c o n c u r r e n c y a n d c o r r e c t n e s s Me *1 *1 derived from the writings of Gray, Reuter, Bernstein et.al

8 Serial Processing Read R 1 Read R 2 Write R 3 Read R 1 Read R 2 Write R 3 T 1 T 2 Read R 4 Write R 4 Read R 4 Write R 4 T 3 T 4

Transaction Interleaving Order 1 Order 2 Order 3 Order 4 Order 5 T 1 Read R 1 T 1 Read R 2 T 1 Write R 3 T 2 Read R 1 T 2 Read R 2 T 2 Write R 3 T 3 Read R 4 T 3 Write R 4 T 4 Read R 4 T 4 Write R 3

9 Transaction Interleaving Order 1 Order 2 Order 3 Order 4 Order 5 T 1 Read R 1 T 1 Read R 2 T 1 Write R 3 T 2 Read R 1 T 2 Read R 2 T 2 Write R 3 T 3 Read R 4 T 3 Write R 4 T 4 Read R 4 T 4 Write R 3 T 2 Read R 1 T 2 Read R 2 T 2 Write R 3 T 1 Read R 1 T 1 Read R 2 T 1 Write R 3 T 4 Read R 4 T 4 Write R 3 T 3 Read R 4 T 3 Write R 4 T 1 Read R 1 T 1 Read R 2 T 2 Read R 1 T 2 Read R 2 T 1 Write R 3 T 2 Write R 3 T 3 Read R 4 T 3 Write R 4 T 4 Read R 4 T 4 Write R 3 T 1 Read R 1 T 1 Read R 2 T 2 Read R 1 T 2 Read R 2 T 2 Write R 3 T 1 Write R 3 T 3 Read R 4 T 3 Write R 4 T 4 Read R 4 T 4 Write R 4 T 1 Read R 1 T 1 Read R 2 T 2 Read R 1 T 2 Read R 2 T 1 Write R 3 T 2 Write R 3 T 3 Read R 4 T 4 Read R 4 T 3 Write R 4 T 4 Write R 4

Transactional Histories T 1 Read R 1 T 1 Read R 2 T 2 Read R 1 T 2 Read R 2 T 1 Write R 3 T 2 Write R 3 T 3 Read R 4 T 4 Read R 4 T 3 Write R 4 T 4 Write R 4 T 1 SLOCK R 1 T 1 Read R 1 T 1 UNLOCK R 1

10 Transactional Histories T 1 Read R 1 T 1 Read R 2 T 2 Read R 1 T 2 Read R 2 T 1 Write R 3 T 2 Write R 3 T 3 Read R 4 T 4 Read R 4 T 3 Write R 4 T 4 Write R 4 T 1 SLOCK R 1 T 1 Read R 1 T 1 UNLOCK R 1 T 1 SLOCK R 2 T 2 SLOCK R 1 T 2 Read R 1 T 1 Read R 2 T 2 UNLOCK R 1 T 2 SLOCK R 2 T 2 Read R 2 T 1 UNLOCK R 2 T 2 UNLOCK R 2 T 1 XLOCK R 3 T 1 Write R 3 T 1 UNLOCK R 3 T 2 XLOCK R 3 T 2 Write R 3 T 2 UNLOCK R 3 A transaction is considered Two-Phased if all LOCK actions precede an UNLOCK action A transaction is considered to be Well- Formed if all READ, WRITE and UNLOCK operations are covered by a preceding LOCK. Isolation mechanism has serialized these transactional writes to same resource

11 Locking (aka what the blockin hell!)

12 Locks Are compatible OR incompatible with each other Are ONLY memory structures (lock blocks) and long blocking chains can consume a lot of memory Compared by lock manager across same resource or lock partition They can be converted or escalated Poor queries cause less granular locks or escalation of locks For performance and memory savings Increases chances of blocking and deadlocks which cause perceived OR actual poor performance! Is why developers love NOLOCK

13 (U)pdate lock a special kind of lock UPDATE orders SET status = 1 WHERE id > 1 AND id < 4 SEARCH PHASE spid 115 id orders status 1 0 spid 162 UPDATE orders SET status = 1 WHERE id > 1 AND id < 3 UPDATE PHASE Lock Conversion X X Lock will be blocked! 4 0 S U X S U X

14 Isolation (aka nobody loves me)

15 Isolation Levels Isolation Level Bad Dependencies X Dependencies Concurrency 1 READ UNCOMMITTED Dirty Read, Non-Repeatable Read, Phantoms, Lost Updates WRITE WRITE GOOD: only wait on write-write locks 2 READ COMMITTED Non-Repeatable Read, Phantoms, Lost Updates WRITE WRITE READ WRITE WRITE READ OK: wait on both but only writes held to EOT 2 READ COMMITTED (with Snapshot Isolation) Non-Repeatable Read, Phantoms, Lost Updates WRITE WRITE GOOD: only wait on writes held to EOT 3 REPEATABLE READ Phantoms WRITE WRITE READ WRITE WRITE READ LOW: read and write locks held to EOT 4 SERIALIZABLE None WRITE WRITE WRITE READ READ WRITE LOWEST: read and write locks held to EOT 5 SNAPSHOT None (though Causal consistency concerns, lost update prevention and other behaviours) WRITE WRITE GOOD: only wait on writes held to EOT

16 Isolation Levels Attempt to solve reduce interleaving dependency problems 4 Levels are defined standard by ANSI, SQL introduced 5th Not all Isolation Levels can be used everywhere FILESTREAM enabled databases support only RC, RCS and SI Set at session level, transaction level and statement Sometimes used behind the covers (such as Readable Secondaries and In-Memory OLTP)

17 Read Committed Lost Updates? INT = 1 INT BEGIN TRANSACTION = quantity FROM GunInventory WITH (NOLOCK) WHERE id = 1 UPDATE GunInventory SET quantity WHERE id = 1 COMMIT

18 Demo Pessimistic isolation

19 Optimistic Concurrency (aka sharks with frikken lasers!)

20 Row Versioning Row data 14 Bytes T2 UPDATE x=4 COMMIT Row Pointer XSN 1 6 A 9925 T1 UPDATE x=2 COMMIT Version 1 4 B 9910 Version created on statement execution not transaction commit. Version 1 2

21 Read Committed Snapshot vs Snapshot Isolation SI provides isolation at the transaction level, RCS provides isolation at the statement level SI implements automatic update conflict detection don t forget to use error handling! SI must be explicitly SET in each connection, for RCS it becomes the new default Enabling SI level requires no active transactions in order to transition. Enabling RCS requires Exclusive Transaction Workspace lock (and therefore no other connections to DB) RCS not allowed on master, tempdb and msdb, SI is allowed READPAST & Furious: In defence of being Pessimistic Mark Broadbent sqlcloud.co.uk

22 Disk Based Table Optimistic Concurrency #FAIL Snapshot Isolation introduces Update conflicts (not quite true in reality it doesn t cause and instead provides detection!) Causal *1 consistency behaviours and no serializable guarantees TempDB version-store overhead Increased IOPS for version creation Tree Traversal Long running transactions can result in large version chains Page Fragmentation and 14 byte version pointer Writers use e(x)clusive locks Which still block other writers And could still escalate *1 At least that is what I believe it is called (i.e. causal consistency). See A Read-Only Transaction Anomaly Under Snapshot Isolation By Alan Fekete, Elizabeth O'Neil, and Patrick O'Neil And Craig Freadman s blog

23 Are you Pessimistic about being Optimistic? Being pessimistic means that I expect lots of contention, I must prevent concurrent access. Being optimistic means: I do not expect resource contention, so lets not overburden the system with concurrency controls. Consider: Proper use of indexing strategy Keep Transactions short lived Avoid escalation (in the wrong situation) Avoid higher ISOLATION LEVELS Make an intelligent use of SQL Server Scalability

24 Demo Optimistic isolation

25 Further Reading

26 In Summary (what we have learnt today) Interleaving and concurrent execution is why isolation is required Isolation and bad dependencies determined by the ISOLATION Level But static read-only data does not require isolation RCSI is perhaps the best optimistic compromise but has overheads Snapshot Isolation is almost conceptually a perfect Isolation level but practically dangerous because It does not offer SERIALIZABLE protection Optimistic isolation is not a silver bullet for Concurrency But in the right situation In-Memory OLTP sure can help

27 Thank you for listening! Twitter: retracement Blog: Slideshare:

Into into Locking and Blocking. Dmitri Korotkevitch (http://aboutsqlserver.com) 1

Into into Locking and Blocking Dmitri Korotkevitch (http://aboutsqlserver.com) 1 About me 20 years of experience in IT 14+ years of experience working with Microsoft SQL Server Microsoft SQL Server MVP