ENCh17

7/21/2019 ENCh17

http://slidepdf.com/reader/full/ench17 1/57

7/21/2019 ENCh17


Chapter 17

Introduction to Transaction Processing

Concepts and Theory

Copyright © 2004 Pearson Education, Inc.

7/21/2019 ENCh17


Copyright © 2004 Ramez Elmasri and Shamant !a"athe

Elmasri/Navathe, Fundamentals of ata!ase "ystems, Fourth Edition Chapter 17-3

Chapter Outline

# Introduction to $ransaction Processing

2 $ransaction and System Concepts

% &esira'le Properties o( $ransactions

4 Characterizing Schedules 'ased on Reco"era'ility) Characterizing Schedules 'ased on Serializa'ility

* $ransaction Support in S+

7/21/2019 ENCh17



Elmasri/Navathe, Fundamentals of ata!ase "ystems, Fourth EditionChapter 17-4

1 Introduction to Transaction Processing (1)

Single-User System: -t most one user at a time can

use the system.

Multiuser System /any users can access the systemconcurrently.

Concurrency

Interleaved processing concurrent e1ecution o(

processes is interlea"ed in a single CP

Parallel processing processes are concurrently

e1ecuted in multiple CPs.

7/21/2019 ENCh17



Elmasri/Navathe, Fundamentals of ata!ase "ystems, Fourth Edition Chapter 17-

Introduction to Transaction Processing (2)

! "ransaction: logical unit o( data'ase processing thatincludes one or more access operations 3read retrie"al,5rite insert or update, delete6.

! transaction #set o$ operations% #.may 'e standalone speci(ied in a high le"el language lie S+su'mitted interacti"ely, or 2.may 'e em'edded 5ithin a

program.

"ransaction &oundaries 7egin and End transaction.

-n application program may contain se"eraltransactions separated 'y the 7egin and Endtransaction 'oundaries.

7/21/2019 ENCh17



Elmasri/Navathe, Fundamentals of ata!ase "ystems, Fourth Edition Chapter 17-'


SIMP() M*+)( *, ! +!"!!S) #$orpurposes o$ discussing transactions%:

! data&ase - collection o( named data items

.ranularity o$ data a (ield, a record , or a 5hole

dis 'loc 3Concepts are independent o( granularity6

7asic operations are read and /rite read0item#% Reads a data'ase item named 8 into a

program "aria'le. $o simpli(y our notation, 5e assumethat the program variable is also named X.

/rite0item#% 9rites the "alue o( program "aria'le 8into the data'ase item named 8.

7/21/2019 ENCh17





READ AND WRITE OPERATIONS: Basic unit of data transfer from the disk to thecomputer main memory is one block. In general, adata item (what is read or written) 1.will be the field

of some record in the database, although 2.it may be alarger unit such as a record or even a whole block. read_item(X) command includes the following steps:1. Find the address of the disk block that contains item X.

2. Copy that disk block into a buffer in main memory (if that disk

block is not already in some main memory buffer).

3. Copy item X from the buffer to the program variable named X.

7/21/2019 ENCh17




READ AND WRITE OPERATIONS (cont.): write_item(X) command includes the followingsteps:

1. Find the address of the disk block that contains item X.

2. Copy that disk block into a buffer in main memory (ifthat disk block is not already in some main memory buffer).

3. Copy item X from the program variable named X intoits correct location in the buffer.

4. Store the updated block from the buffer back to disk(either immediately or at some later point in time).


7/21/2019 ENCh17

http://slidepdf.com/reader/full/ench17 9/57Copyright © 2004 Ramez Elmasri and Shamant !a"athe


FI#$%E 17&'

Two sample transactions. (a) Transaction T 1.

() Transaction T 2.

7/21/2019 ENCh17



5hy Concurrency Control is needed:The Lost Update Problem.

This occurs when two transactions that access the samedatabase items have their operations interleaved in a way

that makes the value of some database item incorrect.The Temporary Update (or Dirty Read) Problem.

This occurs when one transaction updates a databaseitem and then the transaction fails for some reason (see

Section 17.1.4). The updated item is accessed by anothertransaction before it is changed back to its original value.

Introduction to Transaction Processing (!)

7/21/2019 ENCh17



5hy Concurrency Control is needed #cont6%:

The Incorrect Summary Problem .

If one transaction is calculating an aggregatesummary function on a number of records whileother transactions are updating some of theserecords, the aggregate function may calculate some

values before they are updated and others after theyare updated.

Introduction to Transaction Processing (")

7/21/2019 ENCh17



FI#$%E 17&(

#ome prolems that occur when concurrent

e$ecution is uncontrolled. (a) The lost update

prolem.

7/21/2019 ENCh17



FI#$%E 17&( )continued*

#ome prolems that occur when concurrent

e$ecution is uncontrolled. () The temporar% update

prolem.

7/21/2019 ENCh17



FI#$%E 17&( )continued*

#ome prolems that occur when concurrent e$ecution is

uncontrolled. (c) The incorrect summar% prolem.

7/21/2019 ENCh17



5hy recovery is needed:

(What causes a Transaction to fail)

1.A computer failure (system crash): A hardware orsoftware error occurs in the computer system during

transaction execution. If the hardware crashes, thecontents of the computer’s internal memory may be lost.

2.A transaction or system error : Some operation in thetransaction may cause it to fail, such as 1.integer overflow or 2.division by zero. Transaction failure may also occur

because of 3.erroneous parameter values or because of a4.logical programming error. In addition, 5.the user mayinterrupt the transaction during its execution.


7/21/2019 ENCh17


Elmasri/Navathe, Fundamentals of ata!ase "ystems, Fourth Edition Chapter 17-1'

5hy recovery is needed #cont6%:

3. Local errors or exception conditions detected by thetransaction:-certain conditions necessitate cancellation of thetransaction.For example,data for the transaction may not befound. A condition, such as insufficient account balance in a banking database, may cause a transaction, such as a fund

withdrawal from that account, to be canceled.- a programmed abort in the transaction causes it to fail.

4.Concurrency control enforcement: The concurrency controlmethod may decide to abort the transaction, to be restartedlater , becauseit 1.violates serializability or because 2.several

transactions are in a state of deadlock (see Chapter 18).


7/21/2019 ENCh17



5hy recovery is needed #cont6%:

5. Disk failure: Some disk blocks may lose their data because of a read or write malfunction or because of adisk read/write head crash. This may happen during

a read or a write operation of the transaction.6. Physical problems and catastrophes: This refers to anendless list of problems that includes power or air-conditioning failure, fire, theft, sabotage, overwriting

disks or tapes by mistake, and mounting of a wrongtape by the operator.


7/21/2019 ENCh17



2 Transaction and #%stem Concepts (1)

Atransaction is an atomic unit of work that is eithercompleted in its entirety or not done at all.

* For recovery purposes, the system needs to keep track

of when the transaction starts, terminates, and commitsor aborts.

Transaction states:Active state

Partially committed stateCommitted stateFailed stateTerminated State

7/21/2019 ENCh17



Transaction and #%stem Concepts (2)

Recovery manager keeps track of the followingoperations:

begin_transaction:This marks the beginning oftransaction execution.

read or write: These specify read or write operations

on the database items that are executed as part of atransaction.

end_transaction: This specifies that read and writetransaction operations have ended and marks the endlimit of transaction execution.At this point it may

be necessaryto check whether the changes introduced by the transaction,,, 1.can be permanently applied tothe database!!! or 2.whether the transaction has to beaborted,, because it violates concurrency control or forsome other reason.

7/21/2019 ENCh17




Recovery manager keeps track of the following operations(cont):

commit_transaction: This signals asuccessful end of thetransactionso that

>any changes (updates) executed by the transaction can besafelycommitted to the database and will not beundone.

rollback (or abort):This signals that the transaction hasended

unsuccessfully, so that >any changes or effects that the transaction may have appliedto the databasemust beundone.

7/21/2019 ENCh17




Reco"ery techni:ues use the (ollo5ing operators:

undo: Similar to rollbackexcept that it

applies to a single operation rather than to awhole transaction.

redo: This specifies that certaintransactionoperations must beredone >>>to ensure that allthe operations of a committed transaction have

been applied successfully to the database.

7/21/2019 ENCh17



FI#$%E 17&+

#tate transition diagram illustrating the states &or

transaction e$ecution.

7/21/2019 ENCh17



Transaction and #%stem Concepts (')

The System LogLog or Journal: The logkeeps track of all transactionoperations that affect the values of database items. This

information may be needed to permit recovery fromtransaction failures. The log is kept on disk , so it isnot affected by any type of failure except for disk orcatastrophic failure. In addition, the log is periodically backed up to archival storage (tape) to guard against such

catastrophic failures.T in the following discussion refers to a uniquetransaction-id that is generated automatically by thesystem and is used to identify each transaction:

7/21/2019 ENCh17



Transaction and #%stem Concepts (!)The System Log (cont):Types of log record:

1.[start_transaction,T]:Records that transaction T has startedexecution.

2.[write_item,T,X,old_value,new_value]:Records thattransaction T has changed the value of database item X fromold_value to new_value.

3.[read_item,T,X]:Records that transaction T has read the valueof database item X.

4.[commit,T]:Records that transaction T has completedsuccessfully, and affirms that its effect can be committed(recorded permanently) to the database.

5.[abort,T]:Records that transaction T has been aborted.

7/21/2019 ENCh17



Transaction and #%stem Concepts (")

The System Log (cont):

protocols for recovery that avoid cascadingrollbacks do not require that read operations

be written to the system log, whereas otherprotocols require these entries for recovery.

strict protocols require simpler write entriesthat do not include new_value (see Section

17.4).

7/21/2019 ENCh17



Transaction and #%stem Concepts ()

Recovery using log records:If the system crashes, we can recover to a consistent databasestate by examining the log and using one of the techniquesdescribed in Chapter 19.

1.Because the log contains a record of every write operationthat changes the value of some database item, it is possibletoundo the effect of these write operations of a transactionT by tracing backward through the log and resetting allitems changed by a write operation of T to their old_values.

2.We can alsoredo the effect of the write operations of atransactionT by tracing forward through the log and settingall items changed by a write operation of T (that did not getdone permanently) to their new_values.

7/21/2019 ENCh17




Commit Point of a Transaction: Definition:A transaction T reaches itscommit point 1.when all its operations that access the database have been executed successfullyand 2.the effect

of all the transaction operations on the database has been recorded in the log. Beyond the commit point, thetransaction is said to becommitted, and its effect isassumed to be permanently recorded in the database.The transaction then writes an entry [commit,T] into

the log. Roll Back of transactions:Needed for transactionsthat have a [start_transaction,T] entry into the log butno commit entry [commit,T] into the log.

7/21/2019 ENCh17





Commit Point of a Transaction (cont):Redoing transactions: Transactions that have writtentheircommit entry in the logmust also have recorded alltheir write operations in the log;otherwise they wouldnot be committed, so their effect on the database can beredone from the log entries. (Notice that the log file

must be kept on disk. At the time of a system crash,only the log entries that have beenwritten back to disk are considered in the recovery process because thecontents of main memory may be lost.)

Force writing a log:before a transaction reaches itscommit point,any portion of the log that has not beenwritten to the disk yet must now be written to the disk.This process is calledforce-writing the log file beforecommitting a transaction.

7/21/2019 ENCh17




3 *esirale Properties o& Transactions (1)

ACID properties:

Atomicity:A transaction is an atomic unit of

processing; it is either performed in its entiretyor not performed at all.

Consistency preservation:A correct executionof the transaction must take thedatabase fromone consistent state to another.

7/21/2019 ENCh17




*esirale Properties o& Transactions (2)

ACID properties (cont.):Isolation:A transaction should not make its updatesvisible to other transactions until it is committed; thisproperty, when enforced strictly,solves the temporary

update problem and makes cascading rollbacks oftransactions unnecessary (see Chapter 21).

Durability or permanency:Once a transaction changes

the database and the changes are committed, thesechanges must never be lost because of subsequent failure.

7/21/2019 ENCh17




4 Characteri+ing #chedules ased

on ,eco-erailit% (1)"ransaction schedule or history: 9hen transactions are e1ecuting

concurrently in an interlea"ed (ashion, the order o(e1ecution o( operations (rom the "arious transactions (orms 5hat is no5n as a transaction schedule 3or history6.

- schedule 3or history6 S o( n transactions $#, $2, ..., $n

It is an ordering o$ the operations o$ the transactions su&8ect tothe constraint that, (or each transaction $i that participates in S,the operations o( $# in S must appear in the same order in 5hich

they occur in $#. !ote, ho5e"er,

that operations (rom other transactions $; can 'einterlea"ed 5ith the operations o( $i in S.

7/21/2019 ENCh17




Characteri+ing #chedules ased on

,eco-erailit% (2)

Schedules classi$ied on recovera&ility:

9ecovera&le schedule: <ne 5here no transaction needsto 'e rolled 'ac.

=- schedule S is recovera&le i( no transaction $ in S commitsuntil all transactions $> that ha"e 5ritten an item that $ readsha"e committed.

Cascadeless schedule: <ne 5here e"ery transaction reads

only the items that are 5ritten 'y committed transactions.Schedules reuiring cascaded roll&ac; - schedule in 5hichuncommitted transactions that read an item (rom a (ailedtransaction must 'e rolled 'ac.

7/21/2019 ENCh17





,eco-erailit% (3)

Schedules classi$ied on recovera&ility #cont6%:

Strict Schedules: - schedule in 5hich a transaction

can neither read or 5rite an item 8 until the last

transaction that 5rote 8 has committed.

7/21/2019 ENCh17




5 Characteri+ing #chedules ased

on #eriali+ailit% (1)

Serial schedule - schedule S is serial i(, (or e"ery

transaction $ participating in the schedule, all the

operations o( $ are e1ecuted consecuti"ely in theschedule. <ther5ise, the schedule is called nonserial

schedule6

Seriali<a&le schedule - schedule S is seriali<a&le i(

it is e:ui"alent to some serial schedule o( the same ntransactions.

7/21/2019 ENCh17





#eriali+ailit% (2)

9esult euivalent $5o schedules are called result

e:ui"alent i( they produce the same (inal state o( the

data'ase.Con$lict euivalent $5o schedules are said to 'e

con(lict e:ui"alent i( the order o( any t5o con(licting

operations is the same in 'oth schedules.

Con$lict seriali<a&le - schedule S is said to 'econ(lict serializa'le i( it is con(lict e:ui"alent to some

serial schedule S>.

7/21/2019 ENCh17





#eriali+ailit% (3)

7eing serializa'le is not the same as 'eing serial

Being serializable implies that the schedule is acorrect schedule.

–It will leave the database in a consistent state.

–The interleaving is appropriate and will result in astate as if the transactions were serially executed, yetwill achieve efficiency due to concurrent execution.

7/21/2019 ENCh17





#eriali+ailit% (4)

Serializa'ility is hard to chec.???@

Interlea"ing o( operations occurs in an operating

system through some scheduler

&i((icult to determine 'e(orehand ho5 theoperations in a schedule 5ill 'e interlea"ed.

7/21/2019 ENCh17





#eriali+ailit% (5)

Practical approach:

Come up 5ith methods 3protocols6 to ensureserializa'ility.

It>s not possi'le to determine 5hen a schedule 'eginsand 5hen it ends. Aence, 5e reduce the pro'lem o(checing the 5hole schedule to checing only acommitted project o( the schedule 3i.e. operations (rom

only the committed transactions.6Current approach used in most &7/Ss

se o( locs 5ith t5o phase locing

7/21/2019 ENCh17





#eriali+ailit% (')

=ie/ euivalence - less restricti"e de(inition o(

e:ui"alence o( schedules

=ie/ seriali<a&ility: de(inition o( serializa'ility

'ased on vie/ euivalence6

= - schedule is view serializable i( it is

view equivalent to a serial schedule.

7/21/2019 ENCh17





#eriali+ailit% (!)

$5o schedules are said to 'e vie/ euivalent i( the (ollo5ing threeconditions hold

#. $he same set o( transactions participates in S and S>, and S andS> include the same operations o( those transactions.

2. Bor any operation Ri386 o( $i in S, i( the "alue o( 8 read 'y theoperation has 'een 5ritten 'y an operation 9;386 o( $; 3or i( itis the original "alue o( 8 'e(ore the schedule started6, the samecondition must hold (or the "alue o( 8 read 'y operation Ri386o( $i in S>.

%. I( the operation 936 o( $ is the last operation to 5rite item in S, then 936 o( $ must also 'e the last operation to 5riteitem in S>.

7/21/2019 ENCh17





#eriali+ailit% (")

"he premise &ehind vie/ euivalence:

-s long as each read operation o( a transaction reads

the result o( the same write operation in 'oth

schedules, the 5rite operations o( each transaction

must produce the same results.

>"he vie/? the read operations are said to see the same view in 'oth schedules.

7/21/2019 ENCh17





#eriali+ailit% ()

9elationship &et/een vie/ and con$lict euivalence:

$he t5o are same under constrained /rite assumption

5hich assumes that i( $ 5rites 8, it is constrained 'y the

"alue o( 8 it readD i.e., ne5 8 (3old 86 Con(lict serializa'ility is stricter than "ie5

serializa'ility. 9ith unconstrained 5rite 3or 'lind 5rite6,a schedule that is "ie5 serializa'le is not necessarilycon(lict serialia'le.

-ny con(lict serializa'le schedule is also "ie5serializa'le, 'ut not "ice "ersa.

7/21/2019 ENCh17





#eriali+ailit% (1)

9elationship &et/een vie/ and con$lict euivalence #cont%:

Consider the (ollo5ing schedule o( three transactions

$# r#386, 5#386D $2 52386D and $% 5%386

Schedule Sa r#386D 52386D 5#386D 5%386D c#D c2D c%D

In Sa, the operations 52386 and 5%386 are 'lind 5rites, since $# and $%do not read the "alue o( 8.

Sa is vie/ seriali<a&le, since it is "ie5 e:ui"alent to the serial schedule$#, $2, $%. Ao5e"er, Sa is not con$lict seriali<a&le, since it is notcon(lict e:ui"alent to any serial schedule.

7/21/2019 ENCh17





#eriali+ailit% (11)

"esting $or con$lict seriali<a&ility

!lgorithm 1761:

#. oos at only readFItem 386 and 5riteFItem 386 operations

2. Constructs a precedence graph 3serialization graph6 a graph

5ith directed edges

%. -n edge is created (rom $i to $ ; i( one o( the operations in $i

appears 'e(ore a con(licting operation in $ ;

46 "he schedule

is seriali<a&le i$ and only i$ the precedence

graph has no cycles6

7/21/2019 ENCh17




FI#$%E 17&7Constructing the precedence graphs &or schedules A and D &rom

igure 1!.5 to test &or con&lict seriali+ailit%. (a) Precedence graph &or

serial schedule A. () Precedence graph &or serial schedule B. (c)

Precedence graph &or schedule C (not seriali+ale). (d) Precedencegraph &or schedule D (seriali+ale/ e0ui-alent to schedule A).

7/21/2019 ENCh17




FI#$%E 17&

nother e$ample o& seriali+ailit% testing. (a) The

,* and ,IT operations o& three transactions

T 1/ T 2/ and T 3.

7/21/2019 ENCh17




FI#$%E 17& )continued*

nother e$ample o& seriali+ailit% testing. () #chedule E .

7/21/2019 ENCh17




FI#$%E 17& )continued*

nother e$ample o& seriali+ailit% testing. (c) #chedule F .

7/21/2019 ENCh17





#eriali+ailit% (14)

*ther "ypes o$ )uivalence o$ Schedules

nder special semantic constraints, schedules that

are other5ise not con(lict serializa'le may 5or

correctly. sing commutati"e operations o( addition

and su'traction 35hich can 'e done in any order6

certain nonserializa'le transactions may 5or

correctly

7/21/2019 ENCh17





#eriali+ailit% (15)*ther "ypes o$ )uivalence o$ Schedules #cont6%

Example: bank credit / debit transactions on a given item areseparable andcommutative.

Consider the following schedule S for the two transactions:

Sh : r1(X); w1(X); r2(Y); w2(Y); r1(Y); w1(Y); r2(X); w2(X);Using conflict serializability, it is notserializable.

However, if it came from a (read,update, write) sequence as follows:

r1(X); X := X 10; w1(X); r2(Y); Y := Y 20;r1(Y);

Y := Y + 10; w1(Y); r2(X); X := X + 20; (X);

Sequence explanation: debit, debit, credit, credit.

It is acorrect schedule for the given semantics

7/21/2019 ENCh17




6 Transaction Support in SQL2 (1)

- single S+ statement is al5ays considered to 'eatomic. Either the statement completes e1ecution5ithout error or it (ails and lea"es the data'ase

unchanged.9ith S+, there is no e1plicit 7egin $ransaction

statement. $ransaction initiation is done implicitly5hen particular S+ statements are encountered.

E"ery transaction must ha"e an e1plicit endstatement, 5hich is either a C<//I$ orR<7-CG.

7/21/2019 ENCh17




Transaction Support in SQL2 (2)

Characteristics speci$ied &y a S)"

"9!@S!C"I*@ statement in SA(:

!ccess mode: RE-& <! or RE-& 9RI$E. $he

de(ault is RE-& 9RI$E unless the isolation le"el o(RE-& !C</I$$E& is speci(ied, in 5hich case

RE-& <! is assumed.

+iagnostic si<e n, speci(ies an integer "alue n,

indicating the num'er o( conditions that can 'e heldsimultaneously in the diagnostic area. 3Supply user

(eed'ac in(ormation6

7/21/2019 ENCh17





Characteristics speci$ied &y a S)"

"9!@S!C"I*@ statement in SA( #cont6%:

Isolation level Hisolation, 5here Hisolation can 'e

RE-& !C<//I$$E&, RE-& C<//I$$E&,REPE-$-7E RE-& or SERI-IJ-7E. $he de(ault

is SERI-IJ-7E.

With SERIALIZABLE: the interleaved execution of

transactions will adhere to our notion ofserializability. However, if any transaction executesat a lower level, then serializability may be violated.

7/21/2019 ENCh17





Potential pro&lem /ith lo/er isolation levels: +irty 9ead Reading a "alue that 5as 5ritten 'y a

transaction 5hich (ailed.

@onrepeata&le 9ead -llo5ing another transaction to 5ritea ne5 "alue 'et5een multiple reads o( one transaction.

- transaction $# may read a gi"en "alue (rom a ta'le.I( another transaction $2 later updates that "alue and $#reads that "alue again, $# 5ill see a di((erent "alue.

Consider that $# reads the employee salary (or Smith. !e1t, $2 updates the salary (or Smith. I( $# reads SmithKssalary again, then it 5ill see a di((erent "alue (or SmithKssalary.

7/21/2019 ENCh17





Potential pro&lem /ith lo/er isolation levels

#cont6%:

Phantoms !e5 ro5s 'eing read using the same read

5ith a condition. A transaction T1 may read a set of rows from a table,perhaps based on some condition specified in theSQL WHERE clause. Now suppose that a transaction

T2 inserts a new row that also satisfies the WHEREclause condition of T1, into the table used by T1. IfT1 is repeated, then T1 will see a row that previouslydid not exist, called aphantom.

7/21/2019 ENCh17





Sample SQL transaction: E8EC S+ 5hene"er s:lerror go to !&<D

E8EC S+ SE$ $R-!S-C$I<!

RE-& 9RI$E

&I-L!<S$ICS SIJE )

IS<-$I<! EME SERI-IJ-7ED

E8EC S+ I!SER$

I!$< E/P<EE 3B!-/E, !-/E, SS!, &!<, S--R6M-ES 3KRo'ertK,KSmithK,KNN#004%2#K,2,%)0006D

E8EC S+ P&-$E E/P<EE

SE$ S--R S--R = #.#

9AERE &!< 2D

E8EC S+ C<//I$D

L<$< $AEFE!&D!&< E8EC S+ R<7-CGD

$AEFE!& ...

7/21/2019 ENCh17



Possi&le violation o$ seriali<a&ilty:

Type of Violation

___________________________________

Isolation Dirty nonrepeatable

level read read phantom_____________________ _____ _________ ____________________

READ UNCOMMITTED yes yes yes

READ COMMITTED no yes yes

REPEATABLE READ no no yes

SERIALIZABLE no no no

ENCh17

Documents

Transcript of ENCh17