Pokok Bahasan #5 Transactions Processing

8/9/2019 Pokok Bahasan #5 Transactions Processing

1/56

JURUSAN SISTEMINFORMASI

Program Pascasarjana

SISTEM MANAJEMEN BASISDATA

Pokok Bahasan #5Introdct!on to Transact!on

Proc"ss!ng

Fndam"nta$s o% DB& '"d(& E)masr!&*ha+( ,-.Pro%( Ir( Ar!% Djna!d/& M(Sc(& Ph(D(

[email protected]@gmail.com

1


2/56

Outline•

Introduction to Transaction Processing• Transaction and System Concepts

• Desirable Properties of Transactions

• Characteriing Schedules based on!eco"erability

• Characteriing Schedules based on

Serialiability• Transaction Support in S#$

%


3/56

Slide &

Introduction to TransactionProcessing '1(

• S!ng$"0Us"r S/st"m) – *t most one user at a time can use the system.

• M$t!s"r S/st"m) –

+any users can access the systemconcurrently.

• *oncrr"nc/ – Int"r$"a1"d +roc"ss!ng)

• Concurrent e,ecution of processes is interlea"ed in a

single CP- – Para$$"$ +roc"ss!ng)

• Processes are concurrently e,ecuted in multipleCP-s.


4/56

Slide

Introduction to TransactionProcessing '%(

• * Transact!on) – $ogical unit of database processing that includes

one or more access operations 'read /retrie"al0 rite/ insert or update0 delete(.

•

* transaction 'set of operations( may bestand/alone speci2ed in a high le"el languageli3e S#$ submitted interacti"ely0 or may beembedded ithin a program.

• Transact!on 2ondar!"s) – 4egin and 5nd transaction.

• *n a++$!cat!on +rogram may containse"eral transactions separated by the 4eginand 5nd transaction boundaries.


5/56

Slide 6

Introduction to TransactionProcessing '&(

SI+P$5 +OD5$ O7 * D*T*4*S5 'for purposesof discussing transactions()•A data2as" is a collection of named data items

•

3ran$ar!t/ of data / a 2eld0 a record 0 or a holedis3 bloc3 'Concepts are independent of granularity(

•4asic operations are r"ad and 4r!t"

– r"ad!t"m6() !eads a database item named 8into a program "ariable. To simplify our notation0

e assume that the program "ariable is alsonamed 8.

– 4r!t"!t"m6() 9rites the "alue of program"ariable 8 into the database item named 8.


6/56

Slide :

Introduction to TransactionProcessing '(

!5*D *;D 9!IT5 OP5!*TIO;S)• 4asic unit of data transfer from the dis3 to the

computer main memory is one bloc3. In general0 adata item 'hat is read or ritten( ill be the 2eld of

some record in the database0 although it may be alarger unit such as a record or e"en a hole bloc3.• read


7/56

Slide >

Introduction to TransactionProcessing '6(

!5*D *;D 9!IT5 OP5!*TIO;S 'contd.()• 4r!t"!t"m6( command includes the folloing

steps) – 7ind the address of the dis3 bloc3 that contains item

8. – Copy that dis3 bloc3 into a bu=er in main memory 'if

that dis3 bloc3 is not already in some main memorybu=er(.

– Copy item 8 from the program "ariable named 8 intoits correct location in the bu=er.

– Store the updated bloc3 from the bu=er bac3 to dis3'either immediately or at some later point in time(.


8/56

Slide ?

To sample transactions

• Consiuder to sample transactions belo) – 'a( Transaction T1 – 'b( Transaction T%


9/56

Slide

Introduction to TransactionProcessing ':(

9hy Concurrency Control is needed)• Th" )ost U+dat" Pro2$"m

– This occurs hen to transactions that access the samedatabase items ha"e their operations interlea"ed in a aythat ma3es the "alue of some database item incorrect.

• Th" T"m+orar/ U+dat" or D!rt/ R"ad. Pro2$"m – This occurs hen one transaction updates a database item

and then the transaction fails for some reason. – The updated item is accessed by another transaction before it

is changed bac3 to its original "alue.

• Th" Incorr"ct Smmar/ Pro2$"m – If one transaction is calculating an aggregate summary

function on a number of records hile other transactions areupdating some of these records0 the aggregate function maycalculate some "alues before they are updated and othersafter they are updated.

t t


10/56

Slide 1A

oncurrent e,ecut on suncontrolled)

'a( The lost update problem.


11/56

Slide 11

uncontrolled)

'b( The temporary updateproblem.


12/56

Slide 1%

uncontrolled)

'c( The incorrect summaryproblem.


13/56

Slide 1&

Introduction to TransactionProcessing '>(

9hy r"co1"r/ is needed)'9hat causes a Transaction to fail(

1. * computer failure 'system crash()* hardare or softare error occurs in the computer

system during transaction e,ecution. If thehardare crashes0 the contents of the computerBsinternal memory may be lost.

%. * transaction or system error)Some operation in the transaction may cause it to fail0

such as integer o"ero or di"ision by ero. Transaction failure may also occur because oferroneous parameter "alues or because of a logicalprogramming error. In addition0 the user mayinterrupt the transaction during its e,ecution.


14/56

Slide 1

Introduction to TransactionProcessing '?(

9hy r"co1"r/ is needed 'Contd.()'9hat causes a Transaction to fail(

&. $ocal errors or e,ception conditions detected bythe transaction)

Certain conditions necessitate cancellation of thetransaction. 7or e,ample0 data for the transaction maynot be found. * condition0 such as insucient accountbalance in a ban3ing database0 may cause atransaction0 such as a fund ithdraal from thataccount0 to be canceled.

* programmed abort in the transaction causes it to fail.

. Concurrency control enforcement) The concurrency control method may decide to abort the

transaction0 to be restarted later0 because it "iolatesserialiability or because se"eral transactions are in astate of deadloc3 'see Chapter 1?(.


15/56

Slide 16

Introduction to TransactionProcessing '(

9hy r"co1"r/ is needed 'contd.()'9hat causes a Transaction to fail(

6. Dis3 failure)

Some dis3 bloc3s may lose their data because of aread or rite malfunction or because of a dis3readErite head crash. This may happen duringa read or a rite operation of the transaction.

:. Physical problems and catastrophes) This refers to an endless list of problems that

includes poer or air/conditioning failure0 2re0theft0 sabotage0 o"erriting dis3s or tapes bymista3e0 and mounting of a rong tape by theoperator.


16/56

Slide 1:

Transaction and SystemConcepts '1(

• * transact!on is an atomic unit of or3that is either completed in its entirety ornot done at all. – 7or reco"ery purposes0 the system needs to

3eep trac3 of hen the transaction starts0terminates0 and commits or aborts.

• Transact!on stat"s) – *cti"e state –

Partially committed state – Committed state – 7ailed state – Terminated State


17/56

Slide 1>

Transaction and SystemConcepts '%(

• !eco"ery manager 3eeps trac3 of the folloingoperations) – 2"g!ntransact!on) This mar3s the beginning of

transaction e,ecution. – r"ad or 4r!t") These specify read or rite operations

on the database items that are e,ecuted as part of atransaction.

– "ndtransact!on) This speci2es that read and ritetransaction operations ha"e ended and mar3s the endlimit of transaction e,ecution.

•

*t this point it may be necessary to chec3 hetherthe changes introduced by the transaction can bepermanently applied to the database or hether thetransaction has to be aborted because it "iolatesconcurrency control or for some other reason.


18/56

Slide 1?

Transaction and SystemConcepts '&(

•

!eco"ery manager 3eeps trac3 of thefolloing operations 'cont()

– comm!ttransact!on) This signals a successfulend of the transaction so that any changes

'updates( e,ecuted by the transaction can besafely committed to the database and ill notbe undone.

– ro$$2ack 'or a2ort() This signals that the

transaction has ended unsuccessfully0 so thatany changes or e=ects that the transaction mayha"e applied to the database must be undone.


19/56

Slide 1

Transaction and SystemConcepts '(

• !eco"ery techniFues use the folloingoperators)

– ndo) Similar to rollbac3 e,cept that it

applies to a single operation rather thanto a hole transaction.

– r"do) This speci2es that certaintransaction operations must be redone toensure that all the operations of acommitted transaction ha"e been appliedsuccessfully to the database.

St t t iti di


20/56

Slide %A

State transition diagramillustrating the states for

transaction e,ecution


21/56

Slide %1

Transaction and SystemConcepts '6(

• The System $og – )og or Jorna$) The log 3eeps trac3 of all

transaction operations that a=ect the "aluesof database items.• This information may be needed to permit reco"ery

from transaction failures.

• The log is 3ept on dis30 so it is not a=ected by anytype of failure e,cept for dis3 or catastrophic

failure.• In addition0 the log is periodically bac3ed up to

archi"al storage 'tape( to guard against suchcatastrophic failures.


22/56

Slide %%

Transaction and SystemConcepts ':(

• The System $og 'cont() – T in the folloing discussion refers to a uniFue

transact!on0!d that is generated automatically by thesystem and is used to identify each transaction)

– Types of log record)•

Gstart


23/56

Slide %&

Transaction and SystemConcepts '>(

• The System $og 'cont() – Protocols for reco"ery that avoid

cascading rollbacks do not require that

read operations be written to the systemlog0 hereas other protocols reFuirethese entries for reco"ery.

–

Strict protocols reFuire simpler riteentries that do not include ne


24/56

Slide %

Transaction and SystemConcepts '?(

!eco"ery using log records)• If the system crashes0 e can reco"er to a

consistent database state by e,amining the logand using one of the techniFues described in ne,tChapter.1. 4ecause the log contains a record of e"ery rite

operation that changes the "alue of some databaseitem0 it is possible to ndo the e=ect of these riteoperations of a transaction T by tracing bac3ardthrough the log and resetting all items changed by arite operation of T to their old


25/56

Slide %6

Transaction and SystemConcepts '(

Commit Point of a Transaction)• D"7n!t!on a *omm!t Po!nt8

– * transaction T reaches its comm!t +o!nt hen all itsoperations that access the database ha"e been e,ecutedsuccessfully and the e=ect of all the transaction

operations on the database has been recorded in the log. – 4eyond the commit point0 the transaction is said to be

committed0 and its e=ect is assumed to be permanentlyrecorded in the database.

– The transaction then rites an entry Gcommit0TH into thelog.

• Ro$$ Back o% transact!ons8 – ;eeded for transactions that ha"e a Gstart


26/56

Slide %:

Transaction and SystemConcepts '1A(

Commit Point of a Transaction 'cont()• R"do!ng transact!ons8

– Transactions that ha"e ritten their commit entry in thelog must also ha"e recorded all their rite operations inthe log otherise they ould not be committed0 so theire=ect on the database can be redone from the log entries.';otice that the log 2le must be 3ept on dis3.

– *t the time of a system crash0 only the log entries thatha"e been ritten bac3 to dis3 are considered in thereco"ery process because the contents of main memorymay be lost.(

• Forc" 4r!t!ng a $og8 – 4efore a transaction reaches its commit point0 any portion

of the log that has not been ritten to the dis3 yet mustno be ritten to the dis3.

– This process is called force/riting the log 2le beforecommitting a transaction.


27/56

Slide %>

Desirable Properties of Transactions

*CID properties)

• Atom!c!t/) * transaction is an atomic unit of processing itis either performed in its entirety or not performed at all.

• *ons!st"nc/ +r"s"r1at!on) * correct e,ecution of thetransaction must ta3e the database from one consistent

state to another.• Iso$at!on) * transaction should not ma3e its updates "isible

to other transactions until it is committed this property0hen enforced strictly0 sol"es the temporary updateproblem and ma3es cascading rollbac3s of transactions

unnecessary 'see Chapter %1(.• Dra2!$!t/ or +"rman"nc/) Once a transaction changes

the database and the changes are committed0 thesechanges must ne"er be lost because of subseFuent failure.


28/56

Slide %?

Characteriing Schedulesbased on !eco"erability '1(

• Transact!on sch"d$" or h!stor/) – 9hen transactions are e,ecuting concurrently in an

interlea"ed fashion0 the order of e,ecution ofoperations from the "arious transactions forms hatis 3non as a transaction schedule 'or history(.

• * sch"d$" 'or h!stor/( S of n transactions T10 T%0 J0 Tn)

– It is an ordering of the operations of the transactionssubject to the constraint that0 for each transaction Tithat participates in S0 the operations of T1 in S must

appear in the same order in hich they occur in T1. – ;ote0 hoe"er0 that operations from othertransactions Tj can be interlea"ed ith the operationsof Ti in S.


29/56

Slide %

Characteriing Schedulesbased on !eco"erability '%(

Schedules classi2ed on reco"erability)• R"co1"ra2$" sch"d$")

– One here no transaction needs to be rolled

bac3. – * schedule S is reco"erable if no transaction T in S commits until all transactions TB thatha"e ritten an item that T reads ha"ecommitted.

• *ascad"$"ss sch"d$") – One here e"ery transaction reads only the

items that are ritten by committedtransactions.


30/56

Slide &A

Characteriing Schedulesbased on !eco"erability '&(

Schedules classi2ed on reco"erability'contd.()

• Sch"d$"s r"9!r!ng cascad"d

ro$$2ack ) – * schedule in hich uncommitted

transactions that read an item from a failedtransaction must be rolled bac3.

•

Str!ct Sch"d$"s) – * schedule in hich a transaction can neither

read or rite an item 8 until the lasttransaction that rote 8 has committed.


31/56

Slide &1

Characteriing Schedulesbased on Serialiability '1(

• Serial schedule)

– * schedule S is serial if0 for e"ery transaction Tparticipating in the schedule0 all the operations

of T are e,ecuted consecuti"ely in theschedule.• Otherise0 the schedule is called nonserial

schedule.

• Serialiable schedule)

– * schedule S is serialiable if it is eFui"alent tosome serial schedule of the same ntransactions.


32/56

Slide &%

Characteriing Schedulesbased on Serialiability '%(

• !esult eFui"alent)

– To schedules are called result eFui"alent if theyproduce the same 2nal state of the database.

•

Conict eFui"alent) – To schedules are said to be conict eFui"alent

if the order of any to conicting operations isthe same in both schedules.

•

Conict serialiable) – * schedule S is said to be conict serialiable if it

is conict eFui"alent to some serial schedule SB.


33/56

Slide &&

Characteriing Schedulesbased on Serialiability '&(

• 4eing serialiable is not the same asbeing serial

• 4eing serialiable implies that the

schedule is a correct schedule. – It ill lea"e the database in a consistent

state.

–

The interlea"ing is appropriate and illresult in a state as if the transactions ereserially e,ecuted0 yet ill achie"e eciencydue to concurrent e,ecution.


34/56

Slide &

Characteriing Schedulesbased on Serialiability '(

• Serialiability is hard to chec3. – Interlea"ing of operations occurs in an

operating system through some

scheduler – Dicult to determine beforehand ho

the operations in a schedule ill be

interlea"ed.


35/56

Slide &6

Characteriing Schedulesbased on Serialiability '6(

Practical approach)• Come up ith methods 'protocols( to

ensure serialiability.•

ItBs not possible to determine hen aschedule begins and hen it ends. – Kence0 e reduce the problem of chec3ing

the hole schedule to chec3ing only acomm!tt"d +roj"ct of the schedule 'i.e.

operations from only the committedtransactions.(

• Current approach used in most D4+Ss) – -se of loc3s ith to phase loc3ing


36/56

Slide &:

Characteriing Schedulesbased on Serialiability ':(

• Lie eFui"alence)

– * less restricti"e de2nition ofeFui"alence of schedules

• Lie serialiability)

– De2nition of serialiability based on "ie

eFui"alence. – * schedule is view serializable if it is view

equivalent to a serial schedule.


37/56

Slide &>

Characteriing Schedulesbased on Serialiability '>(

• To schedules are said to be "ie eFui"alent ifthe folloing three conditions hold)1. The same set of transactions participates in S and

SB0 and S and SB include the same operations ofthose transactions.

%. 7or any operation !i'8( of Ti in S0 if the "alue of 8read by the operation has been ritten by anoperation 9j'8( of Tj 'or if it is the original "alue of 8before the schedule started(0 the same conditionmust hold for the "alue of 8 read by operation !i'8(of Ti in SB.

&. If the operation 93'M( of T3 is the last operation torite item M in S0 then 93'M( of T3 must also be thelast operation to rite item M in SB.


38/56

Slide &?

Characteriing Schedulesbased on Serialiability '?(

• The premise behind "ieeFui"alence)

– *s long as each read operation of a

transaction reads the result of the samewrite operation in both schedules0 therite operations of each transaction mustproduce the same results.

– NTh" 1!"4) the read operations are saidto see the same view in both schedules.

h i i h d l


39/56

Slide &

Characteriing Schedulesbased on Serialiability '(

• R"$at!onsh!+ 2"t4""n 1!"4 andcon:!ct "9!1a$"nc") – The to are same under constra!n"d 4r!t"

assm+t!on hich assumes that if T rites

80 it is constrained by the "alue of 8 it readi.e.0 ne 8 f'old 8( – Conict serialiability is str!ct"r than "ie

serialiability. 9ith unconstrained rite 'orblind rite(0 a schedule that is "ie

serialiable is not necessarily conictserialiable.

– *ny conict serialiable schedule is also "ieserialiable0 but not "ice "ersa.

Ch i i S h d l


40/56

Slide A

Characteriing Schedulesbased on Serialiability '1A(

• !elationship beteen "ie and conicteFui"alence 'cont() – Consider the folloing schedule of three transactions

• T1) r1'8(0 1'8( T%) %'8( and T&) &'8() – Schedule Sa) r1'8( %'8( 1'8( &'8( c1 c% c&

• In Sa0 the operations %'8( and &'8( are blindrites0 since T1 and T& do not read the "alue of8. –

Sa is "ie serialiable0 since it is "ie eFui"alent tothe serial schedule T10 T%0 T&. – Koe"er0 Sa is not conict serialiable0 since it is not

conict eFui"alent to any serial schedule.

Ch i i S h d l


41/56

Slide 1

Characteriing Schedulesbased on Serialiability '11(T"st!ng %or con:!ct s"r!a$!;a2!$!t/8

– $oo3s at only read


42/56

Slide %

Constructing the PrecedenceQraphs

• Constructing the precedence graphs for schedules * and D to test for conictserialiability. – 'a( Precedence graph for serial schedule *. – 'b( Precedence graph for serial schedule 4. – 'c( Precedence graph for schedule C 'not serialiable(. – 'd( Precedence graph for schedule D 'serialiable0 eFui"alent to schedule

*(.

5 l f i li bilit


43/56

Slide &

5,ample of serialiability Testing '1(

5 l f S i li bilit


44/56

Slide

5,ample of Serialiability Testing '%(

5 l f S i li bilit


45/56

Slide 6

5,ample of Serialiability Testing '&(

Ch t i i S h d l


46/56

Slide :

Characteriing Schedulesbased on Serialiability '1%(Oth"r T/+"s o% E9!1a$"nc" o%

Sch"d$"s

• -nder special s"mant!c constra!nts0

schedules that are otherise notconict serialiable may or3 correctly.

– -sing commutati"e operations of addition

and subtraction 'hich can be done inany order( certain non/serialiabletransactions may or3 correctly

Ch t i i S h d l


47/56

Slide >

Characteriing Schedulesbased on Serialiability '1&(

Other Types of 5Fui"alence of Schedules 'contd.(• 5,ample) ban3 credit E debit transactions on a

gi"en item are s"+ara2$" and commtat!1". – Consider the folloing schedule S for the to

transactions) – Sh ) r1'8( 1'8( r%'M( %'M( r1'M( 1'M( r%'8(

%'8( – -sing conict serialiability0 it is not s"r!a$!;a2$". – Koe"er0 if it came from a 'read0update0 rite(

seFuence as follos)

• r1'8( 8 ) 8 R 1A 1'8( r%'M( M ) M R %Ar1'M(• M ) M 1A 1'M( r%'8( 8 ) 8 %A '8(

– SeFuence e,planation) debit0 debit0 credit0 credit. – It is a correct schedule for the given semantics

T ti S t i S#$%


48/56

Slide ?

Transaction Support in S#$%'1(

• * s!ng$" S#$ statement is alaysconsidered to be atom!c. – 5ither the statement completes e,ecution

ithout error or it fails and lea"es thedatabase unchanged.

• 9ith S#$0 there is no e,plicit 4egin Transaction statement. – Transaction initiation is done implicitly hen

particular S#$ statements are encountered.

• 5"ery transaction must ha"e an e,plicitend statement0 hich is either a CO++ITor !O$$4*C.

T ti S t i S#$%


49/56

Slide

Transaction Support in S#$%'%(

Characteristics speci2ed by a S5T T!*;S*CTIO; statement in S#$%)

• Acc"ss mod")

– !5*D O;$M or !5*D 9!IT5.• The default is !5*D 9!IT5 unless the isolation le"el

of !5*D -;CO+ITT5D is speci2ed0 in hich case!5*D O;$M is assumed.

• D!agnost!c s!;" n0 speci2es an integer

"alue n0 indicating the number ofconditions that can be held simultaneouslyin the diagnostic area.

T ti S t i S#$%


50/56

Slide 6A

Transaction Support in S#$%'&(

Characteristics speci2ed by a S5T T!*;S*CTIO; statement in S#$% 'contd.()

• Iso$at!on $"1"$ UisolationV0 hereUisolationV can be !5*D -;CO++ITT5D0

!5*D CO++ITT5D0 !5P5*T*4$5 !5*D orS5!I*$IW*4$5. The default isS5!I*$IW*4$5. – 9ith S5!I*$IW*4$5) the interlea"ed e,ecution

of transactions ill adhere to our notion ofserialiability.

– Koe"er0 if any transaction e,ecutes at a loerle"el0 then serialiability may be "iolated.

T ti S t i S#$%


51/56

Slide 61

Transaction Support in S#$%'(

Potential problem ith loer isolation le"els)• D!rt/ R"ad)

– !eading a "alue that as ritten by a transactionhich failed.

•

Nonr"+"ata2$" R"ad) – *lloing another transaction to rite a ne "aluebeteen multiple reads of one transaction.

– * transaction T1 may read a gi"en "alue from a table.If another transaction T% later updates that "alue and

T1 reads that "alue again0 T1 ill see a di=erent

"alue.• Consider that T1 reads the employee salary for

Smith. ;e,t0 T% updates the salary for Smith. If T1reads SmithXs salary again0 then it ill see a di=erent"alue for SmithXs salary.

Transaction Support in S#$%


52/56

Slide 6%

Transaction Support in S#$%'6(

• Potential problem ith loer isolationle"els 'contd.() – Phantoms)

•

;e ros being read using the same readith a condition. – * transaction T1 may read a set of ros from a

table0 perhaps based on some condition speci2ed inthe S#$ 9K5!5 clause.

–

;o suppose that a transaction T% inserts a nero that also satis2es the 9K5!5 clause conditionof T10 into the table used by T1.

– If T1 is repeated0 then T1 ill see a ro thatpre"iously did not e,ist0 called a phantom.

Transaction Support in S#$%


53/56

Slide 6&

Transaction Support in S#$%':(

• Sample S#$ transaction) 585C S#$ hene"er sFlerror go to -;DO585C S#$ S5T T!*;S*CTIO;

!5*D 9!IT5DI*Q;OSTICS SIW5 6ISO$*TIO; $5L5$ S5!I*$IW*4$5

585C S#$ I;S5!TI;TO 5+P$OM55 '7;*+50 $;*+50 SS;0 D;O0 S*$*!M(L*$-5S 'X!obertX0XSmithX0X1AA&%1X0%0&6AAA(

585C S#$ -PD*T5 5+P$OM55S5T S*$*!M S*$*!M Z 1.19K5!5 D;O %

585C S#$ CO++ITQOTO TK5


54/56

Slide 6

Transaction Support in S#$%'>(

• Possible "iolation of serialiabilty) Type of Liolation

Isolation Dirty nonrepeatablele"el read readphantom


55/56

Slide 66

Summary

• Transaction and System Concepts

• Desirable Properties of Transactions

•

Characteriing Schedules based on!eco"erability

• Characteriing Schedules based onSerialiability

• Transaction Support in S#$


56/56

TERIMA

Documents

Pokok Bahasan #5 Transactions Processing