1. Let Me Finish... Isolating Write Operations
Louis Davidson
drsql.org
nerd

2. Who am I? Been in IT for 20-some years Microsoft MVP For 12 Years
Corporate Data Architect
Written books on database design
They were technically all versions of the same book. They at least had slightly different titles each time
Super Brief Contact Info: DRSQL
Twitter, Website (.org),
Change it to planning the next version

3. Topics of Discussion Transactions Connection/Transaction Isolation
Matters of Timing
Methods of Enforcement

4. Transactions Demo 1 – Cut for time Purpose Durability
Nested Transactions
Autonomous Transactions – Identity, Sequences
Demo 1 – Cut for time

5. Connection/Transaction Isolation
When executing a transaction, how can other connections affect your query results on a second connection?
Types of Issues
Phantom rows - Seeing new rows
Non-repeatable reads – Rows vanishes or changes
Dirty reads – Seeing data that never may actually exist in a specific form
Expired/Older data – Seeing data that no longer exists in the same form, but was consistent at a point in time
Isolation Levels – Settings to determine which anomalies we will accept
Coming up next…the list!

6. Isolation Levels and Anomalies Allowed
READ UNCOMMITTED –Dirty Reads, Phantom Rows, Non-Repeatable Reads
READ COMMITTED (Typical SQL Server Default) – Phantom Rows, Non-Repeatable Reads
SNAPSHOT – Older data, though a consistent view to a point in time
REPEATABLE READ –Phantom Rows
SERIALIZABLE

7. Matters of Timing
Synchronous access
Asynchronous access

8. Synchronous Access - Methods of Enforcement
Locks
Versions

9. Locks Tags to tell others you are using a resource
Note: The following is simplified, will include a list of resources for more detailed information at the end of the presentation
What Can Be Locked: Database, Table, Page, Row, Key, Range of Data, Schema, etc
Compatibility
Lock types must be compatible to be placed simultaneously
Full matrix:
Types:
Shared – Just looking, not modifying
Exclusive – (Typically) Used when modifying data
Update – A type of shared lock that says the connection may modify the underlying data. Must be changed to Exclusive to perform modification. Compatible with shared locks, not other update locks.
Stability – Placed to keep you from changing or dropping an object that is in use
Subtype:
Intent – Placed at higher levels in the resource hierarchy to tell other connections they can’t place an incompatible type
Deadlocks – Resource stalemate

10. Big Demo – Synchronous Concurrency Collisions With Locks
Using:
SQL Server 2016 RC0
in a Hyper-V VM

11. Multi-Valued Concurrency Controls (MVCC)
Every modification to a row results in a new physical resource
There are two versions currently implemented in SQL Server
On Disk Tables (2005+) – Makes copies of rows in tempdb for read versions, still uses locks for write concurrency.
Supported in SNAPSHOT Isolation Level and READ COMMITTED w/ READ_COMMITTED_SNAPSHOT DB Setting
In Memory Tables (2014+) – Physical structures completely based on versions
Supports SNAPSHOT, REPEATABLE READ, SERIALIZABLE Isolation Levels
True Version Based Concurrency Controls are often referred to as Optimistic Concurrency Controls
It is considered “optimistic” because it is assumed that there will rarely be collisions, and optimizes that way
Locking is often referred to as “pessimistic”

12. Hash Index Simplified With Row Versions
TableNameId
Country
OtherColumns 1
USA
Values 2 3
Canada

13. Hash Index – After Row Update
TableNameId
Country
OtherColumns 1
USA
Values 2
Canada 3

14. Big Demo – Synchronous Concurrency Collisions with MVCC
Using:
SQL Server 2016 RC0
in a Hyper-V VM

15. Asynchronous Considerations
Typical Flow
Two Users Fetch Data
One User Updates Data
Second User Updates Data Based on Their Expectations
Time separation may be a few microseconds or many hours
Scenarios
Chaos – Last writer wins
Optimistic Locking – Check cached data to see if it is still the data you had originally
Compare All (Or Some) Data
Compare some automatically maintained data (Rowversion (aka Timestamp), Row Last Modified Time controlled by Trigger, Client Managed Value)
A little bit of both – Example: How to deal with updating 100s (of thousands?) of rows?

16. Wrapup - The problems are complex
Mostly the issue is one of proper design, testing, and probability
Your designs must consider:
Cost of Integrity Fail
Throughput
Likelihood of collisions
Hopefully it is clear what is most important

17. Cost of Integrity Fail – “What if?”
1. Two people are travelling to Nashville via train, and both order hot chicken from two different wait persons, but there is only one order of chicken still available
Verdict: Annoying but not life threatening
2. If Train A is given access to Location L on Track 1 at 11:30 AM, and Train B is given access to the same Location at the same time going in a different direction.
Verdict: Time to learn some Johnny Cash Prison songs so you will fit in
Note: The “what if?” test ought to be applied to all of your designs

18. Questions? Comments?

19. Contact info
Louis Davidson -
Website – <-- Get slides here
Twitter –
SQL Blog
Simple Talk Blog – What Counts for a DBA
[twitter] Slides will be on drsql.org in the presentations area for this and the keynote as soon as I can get them out [/twitter]

20. Thank You!