Avishai Krepel & Tal Olier
Database for DevelopersSession 6: Transactions
Agenda Preface
Database transactions and the ACID model
Locking - basics
Concurrency
Locking - advanced
So many users, so little time… User A interacts with data X
User B interacts with data Y
User C interacts with data X and Y
Conflict?
Multi user applications has a parallel aspect…
Ideal world Suggestion - each user working on it’s own copy of the data,
and sees other users’ (copy of the) data when required, updated to the correct time required.
Concerns: How do we decide who owns the data?
What is the correct time ?
Ideal world (cont.) Throughput compromise! User A works on Sundays, Tuesdays and Thursdays User B works on Mondays, Wednesdays and Fridays User C will have to work Saturdays…
What is a database transaction? Something we perform on our data?
Will it keeps my data safe?
How does it lets multiple users to do their work simultaneously?
From Babylon: “interaction between two parties, negotiation, settlement;
business deal” What is the contract?
The ACID model A set of rules for “keep our data safe”
Acronym for Atomicity Consistency Isolation Durability
ACID - Atomicity
“All in one proposition”
ACID - Consistency Data’s state is kept consistent
Data structures kept correct
Failed transaction’s impact is canceled
ACID - Isolation Transaction separation until finished Modification's separation Data visibility separation
ACID - Durability Modification persistency
Crash recovery Data recovery Log implementation
Locking (basics)
Locking Resource regulation
Possible in several levels Object Page/Block Row
Conceptual types: Exclusive lock Share lock
Exclusive lock Prevents sharing
Obtained to modify data
State assured until lock is removed
Share lockAllows limited sharing Used by data readers to block writers Share likes “to share” with share
• Data’s state is kept consistent
• Data structures kept correct
• Failed transaction’s impact is canceled …
… Consistency
Read consistency Data changes according to time
Readers and writers conflicts
Default level Oracle: statement SQL Server: none
Stmt level read consistency (Oracle)
SELECT statement starts at 08:00 (SCN 10023)
UPDATE statement update data in block #3 and block #5 at 09:00 (SCN 10024)
The SELECT gets to blocks #3 and #5 at 10:00 and reads them from the rollback segment (UNDO tablespace)
1 -2 -3 -4 -5 -6 -7 -
Concurrency
Concurrency side effects Dirty reads
Nonrepeatable (fuzzy) reads
Phantom reads (or phantoms)
Isolation levels
Isolation LevelsThe SQL standard defines four levels:
Read uncommitted
Read committed
Repeatable read
Serializable
Isolation Levels - Read uncommitted The only rule is – “no rules”
One transaction may see uncommitted changes made by some other transaction
Isolation Levels - Read committed The default isolation level
Query sees only data committed before (what?)
Good for conflicting transactions
Isolation Levels - Repeatable read Read data can not be changed
The transaction require specific locks
The transaction will see new data committed
Isolation Levels - Serializable Create the feeling that no other user changed
data
Implementations difference Oracle: The transaction sees only changes
committed before it started SQL Server: The transaction sees the changes as if
all transactions are ordered by time
Require extra developer work
Read phenomena by isolation levels
Isolation levels – Oracle and SQL Server Oracle offers the following
isolation levels Read committed Serializable isolation levels Read-only mode that is not
part of SQL92
Read committed is the default
SQL Server offers all 4 isolation levels: Read uncommitted Read committed Repeatable read Serializable
Read committed is the default
Setting isolation level
Oracle SQL Server SET TRANSACTION ISOLATION
LEVEL READ COMMITTED; SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE; SET TRANSACTION READ ONLY; ALTER SESSION SET
ISOLATION_LEVEL SERIALIZABLE;
ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;
SET TRANSACTIONISOLATION LEVEL READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE
Back to locking (advanced…)
Readers and writers
Oracle SQL Server
Data versioning based Readers do not block
writers Writers do not block
readers
Read-lock mechanism based Readers block writers Writers block readers
Locking - OracleTypes of locks
Oracle DML locks Assure integrity of data being accessed by multiple users
Both table and row locks are used
Partition is considered a table
Row locks (Oracle DML locks)A transaction acquires an exclusive row lock for each individual
row modified by one of the following statements:
INSERT
UPDATE
DELETE
SELECT (only with the FORUPDATE clause)
Table locks (Oracle DML locks)
LOCK TABLE <table name> IN EXCLUSIVE MODE
Oracle manual (explicit ) data lockingPossible via one of the following:
The SET TRANSACTION ISOLATION LEVEL statement
The LOCK TABLE statement
The SELECT ... FOR UPDATE statement
Locks acquired by these statements are released after the transaction commits or rolls back
Locking – SQL ServerResources that can be locked by SQL Server
Locking explicitly – SQL Server Done via hints (proprietary syntax)
Example:select * from t1with (PAGLOCK ,HOLDLOCK)where c1 between 17 and 32
Locking explicitly – SQL Server (cont.) Some more examples of hints NOLOCK/READUNCOMMITTED – dirty read PAGLOCK – takes page locks instead of row locks (statement
scoped) TABLOCK/X - takes page locks (share, exclusive) instead of
row locks (statement scoped) UPDLOCK/XLOCK – takes exclusive locks for read rows
(transaction scoped)
Locking and transactions Transaction modes are managed at the session level
Connection is the object that encapsulates the session “state”
Transaction management - syntax
Oracle SQL Server
BEGINupdate emp set salary = salary * 0.95;update emp set salary = salary * 0.95 where manager_flag = 1;
COMMIT;END;/
BEGIN TRANSACTION
update emp set salary = salary * 0.95;
update emp set salary = salary * 0.95 where manager_flag = 1;
COMMIT;
GO
Transaction – possible endings Commit – makes changes visible
Rollback – cancel changes
commit/rollback Remove all locks Start a new implicit transaction
Auto commit Every SQL statement is committed (upon completion)
The default mode for ADO, OLE DB, ODBC, DB-Library and Java
SQL tools behavior Notice the auto-commit setting prior to updating records
SQL Server SQL Server management studio (SSMS) Every query window is a different connection
Oracle Oracle SQL developer (until release 2) All windows of the same connection share the same transaction (and
locks)
Partial rollback
Oracle “savepoint”SQL Server “save transaction”
begin transaction trans1
insert into t1 values (1, 'one');
save transaction two
insert into 1 values (2, 'two');
rollback transaction two
commit
begin
insert into t1 values (1, 'one');
savepoint two;
insert into 1 values (2, 'two');
rollback to savepoint two;
commit;
end;
Partial rollback (cont.)
After a partial rollback transaction do free locks held by roll backed statements
After a partial rollback transaction do not free locks held by roll backed statements
Oracle “savepoint”SQL Server “save transaction”
Select for update (demo)
Oracle SQL Server
SELECT ID FROM EMP FOR UPDATE
SELECT ID FROM EMP WITH (UPD LOCK)
Locking example1 2 3 4 5
6 7 8 9 10
11 12 13 14 15
16 17 18 19 20
21 22 23 24 25
101 102 103 104 105
106 107 108 109 110
111 112 113 114 115
116 117 118 119 120
121 122 123 124 125
…
Lock escalation Occurs when numerous locks are held at one level of
granularity
Database decides to raise some/all of the locks to a higher level
Tradeoff between number of locks and restrictiveness
Lock escalation – Oracle
Oracle never escalate locks!
Lock escalation – SQL Server Escalation thresholds: T-SQL level – amount of locked rows (~5000) Instance level – amount of memory occupied by locks (40%)
Thresholds can be changed SQL Sever instance ‘locks’ parameter
Escalation can fail because of other locking transactions
Lock escalation – SQL Server (cont.)
Escalation success Escalation failure
The full table lock is acquired
All heap or B-tree, page (PAGE), or row-level (RID) locks held by the transaction on the heap or index are released
Full lock cannot be acquired
Database Engine will continue to acquire row, key, or page locks
Database Engine will retry the lock escalation for each additional ~1,250 locks acquired by the transaction
Lock escalation – demo (SQL Server) Demo table
Update of x rows from the table
Check the locks on the table
Lock escalation – disable At instance level DBCC TRACEON (1211,-1) – disable memory or # of locks
escalations DBCC TRACEON (1224,-1) – disable # locks escalations
At table level (SQL Server 2008 only) ALTER TABLE SET LOCK_ESCALATION = DISABLE
At session level DBCC TRACEON (1211) DBCC TRACEON (1224)
Lock escalation – DEV pitfallsNote: Cases when multiple updates/deletes from various clients
happen on the same table and spanned across many rows Select with updlock (select for update) is considered as update Oracle developers do not know this behavior
Deadlock (example)
This is it.
Top Related