archiwizowanie danych i odtwarzanie bazy danych po awarii€¦ · · 2013-11-28ts ordering...

Transaction Management

Robert Wrembel

Politechnika Poznańska

Instytut Informatyki

[email protected]

www.cs.put.poznan.pl/rwrembel

2 Robert Wrembel, Politechnika Poznańska, Instytut Informatyki

Outline

Concurrent access anomalies

Transaction

Synchronizing concurrent access

Transactions in SQL Server

Transactions in DB2

Transactions in Oracle


Update anomalies (1)

Dirty read



Nonrepetable reads

S1 reading the same row multiple times sees its changes



Phantoms query executed at time t2 sees rows inserted

between t1 and t2

data read at t1 have not changed

t1

t2



Lost update (dirty write)


Isolation Levels

Serializable

it prevents other transactions from updating or inserting rows into the table until the serializable transaction is finished


Transaction

A unit of interaction between a user and a database

consists of a set of commands

States

committed

aborted/rolled back

Properties (ACID)

atomicity

consistency

isolation

durability


Transaction management

Scheduling preserving consistency

Deadlock detection

Commit protocol


Transaction scheduling

Schedule a sequence of operations by a set of concurrent

transactions that preserves the order of the operations in each of the individual transactions

let schedule S consists of a sequence of the operations from the set of T1, T2, ... Tn transactions

for each transaction Ti in schedule S the original order of operations in Ti must be the same in S

Serial schedule a schedule where the operations of each transaction are

executed consecutively without any interleaved operations from other transactions

Nonserial schedule a schedule where the operations from a set of concurrent

transactions are interleaved


Serializability

Anomalies result from parallel execution of transactions

Serial execution prevents from the anomalies

Objective - serializability:

find nonserial schedules that allow transactions to execute concurrently in a way producing a database state the same as produced by a serial execution

If a set of transactions executes concurrently, we say that a nonserial schedule is correct if it produces the same results as a serial schedule

such a schedule is called serializable


Concurrency control techniques

Methods used for ensuring serializability of concurrent transactions

Timestamping

Optimistic method

Locking


Timestamping (1)

No waiting transactions

Conflicting transactions are rolled back and restarted

Timestamp

transaction timestamp: a unique identifier created by a DBMS that indicates the relative starting time of a transaction

read_timestamp - TS of the last transaction that read a record

write_timestamp - TS of the last transaction that modified a record


Timestamping (2)

Timestamping

a concurrency control protocol that orders transactions in such a way that older transactions (with smaller timestamps) get priority in the event of conflict

Transaction TB is allowed to read or write record R if the last update of R was done by an older transaction TA

otherwise TB is restarted and assigned a new TS

new (younger) TS prevents TB from continuously being restarted


TS ordering protocol (1)

Transaction TA issues READ(R)

R has already been updated by a younger transaction TB

TS(TA) < write_timestamp(R)

• rollback TA

• assign a new TS to TA

• restart TA

TS(TA) >= write_timestamp(R)

• READ(R)

• assign read_timestamp(R):=max{TS(TA), read_timestamp(R)}


TS ordering protocol (2)

Transaction TA issues WRITE(R)

R has already been read by a younger transaction TB

TS(TA) < read_timestamp(R)

• rollback TA


• restart TA

R has already been written by a younger transaction TB

TS(TA) < write_timestamp(R)

• rollback TA


• restart TA

otherwise: execute TA

• assign write_timestamp(R) = TS(TA)


Optimistic protocol (1)

Assumptions: conflicts are rare

when transaction T is going to commit, a check is performed to determine whether a conflict occured

if so T has to be aborted and restarted

Offers higher concurrency as no locking is used

Costs of restarting conflicting transactions

Phases

read: reading and updating data

• local copies of updated data are used

• transaction T gets assigned the START(T) timestamp

validation

• checking if serializability is not violated

• transaction T gets assigned the VALIDATION(T) timestamp

write: writing updated data on disk

• transaction T gets assigned the FINISH(T) timestamp


Optimistic protocol (2)

For T to pass the validation phase the following has to be true:

1. All transactions Ti with earlier timestamps must have finished before transaction T started

FINISH(Ti) < START(T)

2. If T starts before earlier transaction Ti finishes, then

the set of records written by Ti is not the same as read by T and

Ti completes its write phase before T enters its validation phase

START(T)<FINISH(Ti)<VALIDATION(T)

it guarantees that writes are done serially, ensuring no conflicts


Locking

A transaction has to obtain a shared (read) lock or an exclusive (write) lock on a data item before executing an operation on that item

Two-phase locking protocol (2PL)

growing phase

• all required locks are obtained

• no obtained locks are released

shrinking phase

• all obtained locks are released

• no new locks are obtained nb of locks

obtained

time

shared

exclusive

shared exclusive

x

x x

lock compatibility


Multiversion locking

Versions of data are maintained by a system

record R being updated has its version Rold before update

transactions reading R (that is modified) access Rold

shared

exclusive

shared exclusive

x

lock compatibility

Locking methods

prevent conflicts by making transactions wait

may cause deadlocks

Dealing with Deadlock

Deadlock prevention techniques

lock all data in advance

no waitnig

cautious waiting

wait-die

wound-wait


Deadlock Prevention

Lock all data in advance

a transaction lock all the data it needs in advance

if any of the data cannot be locked then none of the data are locked

No waiting

a transaction that cannot obtain a lock is immediately aborted and restarted after a certain time delay

Cautious waiting

Ti tries to lock record R that is already locked by Tj

if Tj is not blocked (not waiting for other locked items) then Ti is allowed to wait, otherwise Ti is aborted


Deadlock Prevention

Wait-die

an older transaction is allowed to wait on a younger transaction

a younger transaction requesting R held by an older transaction is aborted and restarted with the same timestamp

TA10, TB

20, TC30

TA requests R held by TB TA waits

TC requests R held by TB TC is restarted

Wound-wait

a younger transaction is allowed to wait on an older one

an older transaction requesting R held by a younger transaction aborts the younger one and restarts it with the same timestamp

TA requests R held by TB TA aborts TB

TC requests R held by TB TC waits


Deadlock Detection

Wait for graph

a node is created for each transaction

arc Ti Tj is created if Ti is waiting for R locked by Tj

Solving deadlocks

a transaction that waits longer than a system defined timeout is aborted

kill the younger transaction

kill the less expensive transaction (data volume modified, locked resources, ...)

kill a randomly selected transaction

kill the transaction that caused the deadlock


Transactions in Oracle

Autocommitt OFF (by default)


-- implicit BEGIN TRANSACTION

sql1;

sql2;

savepoint SP1;

sql3;

sql4;

savepoint SP2;

sql5;

sql6;

sql7;

rollback to savepoint SP1;


sql1;

sql2;

sql3;

sql4;

commit;

rollback to savepoint releases obtained locks

Oracle

Isolation level READ COMMITTED

default


set transaction isolation level READ COMMITTED;

alter session set isolation_level = READ COMMITTED;

Isolation level SERIALIZABLE

set transaction isolation level SERIALIZABLE;

alter session set isolation_level = SERIALIZABLE;

plik konfiguracyjny instancji: SERIALIZABLE = true

READ ONLY transaction

set transaction {READ ONLY | READ WRITE};

Oracle - Lock Types

Row lock (exclusive)

Table locks

Row share lock (RS)

intention to modify table content

select from ... for update of ...

lock table ... in row share mode [nowait]

Row exclusive lock (RX)

modified rows

insert

update

delete

lock table ... in row exclusive mode [nowait]


Oracle - Lock Types

Share table lock (S)

lock table ... in share mode [nowait]

Share row exclusive table lock (SRX)

lock table ... in share row exclusive mode [nowait]

Exclusive table lock (X)

lock table ... in exclusive mode [nowait]


Oracle

Data dictionary locking

Issued by DDL commands

Types

exclusive alter, drop

shared create procedure/function/package locks

dependent objects, e.g., tables

parsing parsing an SQL command locks objects

referenced by the command


Oracle - Lock Types


Oracle

Autonomous transaction

performs an independent transaction

uncommitted data are not seen by the calling transaction

must finish before the calling transaction

available since Oracle8i

Application

registering DML executed on tables

executing DDL in triggers

modifying the content of a table in a function called from SQL

Implementation

PRAGMA AUTONOMOUS_TRANSACTION in a declaration section of a procedure, function, trigger


Oracle

Autonomous transaction cannot be started as the first transaction

i.e., it must be a substransaction


BEGIN TRANSACTION /* calling trans. */

insert;

...

update;

/* autonomous trans. */

DECLARE

PRAGMA AUTONOMOUS_TRANSACTION;

BEGIN

insert;

update;

COMMIT;

END;

insert;

...

COMMIT;

/* this is not allowed */

declare

pragma autonomous_transaction;

begin

insert into t values (1);

end;

/

insert into t values (1);

Oracle


CREATE TABLE test (nr NUMBER, txt VARCHAR2(12));

INSERT INTO test VALUES (1, 'trans1');

INSERT INTO test VALUES (2, 'trans2');

DECLARE


BEGIN

FOR i IN 3 .. 4 LOOP

INSERT INTO test VALUES (i, 'auton trans');

END LOOP;

COMMIT;

END;

ROLLBACK;

SELECT * FROM test;

Oracle

The following types of PL/SQL blocks can be defined as autonomous transactions:

procedures and functions (not stored)

stored procedures and functions in or outside a package

methods (defined for types OO extension)

top-level anonymous blocks


Oracle


CREATE OR REPLACE PROCEDURE pName (inputArgs) AS


BEGIN

...

COMMIT;

END;

BEGIN

insert;

update;

delete;

pName(...);

...

END;

Reading Lock Info

V$LOCKED_OBJECT

...

object_id

session_id

oracle_username

os_user_name

process

locked_mode

• 0 None

• 1 Null

• 2 Row-S (SS)

• 3 Row-X (SX)

• 4 Share

• 5 S/Row-X (SSX)

• 6 Exclusive


Reading Lock Info

DBA_LOCK | DBA_LOCKS

...

session_id

lock_type

• DX Distributed Transaction

• IR Instance Recovery

• TM DML Enqueue

• TX Transaction

• ... the values are not well documented

mode_held = V$LOCKED_OBJECT. locked_mode

mode_requested

blocking_others = {'Not Blocking', 'Blocking'}


DBA_OBJECTS

...

object_name

object_id

object_type

owner

Waiting transactions

DBA_WAITERS

...

waiting_session session id

holding_session session id

lock_type

mode_held

mode_requested

V$SESSION

...

sid

serial#

username

command

status


alter system kill session 'sid, serial#';

Transactions in SQL Server


trans_name: unique transaction name

WITH MARK 'description':

specifies that the transaction is marked in a log

allows for restoring a database to a named mark

'description': max 128 characters

Supports nested (autonomous) transactions (from ver. 2008)

BEGIN {TRAN | TRANSACTION}

[trans_name [WITH MARK 'description']]

SQL commands;

...

{COMMIT TRANSACTION | ROLLBACK TRANSACTION [trans_name]}

SQL Server

Transaction scheduling: locking

Autocommit ON by default

SET IMPLICIT_TRANSACTIONS {ON | OFF}

default OFF Autocommit ON

ON requires explicit COMMIT or ROLLBACK

Isolation levels

read uncommitted

read committed (default)

repeatable read

snapshot

serializable


SQL Server

READ COMMITTED:

if database option READ_COMMITTED_SNAPSHOT is ON then row versioning allows read and write lock on the same row

SNAPSHOT:


SET TRANSACTION ISOLATION LEVEL

{READ UNCOMMITTED |

READ COMMITTED |

REPEATABLE READ |

SNAPSHOT |

SERIALIZABLE}

updates made by other transactions after the start of the current transaction are not visible to statements executing in the current transaction

the transaction gets a snapshot of the committed data as it existed at the start of the transaction

SNAPSHOT transactions reading data do not block other transactions from writing data

transactions writing data do not block SNAPSHOT transactions from reading data

SQL Server

SERIALIZABLE

no other transactions can modify data that has been read by the current transaction until the current transaction ends

range locks are placed in the range of key values that match the search conditions of each statement executed in a transaction

it blocks other transactions from updating or inserting any rows that would qualify for any of the statements executed by the current transaction


SQL Server

Lock types

Shared (S)

for read operations that do not change or update data, e.g., SELECT

Update (U)

on resources that can be updated

only one transaction can held U

when updates start then U is converted into X

Exclusive (X)

for INSERT, UPDATE, or DELETE

ensures that multiple updates cannot be made to the same resource at the same time


SQL Server


Lock types

Intent

intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX)

Schema

schema modification (Sch-M)

schema stability (Sch-S): when compiling and executing queries

Bulk Update (BU)

for bulk loading data into a table

the TABLOCK hint is specified

Key-range

for SERIALIZABLE isolation level

SQL Server


SQL Server


Transactions in DB2

transaction = unit of work

support for autonomous transactions



sql1;

sql2;

sql3;

sql4;

commit;


sql1;

sql2;

savepoint SP1 on rollback retain cursors;

sql3;

sql4;

savepoint SP2 on rollback retain locks;

sql5;

sql6;

sql7;

rollback to savepoint SP1;

DB2

Transaction scheduling: locking

Autocommit OFF by default

Isolation levels

uncommitted read (UR)

cursor stability (CS) = read committed

read stability (RS) = repeatable read

• locks only those rows that a transaction retrieves

• any qualifying row read cannot be changed by another transaction

repeatable read (RR) = serializable

• no other application can update, delete, or insert a row that would affect the result set until the transaction completes


DB2


DB2


Setting an isolation level for a session

SET [CURRENT] ISOLATION LEVEL [=] {UR | CS | RR | RS}

Row locking

share

exclusive

Table locking

share

exclusive

LOCK TABLE tab IN xxx MODE

DB2

Table locks

IN - Intent None

IS - Intent Share

IX - Intent eXclusive

SIX - Share with Intent eXclusive

S - Share

U - Update

X - eXclusive

Z - Superexclusive


Row locks

S - Share (table lock = IS)

U - Update (table lock = IX)

X - eXclusive (table lock =IX)

W - Weak Exclusive (table lock = IX)

NS - Next Key Share (table lock = IS)

NW - Next Key Weak Exclusive (table lock = IX)

for indexes

Distributed Transactions

Distributed 2PL

2PC/3PC

Distributed deadlock detection


archiwizowanie danych i odtwarzanie bazy danych po awarii€¦ · · 2013-11-28ts ordering...

Documents