Tài liệu Database Systems: The Complete Book- P11 ppt

1. START thc scLt of transactio~~s that have started. but not yet completed va!idation. For each transaction T in this set. the scheduler maintains ST.4R-1 (T). the tilnc at which T started. 2. K4L; the set of transactions that have been validated hut not yet finished tlie n-riting of phase 3. For each transaction T in this set, the scheduler niairitains both srr \nr(T) and \:-\L(T), the time at which T valiciated. Sote that \~L(T) is also thc time at which T is irnagined to execute ill the hypotlirtical serial order of esccutioi~. 3. FIIV: the set of trai~sactio~is that have corripletcd phase 3. For thesc tra~isactions T, the scheduler records START(T), \' \I.(T), and FIS(T): the time at which T finished. In principle this set grows, but as a-e shall see. n-e do not havc to remember transaction T if ~ln(T) < ST.~KT(C-) for any actir~c transaction U (i.e for any U in START or VAL). The scheduler may thus periodically purge the FIN set to keep its size from growing beyond bounds. 18.9.2 The Validation Rules If rnaintaincd by the scheduler. the information of Section 18.9.1 is cnotigh for it to detect any potential violation of the assulned serial order of the transac- tions - the order in which the trai~sactions validate. To understand tlie rules. Irt us first consider what can be I\-long ~vhe~i w\-r try to validate a transaction T. T reads X / U writes X U stalt T start U validated T validating Figure 18.43: T cannot ~alidate if an earlier transaction is nolv ~viiting some- thing tlrat T slioulci have rcati 1. Supposcx tlir~rc, is ;I transaction L7 sur.11 t11;it: (a) C is in 1/;-lL or FLV: that is. C- has vnlid;~tcd. (b) FIS(C) > s'I-~\RT(T): that is, C tiid not finish beforc T started.'" - - '"ore tlrat if 1: is in VAL. then C has not yet firris11c.d when ?. validates. In that case. FIX((.') is trclirricall?. l~ndefined. Holvever. we lirlon. it mrlst he largpr than ST;\KT(T) in this case. (c) RS(T) n nls(U) is not empty; in particular, let it contain database elenlent S. Then it is possible that U wrote S after T read S. In fact. I/' may not even have written A' yet. -2 situatiorl where LT wrote X, but not in time is shown in Fig, 18.43. To interpret the figure. note that the dotted lines connrct the eyents in real time ~vith the time at which they xvould have occurred had transactions bee11 executed at the molnent they validated. Since n.e don't kno~v n-hether or not T got to read li's value, \ve must rollback T to avoid a risk that the actions of T and U will not be consistent ~vitli the assumed serial order 2. Suppose there is a transaction U such that: (a) U is in VAL: i.e., U has successfully validated. (h) FIS(U) > \:-\L(T); that is, U did not finish before T entered its validation phase. (c) \vs(T) n \\.s(U) # 0: in particular. let S be in both \\-rite sets. Thcn the potential probleni is as sho~vn ill Fig. 18.44. T and li must both \\rite values of S, and if \vc let T validate. it is possible that it will wiite S before I- does. Since \ve cannot be sure. ne rollback T to make sure it does not violate the assumed serial order in which it follo~s C'. T writes X I U writes X D. validated T validating U finish Figure 18.41: T cannot validate if it co~ild tl~en mite something ahead of an earlier transaction Tile two descrillpd above are the only situations in I\-hich a write T could I,e pl~~sically ullrcalizablt. In Fig. 15.43. if C finished before 7' starred. tlle~l sure]!. T lv0~~ltl read tlic va111c of S that either c- or sollle later trallsaction n.roce. In Fig. 18.44. if C. finished hefore T validated. then surely C' lvrote .y before T did. \Ye may tli~ls sunllnarize these observations with the follon-ing rule for validating a transaction T: Check that RS(T) n \\.s(U) = 0 for any previously validated C' that did not finish before T startcd, i.e if FIS(~) > START(T). Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 982 CHAPTER 18. COAiCURRENCY C'OXTROL Check that wS(T) n WS(U) = 0 for any previously validated U that did not finish before T validated, i.e., if FIS(U) > v.%L(T). Example 18.29 : Figure 18.45 shows a time line during which four transactiorls T, U, V, and IV attempt to execute and validate. The read and write sets for each transaction are indicated on the diagram. T starts first, although U is the first to validate. Figure 18.45: Four transactiorls and their validation 1. \'alidation of U: When U validates there are no other validated transac- tions, so there is nothing to check. U validates successfully and writes a value for database element D. 2. \lidation of T: When T validates, LT is validated but not finished. Thus. lve must check that neither the read nor write set of T has anything in common with WS(U) = {D). Since RS(T) = {.4. B). and m(T) = { I, C), both checks are successfiil. and T validates. 3. \%lidation of IT: \lilien 17 validates. li is validated and finished. and T is validated but not finishtd Also. I' started hefore C finished 711~5. ne n~ust compare bath RS(I') and n ~(13 against ws(T) Lilt onlv RS(I .) nerds to be compared against \\.s(l*). \\e find: RS(~-) n us(T) = {B) n {-4.C) = 0. . ns(17) n ~zs(T) = {D, E) n {-4.C) = 0 . RS(~*) n ~(u) = {B) n {D) = 0. Thus, I - also validates successfully. 18.9. C04CL7RRE~1'CY CONTROL BY VALID-4T10hT 983 I Just a Moment I lrou may have been concelned xvith a tacit notion that validation takes place in a moment, or indivisible instant of time. For example, we i~nagine that vie can decide whether a transaction U has already validated before we start to validate transaction T. Could U perhaps finish validating while n-e are xalidating T? If we are running on a uniprocessor system, and there is only one scheduler process, we can indeed think of validation and other actions of the scheduler as taking place in an instant of time. The reason is that if the scheduler is validating T, then it cannot also be validating U, so all during the validation of T, the validation status of U cannot change. If I\-e are running on a multiprocessor, and there are several sched- uler processes, then it might be that one is validating T while the other is validating U. If so, then we need to rely on whatever synchroniza- tion mechanism the ~nultiprocessor system provides to make validation an atomic action. 4. Iralidation of 15': \'i;hen \IT validates, ~\-e find that U finished bcfore Ili started. so no co~nparison betwen IV and U is performed. T is finished before 11. validates but did not finish before Ti7 started, so [ve compare onl\- RS(TV) with \j's(T). I. is validated but not finished. so xe need to cornpale both ~s(T1') arid I\ ~(11~) with ws(T). These tests are: ~s(rl/) n ws(~) = {A4. D) n { l;C) = {.A). ~s(rv) n ws(l') = {.4. D) n {D. E} = {Dl. \vs(11-) n ws(17) = { I. C) n {D; E) = 0. Since the i~ltersections are not all empty. Ti7 IS not validated. Rather, TIT is rolled back and does not write values for I or C. 18.9.3 Comparison of Three Concurrency-Control Mechanisms Tile tllrce approaches to serializabllity that n-e have collsidered locks. times- tamps. and validation - each have their advantages. First. they can be corn- pared for their storage utilization: Locks: Space in the lock table is proportional to the number of database elements locked. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Tzmestamps: In a naive implementation, space is needed for read- and write-times with every database element, nhether or not it is currently accessed. However, a more careful implenlentation \%-ill treat all times- tamps that are prior to the earliest active transaction as "minus infinity.' and not record them. In that case. we can store read- and write-times in a table analogous to a lock table, in which only those database elements that have been accessed recently are mentioned at all. Validation: Space is used for timestamps and read/\vrite sets for each currently active transaction, plus a few more transactions that finished after some currently active transaction began. Thus, the amounts of space used by each approach is approximately propor- tional to the sum over all active transactions of the number of database elenle~lts the transaction accesses. Timesta~nping and validation may use slightly more space because they keep track of certain accesses by recently committed trans- actions that a lock table ~vould not record. X poter~tial problem with validation is that the w~ite set for a transaction must be known before the xrites occur (but after the transaction's local cornputation has been conlpleteti). It'e can also conipare the methods for their effect on the ability of transac- tions to complete tvithout delay. The performance of the three methotfs depends on whether interaction among transactions (the likelihood that a tra~lractioci will access an elenlent that is also being accessed by a concurrent transaction) is high or low. Locking delays transactions but avoids rollbaclts. even ~vhen interactio~l is high. Tiniestamps and validation do not delay transactions. but call cause them to rollback, which is a niore serious form of delay and also ~~astes resources. If interference is lo\v. then neither timestamps nor validation ~vill cause many rollbacks. and may be preferable to locking because they generally have lolver overhead than a locking scheduler. \\-hen a rollback is necessary, tinlestamps catch some proble~ns earlier than validation, which altx-ays lets a transactioll do all its i~iter~lal n-ork before considering whether the transaction niust rollback. 18.9.4 Exercises for Section 18.9 Exercise 18.9.1 : In the follo~vi~lg scquc.nccs of events. \\e IISP R,(.\-) to mcnn "transaction T, starts, and its read set IS the list of databa~e elc~nents S." =\lqo. I/, lrieans .'T, attempts to talidate." and II;(.Y) lneans that T, finishes. and its write set was S." Tell nhat happens n-lien each sequence is piocessect bj a validation-based scheduler. * a) R1(.4.B); Rr(B,C); 1;; R3(C. D): 15: II;(.4): I>: TI:L(,4): 11;(B): b) R1(-4.B): R2(B,C): Vl; Rs(C,D), t:; fT-1(~4); 15: 11'2(A4); 1i73(~): C) R1(.4.B); Rr(I3.C); 15; R3(C. D): 15; II7l(c): 1:; 11'2(-+1): 1ir3(D); d) R1(-4.B); R2(B.C): R3(C); V1: i5; If3; llTl(-4): Ilr2(B); fv3(c): e) Rl( I.B); R2(B.C); R3(C); 1;: 1;: V3; ll'-l(C): 11-z(B); 1i73(>4): f) Rl(-4.B): R2(B, C); R3(C); 11: 1;: 1;; Ll-1 (-4) I17z(C): 1$-3(B): 18.10 Summary of Chapter 18 + Conszstent Database States: Database states that obey xhatever i~nplied or declared constraints the designers inte~lded are called consistent. It is essential that operations on the database preserve consiste~lcy. that is. they turn one consistent database state into anothel. + Cons~stenc~ of Concurrent Transacttons: It is normal for several trans- actions to have access to a database at the same time. Trarisactions, run 111 isolation, are assumed to preserve consistency of the database. It is the job of the scheduler to assure that concurrently operating transactions also preserxe the consistency of the database. + Schedrrles: Tra~lsactions are brokcn into actions, lnaillly reading and writ- i~lg from the database. X sequcnce of these actions from one or more tra~lsactiolls is called a schedule. + Serial Schedules: If trallsactio~ls esecutc ollf ar a time, the s~ht!du!C is said to be serial. + Serializable Schedules: i schcdnle that is equivalent in its effect on the database to sollle serial schedule is said to bc serializable. 111terlcat-i11g of actions from transactions is I~ossible in a serializable schedule that I I is not itself serial, but \ye 1llust ver?- careful what sequences of actions I i m-e allol3 or all interlea\-ing \vill Iea~e the database in an inconsistent state. + Conflict-se~alirabi~ity: -1 ii~nple-to-te~t. sufficient condition for serializ- ability is that the schedule can be made serial by a sequellce of stvaps of adjacellt actiolls \vithout conflicts. Such a schedule is called conflict- sPrialixa]lle. ;\ collflicr occurs if ~vc try to snap tn-o actions of the same transaction. or to sXvap tXyo ac.tio~~s that acccss the same datalxsr elenlent. at least one of ~vhich actions is ~vritc. + PVecedence Gmyhs: .in easy tcst for cullflirt-serializal~ility is to construct a precedellce graph for the schedule. Sodes correspond to transactions. and there is an arc T + C if some action of T in the schedule conflicts n-itIl a later action of c. .\ schedule is conflict-serializable if and onl> if the precedence graph is ac\-clic. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CH IPTER 18. CONCURRESCY COSTROL + Locking: The most common approach to assuring serializable schedules is to lock database elernents before accessillg them, and to release the lock after finishing access to the element. Locks on an eleluent prevent otlier transactions from accessing the element. + TWO-Phase Lockzng: Lorking by itself does not assure serializability. How- ever, two-phase locking, in which all transactions first enter a phase ~vhere they only acquire locks, and then enter a phase diere they only release locks. will guarantee serializability. + Lock Modes: To a\-oitl locking out transactions unnecessarily, systems usually use several lock modes, with different rules for each lriode about when a lock can be granted. Most common is the system with shared locks for read-only access and esclusive locks for accesses that include writing. + Compatzbzlzty Matrzces: A compatibility matrix is a useful summaiy of . xhen it is legal to grant a lock in a certain lock mode, given that there may be other locks, in the same or other rnocles, on the same elelnent. + Update Locks: A scheduler can allow a transactiori that plans to read and then write an element first to take an update lock, and later to upgrade the lock to esclusive. Update locks call be granted hen there are already shared locks on the elcmerit: but once there, an update lock prevents vtlier locks from being granted on tliat element. + Increment Loch: For the common case where a transaction nanti only to add or subtract a constant from an element, an increment lock is suitable. Increnlent locks on the sanie elelne~lt do not conflict n-it11 each other. although they conflict bit11 shared and esclusi~e locks. + Locking Elements Li'zth a GI-u~zularfty Hzerarchy: \\-hell both large and srnall elenients - relations, disk; blorks. and tuples, perhaps - may need to be locked, a ~va~lling system of locks enforces serializability. Tra~lsac- tions place intention locks on large elements to warn other transactions that tliey plan to access one or more of its subelements. + Locking Elemen,ts .irmnged in a Tree: If database elements are only ac- cessed by moving dolvn a tree. as in a 13-tree index, then a non-tn-o-phase locking strategy call enforce serializability. The rules require a lock to 11e held on the parent n-llilt, obtaining a lock on tlic child. altliough the lock on the parent c;111 then be rtlleasrd anti adtlitiorial locks taken latcr. + Optimistic Concurrency Control: Instead of locking, a scheduler can as- sume transactions dl be scrializahle. and abort a transactiori if some potentially nonserializable behavior is seen. This approach, called opti- mistic, is divided into timestamp-based, and validation-based scheduling. REFERESCES FOR CII.4PTER 18 + Timestamp-Based Schedulers: Tliis type of scheduler assigns tirnesta~ilps to transactio~ls as they begin. Database elements have associated read- and write-times, \\.!lich are the tiniestanlps of the transactions that most recently 1;erformed those actions. If an irnpossible situation, such as a read by one transaction of a value that sas written in that transaction's future is detected. the violating transaction is rolled back, i.e., aborted and restarted. + Val2dntfon-Based Schedrrlers: These schedlilers validate transactions after tliey haye read pverything they need, but before they write Trar~sactions that have wad. or \v111 nritc, an elenient that some other transaction is in the ploccss of xvriting. nil1 have an ambiguous result, so the transaction is not val~dated. A transaction that fails to validate is rolled back. + Mr~ltiverszon Timestamps: A common technique in practice is for read- only transactiolls to l~e scheduled by timestamps. but with multiple ver- sio~is, rvhere a !\-rite of an element does not overwrite earlier values of that ele~nent until all transactions that could possibly need the earlier value have finished. IYriting transactions are scheduled by conventional locks. 18.11 References for Chapter 18 The book [GI is an important source for niaterial on scheduling, as well as locking. [3] is another important source. Two recent surveys of concurrency control are [I21 alid [Ill. Probably tlie most significant paper in the field of transaction processing is [4] on two-phase locking. Tlle ~varning protocol for hierarchies of granularity is from [3]. Son-tx-o-phase locking for trees is from [lo]. The compatibility matrix was introduced to study behavior of lock modes ill [7]. Timestaiups as a concurrency control rilethod appeared in [2] and [I]. Sched- uling by ~alidation is from [a]. The use of riiultiple versions was studied by [9]. 1. P. .\. Brln>tein arid 1. Goodman. Ti~nestamp-based algorithms for con- currency control ill distributed database systems." Proc. Intl. COIL~. on l'ery Large Databnses (1980). pp. 28.3-300. 2. P. ;\. Benlstein. S. Goodman. J. 13. Rothnie, Jr and C. H. Papadirn- itriou. -Anal\-4s of sprializabiIity in SDD-1: a system of distributed data- bases (the full rcdlrrlda~lt case)." IEEE Tra11,s. on Software En,g~:neering SE-4:3 (197S). pp. 1.54-168. 3 P. .A. Bclnitein. \ Hadlilncoi. ant1 S Goodman. Concu~rency Corltrol and Recocery 171 Datrrbnsr: Sgstems. Iddlson-IYesley. Reading \IX, 1987. 1. K. P. Esn-amn. J. S. Gray. R. -1. Lorie, and I. L. Traiger. "The notions of consistency and pledicate locks in a database system." Comm. iiCM 19:ll (1976). pp. 624-633. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 988 CII.4PTER IS. CONCURRENCY CONTROL 5. J. N. Gray, F. Putzolo. and I. L. Traiger. "Granularity of locks and degrees of consistency in a shared data base," in G. AI. Sijssen (ed.), JJodelzng zn Duta Base 121anngen~ent Systems, North Holland, Amsterdam. 19iG. 6. J. X. Gray and A. Reuter, 'II-nnsaction Processing: Concepts and Tech- nzques, Morgan-Kaufrnann. San Francisco, 1993. 7. H. F. Korth, "Locking primitives in a database system," J. ACM 30:l (19831, pp. 55-79. 8. H T. Kung and J. T. Robinson, "Optimistic concurrency control,.' ACM Trans. on Database Systems 6:2 (1981), pp. 312-326. 9. C. H. Papadimitriou and P. C. Kanellakis, "On concurrency control by multiple versions," ACM Trans. on Database Systems 9:l (1984), pp. 89- 99. 10. A. Silberschatz and 2. Kedem, "Consistency in hierarchical database sys- ' terns," J. ACM 273 (1980). pp. 72-80. 11. A. Thomasian, "Concurrency control: methods, performance: and analy- sis," Computing Surveys 30:l (1998), pp. 70-119. 12. B. Thuraisingham and H P. KO, "Concurrency control in trusted data- base managelner~t systems: a survey," SIGMOD Record 22:4 (1993), pp. 52-60. Chapter 19 More About Transaction Management 111 this chapter we cover several issues about transaction managelllent that were not addressed in Chapters 17 or 18. If7e begin by reconciling the points of vien- of these two chapters: how do the needs to recover from errors, to allow transactions to abort: and to maintain serializability interact? Then, we discuss the management of deadlocks aillong transactions: which typically result from several transactio~ls each having to wait for a resource, such as a lock, that is held by another transaction. This chapter also incllldes an introduction to distributed databases. IVe focus on ho1v to lock elements that are distributed among several sites, perhaps with replicated copies. Ke also consider how the decision to co~nmit or abort a transaction can be rnade ~vhen the transaction itself involves actions at several sites. Finally, consider the problems that arise due to ''long transactions." There are applications, such as CAD syste~lls or "workflow" systems, in which llumaii and conlputer processes interact, perhaps over a period of days. These systelns. like short-transaction systems such as banking or airline reservations, need to preserl-e consistency of the database state. Ho\T-ever, the concurrexlcy- control methods discussed in Chapter 18 do not rvork reasonably when locks are held for days, or decisions to validate are based on events that 'happened days in the past. 19.1 Serializability and Recoverability In Chapter 17 Xve discussed the creation of a log and its use to recover the database state when a system crash occurs. \Ye introduced the vie\\- of database cornputatio~l in which values move bet\\-ecn nonvolatile disk, volatile ~nain- menlor? and the local address space of transactions. The guarantee the various Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 090 CHAPTER 19. AIORE ABOUT TRAj\'SACTION JIALVL4GE-IIEIVT logging methods give is that, should a crash occur, it ~57ill be able to reconstruct tlie actions of the committed transactions (and only the committed transac- tions) on the disk copy of the database. A logging system makes no attempt to support serializabil~ty; it w~ll blindly reconstruct a database state, even if it is the result of a noriserializable schedule of actions. In fact, commercial database systems do not always insist on serializabilit~; and in sorne systems. serializability is enforced only on explicit request of the user. On the othcr hand, Chapter 18 talked about serializability only. Scliedulels designed according to the principles of that chapter may do things that the log manager cannot tolerate. For instance, there is nothlng in the serializability definition that forbids a transaction with a lock on an element A from writing a new value of A into the database before committing, and thus violating a rule of the logging policy. \Verse, a transaction might write into the database and then abort without undoing the Ivnte, which could easily result in an incon- sistent database state, even though there is no system crash and the scheduler . theoretically maintains serializability. 19.1.1 The Dirty-Data Problem Recall from Section 8.6.5 that data is "dirty" if it has been written by a trans- action tliat is not yet committed. The dirty data could appear either in the buffers, or on disk, or both; either can cause trouble. A := A+100; wl(d); Il(B); ul(:l); 125 12 (.A); 7'2 (.A); A := A*2; wq (.A) ; 250 12 (B) Denied ~1 (B); Abort; ul(B); /2(B): 112 (24); r2 (B): B := B*2: tc,,(B): 112(O); .5 0 Figure 19.1: TI writes dirty data and then aborts Example 19.1 : Let us rcconsider the serializable schedule from Fig. 18.13. but suppose that after reading B, TI has to abolt for sonic reason. Then tlie sequence of events is as in Fig. 19.1. After Tl aborts, the sclieduler releases the lock on B that TI obtained; that step is essential, or else the lock on B would be unavailable to any other transaction, forever. Ho~i-ever, T2 has now read data that does not represent a consistent state of the database. That is, ?r2 read the value of -4 that TI changed, but read the value of B that existed prior to Ti's actions. It doesn't matter in this casc whether or not the value 125 for il that TI created n-as mitten to disk or not; ?'? gets that value from a buffer, regardless. As a result of reading an incorlsistcr~t state, T2 leaves the database (on disk) with an inconsistent state, where -4 # B. The problem in Fig. 19.1 is that -4 ~vritten by TI is dirty data, whether it is in a buffer or on disk. The fact that 1; read -4 and used it in its on-n calculation makes z's actions questionable. -1s we shall see in Section 19.1.2. it is necessary, if such a situation is allowed to occur, to abort and roll back T2 as \\-ell as TI. Figure 19.2: TI has read dirty data from T2 and nlust abort n-hen Tl docs Example 19.2 : Sow, consider Fig. 19.2.1~11ich sho~vs a sequellce of actions i~n- der a timestamp-based scheduler as in Section 18.8. Ho~vever: lye ilnagille that this sclleduler does not use the colnrnit bit that \\-as introduced in Section 18.8.1. Recall that, the purpose of this bit is to prevent a value that !\-as n-ritten b>- an uncommitted transaction to be read by anot,her transaction. Th~s, when TI reads B at the second step, there is no co~nmit-bit check to tell TI to delay. TI can pr.oceed and could eve11 write to disk and commit; we haye not shoiv11 further details of 1v11at Tl dors. Eyei~tually. 7; tries to ~i-ritc C in a ph!.sically unrealizable \\-a?. and T2 aborts. The effecr of fi's prior write of B is cancelled: the value and \\-rite-ti~np of B is reset to 1~11at it was before T2 wrote. I-et TI has been allo~i-?ti to use this cancelled value of B and can do anything ~ith it: such as using it to conlpute nex values of .A. B, and/or C and ~vriting them to disk. Thus. TI? ha\-ing read a dirty value of B, can cause an inconsistellt database state. Xote that. had the commit bit been recorded and used, the read rl(13) at step (2) would have Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 992 C'H-4l'TER 19. MORE ABOUT TRA.VSS-iCTION AI-A-YilGElIEST I 19.1, SERI.~LIZ ~BILITY 1SD RECOVERABI~~ITI- 993 been delayed, and not allowed to occur until after T2 aborted and the value of B had been restored to its previous (presumably committed) value. 19.1.2 Cascading Rollback AS xe see from the exam~~les above, if dirty data is available to transactions, then \ve so~netilnes have to perform a cascading rollback. That is, when a transaction T aborts, we must determine ~vhich tralisactions have read data written by T, abort thein: and recursively abort any tralisactions that have read data written by an a.borted transaction. That is, we must find each transaction L' that read dirty data written by T, abort C': find any transaction 5- that read dirty data from li, abort V: and so on. To cancel the effect of an aborted transaction, we can use the log, if it is one of the types (undo or undo/redo) that provides former ~ralalues. We may also be able to restore the data from the disk copy of the database, if the effect of the dirty data has not migrated to disk. These approaches are considered in the next section. As Jve have noted, a ti~ncstamp-based scheduler witti a conlrnit bit pre- vents a transaction that rnay Ilax-e read dirty data from proceeding, so there is no possibility of cascading rollbaclc xvith such a scheduler. -4 validation-based sclieduler avoids cascading rollback, because ~vriting to the database (el-en in buffers) occurs only after it is determined that the transaction JX-ill colnmit. 19.1.3 Recoverable Schedules In order for any of the logging metllods ~ve Ilave discussed in Chapter 17 to ailon- 1-ecovery. the set of transactions that are regarded as committed after recol-el?- must be consistent. That is. if a transaction TI is, after recovery. rega~drd as committed, and Tl used a value written by G, the11 T2 must also remain committed. after recovei 5 Thus, n e define: -1 schedule is rccove~able if earh tra~lsaction coinmits only after each tians- action from n-hlcli it lias read lias committed. Example 19.3: 111 this and several subsequent exa~nples of schedules n-it11 read- and n-rite-actions, we shall use c, for the action .'transaction T, commits." Here is an example of a recoverable schedule: Sl : IC, (A): ICI (B): w2 (-4): r2 (B): cl : r2: Sote that 2'2 reacts a value (B) \nitten by TI. so T2 must rol~imit aftcr TI for the sclledr~lc to l~e rccovcrable. Scliedule S1 above is evidently serial (and tllerefore sc~ializablc) as n-ell as recoverable, but the two concepts are orthogonal. For instance, the following variation on SI is still recoverable, but not serializable. In schedule S2, T2 must precede TI in a serial order because of the writing of -4. but TI ~liust precede T2 because of the n-ritirlg and readillg of B. Fillally. observe the follotving variation on S1. \vllich is serializable but not rccoveiable: In sclledule S3: TI precedes T2: but their cornrnitrne~lts occur in the wrong order. If before a crash. the corlllllit record for T'2 reachcd disk, but the conllnit record for Ti did 11ot. then regardless of whether u~ldo, redo, or urldo/redo logging ,$-ere used: 6 ~votild be committed after recovery, but Tl would not. fJ Irl order fc,r schpclules to be truly recoverable under ally of the three loggilrg methods, there is one additional assiiniption ac nlust make re- garding schedules: The log's colllmit records reach disk in the order in which they are written. As 15-c observed in Example 19.3 concerning sclirdule Sg. should it be possible fol coniniit records to reach di4k in the wrong order. then consistent lecovery might be iInllossible, \ye return to a~id exploit this prillciple in Section 19.1.6. 19.1.4 Schedules That Avoid Cascading Rollback Recoverable sclletiules solnetimes require cascading rollback. For instance, if after first four steps of ~clicdule S1 in Esnl~iple 19.3 TI had to roll back, it n-ould be lleccssary to roll back TL, as n-ell. To guar:lntec the absence of cascadillg rollback, lleed a stronger co~lditioll tlian rccowrabilit~. 11'~ Siiy that : -1 schedule olioids cascarlzng rollback (or -is an .4CR schedfile") if trans- actions ma! lead only values written 11.1. co~lnnitted tiansactions. Put allotller \v\-a\ a11 XCR schedule forbids the rcadi~ig of dirty data. As for re- col-erablc sclledules. \ye assume that "comlnitted" ~neans that the log's comn~it record has reaclled disk. Exalllple 19.4 : 5clicdules of Exalnple 19.3 are not -1CR. 111 each case. T2 reads B frolll the uncomniitted transaction TI. Hon-ever. consider: son., T? rends B ollly after TI. thc transaction that last n.rotc B. has colnlnit- red. alld its log record n-rittc~i to disk. Thus. sc,hcdnle S1 is .ACR. as 'vell as rcco\.crablc. sotice tllat sllould a transaction such as T2 read a value mitten 11)- TI after TI conrmits. then surely fi either co~nnlits or a1)orts after T1 commits. Thus: Ever>- ;\CR schedule is recotwable. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 9914 CYL4PTER 19. AfORE ABOUT TIZAh-SACTION hIIA17.~~~~f~hr~ 19.1. SERI.4LIZABILITY AJ-D RECO\~ER.~~~L~~- 9% 19.1.5 Managing Rollbacks Using Locking Our prior discussion applies to schedules that are generated by any kind of scheduler. In the common case that the scheduler is lock-based, there is a simple and commonly used way to guarantee that there are no cascading rollbacks: Strict Locking: .% transaction must not release any exclusive Iocks (or other locks, such as increment locks that allo~ir values to he changed) until the transaction has either con~mitted or aborted, and the commit or abort log record has been flushed to disk. A schedule of transactions that follow the strict-locking rule is called a strict schedule. Two important properties of these schedules are: 1. Every strict schedule is ACR. The reason is that a transaction T2 cannot read a value of element X written by TI until Ti releases any exclusive lock (or similar lock that allolvs X to be changed). Under strict locking, the release does not occur until after commit. 2. Every strict schedule is serialzzable. To see why, ohscrve that a strict schedule is equivalent to the serial schedule in which each tra~isaction runs instantaneously at the time it commits. IVith these observations, we can now picture the relationships among the dif- ferent kinds of schedules we have seen so far. The containments are suggested in Fig.19.3. Figure 19.3: Containments an noncontai~lments among classes of schetlules Clearly. in a strict schedule. it is not possihle for a transaction to rcad dirty data. since data written to a huffer by an unconilnitted transaction re~nairls locked until the transaction commits. Ho~vever: we still have tlie prohleni of fising the data in buffers when a transaction aborts, since these cllallges must have their effects cancelled. How difficult it is to fix buffered data depellds on ~vhether database elements are blocks or sornethi~lg smaller. \Ye shall consider each. Rollback for Blocks If the lockable database elements are blocks. then there is a simple rollback method that never requires us to use tile log. Suppose that a transaction T has obtained an esc1usi~-e lock on block A. written a new value for A in a buffer, and then had to abort. Since -4 has been locked since T xvrote its value, 110 other transaction has lead -4. It 1s easy to restore the old value of -4 provided the folloning rule is follo~ved Blocks ~vritten by uilcominittcd transactiolls are pinned in main memory; that is. their buffers are not alloxved to be written to disk. I11 this case. ne roll back.' T when it aborts by telling the buffer manager to ignore the value of A. That is, the buffer occupied by -4 is not written anywhere, and its buffer is added to the pool of available buffers. \Ve call be sure that the value of A on disk is the most recent value written by a committed transaction, which is c~actly the value we want A to have. Tllele 1s also a sinlple rollback method if we are using a multiversion system as in Sections 18.8.5 and 18.8.6. \Ye niust again assume that blocks written by ~incomniitted transactions are pinned 111 memory. Then, we simply renlove the value of A that was mitten by T from the list of available values of A. Sote that because T was a i\iiting transaction, its value of .I ~vas locked from the time the lalue n.as \vritten to the time it aborted (assuming the timestamp/lock scheme of Section 18.8.6 is used). Rollback for Small Database E1ement.s When lockable database elenlcnts are fractions of a block (e.g., tuples or oh- ~ects). then the sinlple appioach to restori~lg buffels that have been ~nod~fied hl- aborted transactions nil1 not uoik The p~ohle~n is that a buffer may contain data changed by t~vo or more transactions: if one of them aboits, Tve still nlust plesesve tlie changes made by the other \le have several choices \vhen we must restore thc old value of a small database element A that n-as written by the tlansaction that has a11ortt.d. 1. We can read the original value of I from the database stored on disk and modify the buffer contents appropriately. 2. If the log is an undo or untlo/redo log. then we can obtain the former value from the log itself. The same code used to recover frorn crashes ma?. be used for \-oll~ntary" rolll~acks as \~-cll. 3. \IF can keep a separare ~nair~-l~lclr~ory log of the changes n~ade by car11 I transaction, preserved for only the tinlc that transactio~l is active. The i old value call be fouxid fro111 this "log." Sone of these approaches is ideal. The first s~~rely il~rolves a disk access. The second (examining the log) might not involve a disk access. if the relevant Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 996 CHAPTER 19. MORE ABOUT TRAATSACTION JlilA-~lGE:lIEXT When is a Transaction Really Committed? The subtlety of group commit reminds us that a completed transaction can be in several different states between when it finishes its xvork and when it is truly "committed." in the sense that under no circumstances, including the occurrence of a system failure, will the effect of that transaction be lost. As we noted in Chapter 17, it is possible for a transaction to finlsh its work and even write its COMMIT record to the log in a main-memory buffer, yet have the effect of that transaction lost if there is a system crash and the COMMIT record has not yet readied disk. Lloreover, we saw in Section 17.5 that even if the COMMIT record is on disk but not yet backed up in the archive, a media failure can cause the transaction to be undone and its effect to be lost. In the absence of failure, all these states are equivalent, in the sense that each transaction will surely advance from being finished to having its effects survive even a media failure. However, when rve need to take failures and recovery into account, it is important to recognize the differences among these states, which otherwis'e could all be referred to informally as 'L~ommitted." portion of the log is still in a buffer Hone1 er. it could also invol~ e extensix e esamination of portions of the log on disk. sea~ching for the update record that tells the correct former value. Tlie last approach does not require disk accesses. but may consume a large fraction of menioi y for the main-memory '.logs." 19.1.6 Group Commit Under some circumsta~ices, n-e can avoid reading dirty data even if re do not flush every commit record on the log to disk immediately. As long as a-e flush log records in the order that they ale written, we can release locks as soon as tlle commit record is written to tlie log in a buffer. Example 19.5: Suppose transaction TI I\-rites X, finishes, writes its COMMIT record on the log, but the log record remains in a buffer. Even though TI has not committed in the sense that its connilit record can survive a crash. we shall release TL's locks. Then T2 reads S and .'colnmits." but its co~nn~it record, n-hicli follows that of TI. also remains in a buffer. Since we are flushing log records ill the order 1s-ritten. T2 cannot be perceived as co~nmittcd b?- a recovery manager (because its commit record reached disk) unless Tl is also perceived as committed. Thus, there arc three cases that the recovery manager could find: 1. Neither TI nor T.L has its commit record on disk. Then both are aborted by the recovery manager, and the fact that T2 read S from an uncommitted 2. TI is comnlitted. but T2 is not. There is no problerri for two reasons: T2 did not read S from an uncomlnitted transaction, and it aborted anyway. with no effect on the database. 3. Both are corrnnitted. Then the read of S by Tz was not dirty. On the other hand, suppose that the buffer containing Tz's commit record got flushed to disk (say because the buffer manager decided to use the buffer for somet11i1:g else). but the buffer containing TI'S commit lecord did not. If there is a crash at that point. it will look to the recovery manager that TI did not commit, but T2 did. The effect of T2 will be perlrianently reflected in tlie database, but this effect was based on the dirty read of X by T2. Our conclusion from Esa~nple 19.5 is that we can release locks earlier than the time that the transaction's commit record is flushed to disk. This policy, often called giazp commit. is: Do iiot release locks until the transaction finishes: and the comniit log record at least appears in a buffer. Flush log blocks in the order that they \\-ere created. Group commit. like the policy of requiring .'recoverable schedules" as discussed in Section 19.1.3, guarantees that there is never a read of dirty data. 19.1.7 Logical Logging We salv in Section 19.1.5 that dirty reads are easier to fis up rvhen the unit of locking is the block or page. Holvever, there are at least two problems prese~lted when database elements are blocks. 1. -411 logging methods I-equirc either the old or new value of a database element, or both: to be recorded in the log. \Vhen the change to a block is small, e.g., a ren-rittcri attribute of one tuple. or an inserted or deleted tuple, then there is a great deal of redundant information written on tile log. 2. Tlie recluireme~it that the schedule be recoverable; releasing its locks only after co~nnlit. car1 illhibit concurrency severely. For esample, recall our discilssion in Section 18.7.1 of the advantage of early lock release as xr access data tllro,lgll a B-tree indes. If we require that locks be helti until connnit. thcn this advalitagc cannot be obtained: and n-e effectively allon- only one writing transaction to access a B-tree at any time. Both these concerns motivate the use of logical logging. villere only the changes to the blocks are described. There are several degrees of coniplesity. depending on the nature of the change. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 1. .A small rlunlber of bytes of the database element are changed, e.g the update of a fixed-length field. This situation call be handled in a straight- forward way, where we record only the changed bytes and their positions. Example 19.6 \rill show this situation and an appropriate form of update record. 2. The change to the database element is simply described; and easily re- stored, but it has the effect of cliangiiig most or all of the bytes in the database element. One coninion situation: discussed in Example 19.7: is when a variable-length field is changed and illuch of its record, and even other records must slide within the block. The new and old values of the block look very different unless we realize and indicate the simple cause of the change. 3. The change affects many bytes of a database clement, and further changes call prevent this change from ever being undone. This situation is true "logical" logging, since we cannot even sec the undo/rcdo process as occur- ' ring on the database elenieilts thetiiselves, hut rather on some higher-level '.logical" structure that tlie database elenletits represent. 1% shall, in Es- ample 19.8, take up the matter of B-trees, a logical structure represe~ited by database clements that are disk blocks, to illustrate this co~rlples form of logical logging. Example 19.6 : Suppose database elements are blocks that each contain a set of tuples from some relation. 11'e call express the update of an attribute by a log record that says somethirig like .'tuple t had its attribute a changed fro~n vahie ~'1 to 02.'' An insertion of a nerv tuple into empty space on the block can be expressed as "a tuple t with value (nl. a2:. . . : ak) was inserted beginning at offset position p." Unless the attribute changed or the tuple inserted are comparable in size to a block, the alnount of space taken by these records will be much smaller than the entire block. lloreot-er, thcy serve for both undo and redo operations. Notice that both these operations are idernpotent; if you perform them scv- era1 tinlcs on a block; the result is the same as perfor~ning them once. Liken-ise. thcir implied inrerses, I\-here the value of t[n] is restored from vz back to 1.1. or the tuple t is removed. are also idenrpoteiit. Thus. records of these types can be used for rccol-cry in exactly tlie same way that update log rccords were used throughout Cliaptcr 17. 0 Exanlple 19.7: Again assunic database clc~nents arc blocks lioldiiig tl~plc. but the tul~les Ilavc sonie rariahle-lengtil ficlds. If a cllt~~~ge to a fi~ld such as Ivas described in Exalilple 19.6 occurs, n.e niay 1la1-e to slide large portio~ls of the block to make room for a longer field. or to preserve space if a ficld beco~~ics smaller. In extreme cases, ~ve could have to crcatc ail overfloxr block (1.c~cal1 Section 12.5) to hold part of the contents of the original block, or wc could remove an ovc.rflo\v block if a shorter field allows us to combine the contenrs of two bl~clis into one. As 101ig as the block and its o\.erflow block(s) are considered part of one database cl~inent, then it is straightforward to use the old and/or new value of tlic changed field to tundo or redo the change. Ho~vever, the block-plus-overflox~~- bloik(s) must l~e thougilt of as holding certain tuples at a "lo@cal" level 1Ve nlay not even be able to restore the bytes of these blocks to their original state after an undo or redo, because there nlay have been reorganization of the blocks due to othcr cliarges that varied the length of other fields. Holvever. if we think of a database ele~nent as being a collection of blocks that together represent certain tupleb. tile11 a redo or undo can indeed restore the logical *state" of the eleme~it. O Hoxvever, it ]nay not be possible, as we suggested in Example 19.7, to treat blocks as expandable through the mechanis~ll of overflow blocks. IVe nmay thus be able to undo or redo actions only at a level higher than blocks. The next esample discusses the important case of B-tree indexes, nhere the management of blocks does not perinit ove~flow blocks, and we must think of undo and redo as occuiring at the logical level of the B-tree itself; rather tllan the blocks. Example 19.8 : Let us consider the problem of logical logging for B-tree nodes. Instead of xvriting the old and/or new value of an entire node (block) on the log. we n-rite a short record that describes the change. These changes include: 1. Insertion or deletion of a key/pointer pair for a child. 2. Change of the key associated \x-it11 a pointer 3. Splittirig or ~rlerging of nodes. Each of these changes call be indicated with a short log record. Even the splittin: operation requires only telling xvhere t,he split occurs; and ivhere tahe iiex lodes are. Likewise: merging requires only a reference to the nodes in- volved; since rhe manner of rnergirlg is determined by the B-tree rnallagenlent algorithms used. csillg logical iljii!at~ rerorris of these tj-pesalloirs us to release locks earlier than xrould othern-ise be required for a recoverable schedule. The reasoil is that dirt- reads of B-tree blocks are never a problem for the transaction that reads tl~ein. provided its only purpose is to use the B-tree to locate the data the transaction needs to access. For instance. suppose that tra~lsactioll T reads a leaf node dY. but the trans- action c- tilat 1a.t wrote -\- lates aborts. and sorne change nlade to S (e.g.; the illscrrioll of a nelr keT/lloillter pair into due to an insertion of a tuple b\. liceds to be undone. If T has also inserted a key/poi~~ter pair into S. then it is liot possiMe to restore '. to the !ray it was before LT inodified it. Hoxevcr. tlie effect of L- on -\- call be undone; in this exa~nple n-e would delete the key/pointer pair that C had iiiscrted. Tlie resulting 5 is riot the same as that irllich ex- isted before U operated: it has the i~lsertion made by T. Hon-ever, there is no database inconsistency. siilcc the B-tree as a ivhole continues to reflect only the Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... the warehouse, which looks t o the user like an ordinary database The arrangeme~lt is suggested by Fig 20.3, although there may be many more than the t ~ v o sources shown Once the data is in the ~varehouse, queries may be issued by the user exactly b as they ~vould e issued t o any database On the other hand, user updates to the n-arehouse generally are forbidden, since they are not reflected in the. .. and later execute A-', then the resulting database state is the same as if neither -4 nor 4-' had executed Nore forlnally: If D is any database state, and B1B ? B,, is any sequence of actions and compensating transactions (whether from the saga in question or any other saga or transaction that may legally execute on the database) then the same database states result from running the sequences Bl Bz... changed by the complete transaction, it has t o be locked exclusively at action dz and not unlocked until either the transaction aborts or action As completes This lock may have to be held for days, while the people charged with authorizing the payment get a chance to look a t the matter If so, then there can be no other charges made t o account X123, even tentatively On the other hand, if there are... application programs the database supports If a saga execution leads t o the Abort node, then we roll back the saga by executing the compensating transactions for each executed action, in the reverse order of those actions By the property of compensating transactions stated above, the effect of the saga is negated, and the database state is the same as if it had never happened An explanation why the effect is... a virtual database, which the user may query as if it were materialzzed (physically constructed, like a warehouse) The mediator stores no data of its own Rather, it translates the user's query into one or more queries to its sources The mediator then synthesizes the answer to the user's query from the responses of those sources, and returns the answer to the user We shall introduce each of these approaches... query another D2 in terms that D2 can understand The problem with this architecture is that if it databases each need to talk to the 7~ - 1 other databases then n-e must write n(n - 1) pieces of code to support queries between systerns The situation is suggested in Fig 20.1 There, we see four databases in a federation Each of the four needs three components, one to access each of the other three databases... paths that lead to the Abort node represent sequences of actions that cause the overall transaction to be rolled back, and these sequences of actions should leave the database unchanged Paths t o the Complete node represent successful sequences of actions, and all the changes to the database system that these actions perform will remain in the database Example 19.24 : T h e paths in the graph of Fig... Restoring Database State After an Abort: If a transaction aborts but has written values t o buffers, then we can restore old values either from the log or from the disk copy of the database If the new values have reached disk, then the log may still be used to restore the old value + Logical Logging: For large database elements such as disk blocks, it saves much space if we record old and new values on the. .. 1 If the last log record for T was , then T must have been committed bv the coordinator Depending on the log nletl~odused, i t may bc necessary to redo the component of T a t the recovering site 2 If the last log record is then sinlilarly we kno~vthat the global decision was to abort T If the log method requires it we undo the component of T a t the recolering site 3 If the last... along with the physical receipts If not, the transaction is aborted Presumably the traveler will be required to modify the request in some way and resubmit the form In action 44 which may take place several days later the corporate administrator either approves or denies the request or passes the form to an assistanr \rho will then make the decision in action is form is denied the transIf the action . restore the data from the disk copy of the database, if the effect of the dirty data has not migrated to disk. These approaches are considered in the next. conipare the methods for their effect on the ability of transac- tions to complete tvithout delay. The performance of the three methotfs depends on whether