Title Slide No more than 2 lines

Transcription

o
k
b
c
l
lotwco sk,
moki ng barr el s
&
Mark Broadbent
Principal Consultant
SQLCloud
SQLCLOUD.CO.UK
Thank you to our sponsors!
SQL SATURDAY | #516 | REYKJAVIK 2016
Your feedback is important!
Please let us know what you thought of this session
HTTP://SQLSATURDAY.COM/516/SESSIONS/SESSIONEVALUATION.ASPX
SQL SATURDAY | #516 | REYKJAVIK 2016
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
Email: [email protected]
Twitter: https://twitter.com/retracement
Blog: http://tenbulls.co.uk
Event Lead to the UK’s first ever SQLSaturday (Cambridge)
Event #4 in Sept 2016 (pre-cons & Community day)
http://sqlcambs.org.uk
Copyright © 2014, SQLCloud Limited. Please do not redistribute, republish in whole or in part without prior permission of content owner. www.sqlcloud.co.uk
Agenda
X
X
1
Theory
Locking
2
Isolation
3
4
Optimistic
Concurrency
5
The best part of the
presentation… Gin O‘Clock
Theory
(aka whatcha talkin’ ‘bout Willis)
A
C
I
D
Transaction Log –the D in ACID
Log
Buffer
1
Control returned
to spid on
commit.
Log
Buffer
n
Log writes are first
written to log buffers.
Flush on fill or on
commit.
Delayed Durability
is a compromise.
Log
Writer
VLF
header
async
Signal to flush
Log file (.ldf)
Log
file
Header
Log
Block
Virtual Log Files (VLFs)
Version
Header
FseqNo
Record 1
Size
Record 2
Record n
Slot Array
512 bytes to 60KB
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
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
“Isolation is a balance between
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
Serial Processing
Read R1
Read R2
Write R3
Read R1
Read R2
Write R3
T1
Read R4
Write R4
T2
Read R4
Write R4
T3
T4
Transaction Interleaving
Order 1
Order 2
T1 Read R1
T1 Read R2
T1 Write R3
T2 Read R1
T2 Read R2
T2 Write R3
T2 Read R1
T2 Read R2
T2 Write R3
T1 Read R1
T1 Read R2
T1 Write R3
T3
T3
T4
T4
T4
T4
T3
T3
Read R4
Write R4
Read R4
Write R3
Read R4
Write R3
Read R4
Write R4
Order 4
Order 3
T1
T1
T2
T2
T1
T2
T3
T3
T4
T4
Read R1
Read R2
Read R1
Read R2
Write R3
Write R3
Read R4
Write R4
Read R4
Write R3
T1
T1
T2
T2
T2
T1
T3
T3
T4
T4
Read R1
Read R2
Read R1
Read R2
Write R3
Write R3
Read R4
Write R4
Read R4
Write R4
Order 5
T1
T1
T2
T2
T1
T2
T3
T4
T3
T4
Read R1
Read R2
Read R1
Read R2
Write R3
Write R3
Read R4
Read R4
Write R4
Write R4
Transactional Histories
T1 Read R1
T1 Read R2
T2 Read R1
T2 Read R2
T1 Write R3
T2 Write R3
T3 Read R4
T4 Read R4
T3 Write R4
T4 Write R4
T1
T1
T1
T1
SLOCK R1
Read R1
UNLOCK R1
SLOCK R2
T2
T2
T1
T2
T2
T2
T1
T2
T1
T1
T1
SLOCK R1
Read R1
Read R2
UNLOCK R1
SLOCK R2
Read R2
UNLOCK R2
UNLOCK R2
XLOCK R3
Write R3
UNLOCK R3
T2 XLOCK R3
T2 Write R3
T2 UNLOCK R3
A transaction is
considered Two-Phased
if all LOCK actions
precede an UNLOCK
action
A transaction is
considered to be WellFormed if all READ,
WRITE and UNLOCK
operations are covered
by a preceding LOCK.
Isolation
mechanism has
“serialized
these
transactional
writes to same
resource
Locking
(aka what the blockin’ hell!)
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
(U)pdate lock …a special kind of lock
spid 115
UPDATE orders
SET status = 1
WHERE id > 1
AND id < 4
orders
SEARCH
PHASE
UPDATE
PHASE
Lock
Conversion
spid 162
X
id
status
1
0
2
2
UPDATE orders
SET status = 1
WHERE id > 1
AND id < 3
Lock will be blocked!
X
3
1
4
0
S
U
X
S
U
X
Isolation
(aka nobody loves me)
Isolation Levels
Isolation Level
“Bad Dependencies”
X Dependencies
Concurrency
READ UNCOMMITTED
Dirty Read,
Non-Repeatable Read, Phantoms, Lost Updates
WRITE  WRITE
GOOD: only wait on write-write locks
READ COMMITTED
Non-Repeatable Read,
Phantoms , Lost Updates
WRITE  WRITE
READ  WRITE
WRITE  READ
OK: wait on both but only writes held to EOT
READ COMMITTED
(with Snapshot Isolation)
Non-Repeatable Read,
Phantoms , Lost Updates
WRITE  WRITE
GOOD: only wait on writes held to EOT
REPEATABLE READ
Phantoms
WRITE  WRITE
READ  WRITE
WRITE  READ
LOW: read and write locks held to EOT
SERIALIZABLE
None
WRITE  WRITE
WRITE  READ
READ  WRITE
LOWEST: read and write locks held to EOT
SNAPSHOT
None (though Causal consistency concerns, lost
update prevention and other behaviours)
WRITE  WRITE
GOOD: only wait on writes held to EOT
1
2
2
3
4
5
Isolation Levels…
• Attempt to solve reduce interleaving dependency problems
• 4 Levels are defined standard by ANSI, SQL 2005+ 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)
Read Committed Lost Updates?
DECLARE @basketcount INT = 1
DECLARE @newquantity INT
BEGIN TRANSACTION
SELECT @newquantity = quantity FROM GunInventory
WITH (NOLOCK) WHERE id = 1
SET @newquantity = @newquantity - @basketcount
UPDATE GunInventory SET quantity = @newquantity
WHERE id = 1
COMMIT
Demo
Pessimistic isolation
Optimistic Concurrency
(aka sharks with frikken lasers!)
Row Versioning
Row data
Row
T2
1
6
14 Bytes
Pointer
XSN
A
9925
UPDATE… x=4
COMMIT
T1
UPDATE… x=2
COMMIT
Version created on
statement execution
not transaction commit.
Version
1
4
B
Version
1
9910
2
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
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
At least that is what I believe it is
called (i.e. causal consistency).
*1
See “A Read-Only Transaction Anomaly
Under Snapshot Isolation
By Alan Fekete, Elizabeth O'Neil, and
Patrick O'Neil”
And Craig Freadman’s blog
http://bit.ly/SerialVsSnapshot
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
Demo
Optimistic isolation
Further Reading
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
Thank you for listening!
Email: [email protected]
Twitter: retracement
Blog: http://tenbulls.co.uk
Slideshare: http://www.slideshare.net/retracement

Title Slide No more than 2 lines

Transcription

Similar documents

Handling der Transaction Log-Files im MS SQL Server

Zoeller Preassembled Sewage Systems