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.