Are You OPTIMISTIC About Concurrency?

Size: px

Start display at page:

Download "Are You OPTIMISTIC About Concurrency?"

Everett Gilmore
5 years ago
Views:

Are You OPTIMISTIC About Concurrency? SQL Saturday #399 Sacramento July 25, 2015 Kalen Delaney www.sqlserverinternals.

1 Are You OPTIMISTIC About Concurrency? SQL Saturday #399 Sacramento July 25, 2015 Kalen Delaney Kalen Delaney Background: MS in Computer Science from UC Berkeley Working exclusively with SQL Server for almost 28 years Server In-Memory OLTP Internals (RedGate 2014) Primary Author: SQL Server 2012 Internals (MS Press/O Reilly, 2013) Author: SQL Server Concurrency (RedGate 2010) Primary Author: SQL Server 2008 Internals (MS Press, 2009) Primary Author: Inside SQL Server 2005: Query Tuning and Optimization (MS Press, 2007) Author: Inside SQL Server 2005: The Storage Engine (MS Press, 2006) SQL Server Magazine columnist and contributing editor Website: Blog: 2 1

2 Abstract What exactly does it mean to have optimistic concurrency? What is the alternative? Is SQL Server 2012's SNAPSHOT Isolation optimistic? How can SQL Server 2014's In-Memory OLTP provide truly optimistic concurrency? In this session, we'll look at what guarantees the various isolation levels provide, the difference between pessimistic and optimistic concurrency, and the new data structures in SQL Server 2014 that allow the enormous benefits of having totally in-memory storage with no waiting! 3 Main Topics Isolation Levels and Concurrency Models Pessimistic Concurrency Optimistic Concurrency with In-Memory OLTP 4 2

3 Isolation Levels and Concurrency Models Consistency Guarantees Bad Dependencies Isolation Levels Concurrency Models 5 Consistency Guarantees Read Stability Phantom Avoidance 6 3

4 Bad Dependencies Lost Updates Dirty Reads Non-repeatable Reads Phantoms 7 Isolation Levels Isolation Levels READ UNCOMMITTED READ COMMITTED 1 Locking 2 Snapshot SNAPSHOT Dirty Read Phenomena Allowed Non- Repeatable Read Phantoms Update Conflict Yes Yes Yes No No No No Yes Yes No (but not read stability) Yes Yes Yes (but not visible) No No Yes REPEATABLE READ No No Yes No SERIALIZABLE No No No No 8 4

5 Concurrency Models Pessimistic Concurrency Optimistic Concurrency SQL Server SNAPSHOT ISOLATION options are not fully optimistic 9 Pessimistic Concurrency Locks are used to guarantee consistency Changes to isolation level affect: Lock conflicts Duration of locks Type of locks 10 5

6 11 Optimistic Concurrency No locks needed Data in existing rows is never changed Updates are implemented as DELETE + INSERT DELETE changes end-timestamp of row No latches needed for In-memory OLTP No pages used! Internal lock table not needed 12 6

7 In-Memory OLTP Table Storage Hash Table for Name E 20 Elizabeth San Francisco $80K J 10 John Charlotte $50K 30 Jane N.Y. $75K 13 Multiversioning Hash Table for Name E 20 Xb Elizabeth San Francisco $80K Xb Elizabeth San Francisco $90K 14 7

8 Consistency Validation Only three isolation levels possible Snapshot Isolation No validation required Fail immediately if conflict occurs Repeatable Read Verify Read Stability Serializable Verify Read Stability Confirm Phantom Avoidance 15 Validation Requirements During Processing, In-Memory OLTP maintains: Read-set Write-set Scan-set End-timestamp of transaction acquired before validation starts 16 8

9 Validating Read Stability Confirm that each row version in read-set is still visible during validation using end-timestamp 17 Confirming Phantom Avoidance Repeat each scan checking whether new versions have become visible since transaction began Not as expensive as it might seem: All rows are in memory Re-resolving of scan-set can be simplified Only done for transactions in serializable isolation Less expensive than range locking 18 9

10 19 Summary Isolation Levels and Concurrency Models Pessimistic Concurrency Optimistic Concurrency with In-Memory OLTP 20 10

11 21 11

What the Hekaton? In-memory OLTP Overview. Kalen Delaney

What the Hekaton? In-memory OLTP Overview Kalen Delaney www.sqlserverinternals.com Kalen Delaney Background: MS in Computer Science from UC Berkeley Working exclusively with SQL Server for 28 years SQL