are you optimistic about concurrency - wordpress.com · 2016. 10. 8. · 2016-10-08 2 08.10.2016...
TRANSCRIPT
2016-10-08
1
08.10.2016 SQLSaturday #555 Munich 2016
Are You OPTIMISTIC About Concurrency?
Isolation Levels with SQL Server In-Memory OLTP
Kalen Delaneywww.SQLServerInternals.com
08.10.2016 SQLSaturday #555 Munich 2016
Our Sponsors
2016-10-08
2
08.10.2016 SQLSaturday #555 Munich 2016
Kalen DelaneyBackground:
MS in Computer Science from UC Berkeley Working exclusively with SQL Server for 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: www.SQLServerInternals.comTwitter: @sqlqueenBlog: www.SQLBlog.com
08.10.2016 SQLSaturday #555 Munich 2016
AbstractWhat 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!
2016-10-08
3
08.10.2016 SQLSaturday #555 Munich 2016
Main Topics
Isolation Levels and Concurrency Models
Pessimistic Concurrency
Optimistic Concurrency with In-Memory OLTP
08.10.2016 SQLSaturday #555 Munich 2016
Isolation Levels and Concurrency Models
Consistency Guarantees
Bad Dependencies
Isolation Levels
Concurrency Models
2016-10-08
4
08.10.2016 SQLSaturday #555 Munich 2016
Consistency Guarantees
Read Stability
Phantom Avoidance
08.10.2016 SQLSaturday #555 Munich 2016
Bad Dependencies
Lost Updates
Dirty Reads
Non-repeatable Reads
Phantoms
2016-10-08
5
08.10.2016 SQLSaturday #555 Munich 2016
Isolation LevelsPhenomena Allowed
Isolation LevelsDirty Read
Non-Repeatable Read Phantoms Update
Conflict
READ UNCOMMITTED Yes Yes Yes No
READ COMMITTED
1 Locking2 Snapshot
NoNo
YesYes
YesYes
NoNo
SNAPSHOT No No (but not read stability)
Yes (but not visible) Yes
REPEATABLE READ No No Yes No
SERIALIZABLE No No No No
08.10.2016 SQLSaturday #555 Munich 2016
Concurrency Models
Pessimistic Concurrency
Optimistic Concurrency
SQL Server 2005-2012 SNAPSHOT ISOLATION options are not fully optimistic
2016-10-08
6
08.10.2016 SQLSaturday #555 Munich 2016
Pessimistic Concurrency
Locks are used to guarantee consistency Changes to isolation level affect: Lock conflicts Duration of locks Type of locks
08.10.2016 SQLSaturday #555 Munich 2016
2016-10-08
7
08.10.2016 SQLSaturday #555 Munich 2016
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
08.10.2016 SQLSaturday #555 Munich 2016
In-Memory OLTP Table Storage
Hash Table for Name
E Elizabeth San Francisco $80K20 ∞
John Charlotte $50K∞10J
Jane N.Y. $75K30 ∞
2016-10-08
8
08.10.2016 SQLSaturday #555 Munich 2016
Multiversioning
E Elizabeth San Francisco $80K20 ∞
ElizabethElizabeth San FranciscoSan Francisco $90K$90KElizabeth San Francisco $90K∞
Xb
Xb
Hash Table for Name
08.10.2016 SQLSaturday #555 Munich 2016
Consistency ValidationOnly 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
2016-10-08
9
08.10.2016 SQLSaturday #555 Munich 2016
Validation Requirements
During Processing, In-Memory OLTP maintains: Read-set Write-set Scan-set
End-timestamp of transaction acquired before validation starts
08.10.2016 SQLSaturday #555 Munich 2016
Validating Read Stability
Confirm that each row version in read-set is still visible during validation using end-timestamp
2016-10-08
10
08.10.2016 SQLSaturday #555 Munich 2016
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
08.10.2016 SQLSaturday #555 Munich 2016
2016-10-08
11
08.10.2016 SQLSaturday #555 Munich 2016
Isolation LevelsPhenomena Allowed
Isolation LevelsDirty Read
Non-Repeatable Read Phantoms Update
Conflict
READ UNCOMMITTED Yes Yes Yes No
READ COMMITTED
1 Locking2 Snapshot
NoNo
YesYes
YesYes
NoNo
SNAPSHOT No No (but not read stability)
Yes (but not visible) Yes
REPEATABLE READ No No Yes No
SERIALIZABLE No No No No
08.10.2016 SQLSaturday #555 Munich 2016
Summary
Isolation Levels and Concurrency Models
Pessimistic Concurrency
Optimistic Concurrency with In-Memory OLTP
2016-10-08
12
08.10.2016 SQLSaturday #555 Munich 2016
Save the Dates!
PASS Camp 2016 - 06. to 09. December 2016
SQL Konferenz 2017 - 14. to 16. February 2017