Transações em 4 slides (sim, de novo)

Transcrição

1 Bancos de Dados Avançados Recuperação: conceitos e protocolos básicos DCC030 - TCC: Bancos de Dados Avançados (Ciência Computação) DCC049 - TSI: Bancos de Dados Avançados (Sistemas Informação) DCC842 - Bancos de Dados (Pós-Graduação) Transações em 4 slides (sim, de novo) MIRELLA M. MORO mirella@dcc.ufmg.br Controle de Transações FIGURE 17.3 Some problems that occur when concurrent execution is uncontrolled. (a) The lost update problem X = Y = 90; N = 5 e M = 3 Após e em sequência, temos X = X N 85 Y = Y + N 95 X = X + M 88 AGORA, intercaladas: (1) X = X N 85 (1) Y = Y + N 95 (2) X = X + M Introduction to Transaction Processing O que é transação; por que precisa de controle de concorrência e recuperação de transações 2. Transaction and System Concepts Transaction states: active, partially committed, commited, failed, terminated; system log; commit point 3. Desirable Properties of Transactions Atomicidade, consistência, isolamento, durabilidade 4. Schedules based on Recoverability [próximo slide] 5. Schedules based on Serializability [próximo slide] 6. Transaction Support in SQL Atomic, no explicit begin, explicit end 3 4. Schedules based on Recoverability Recoverable: committed T sem rollbacks w1(x) r2(x)... c2 depois de c1 (t1 escreve em X) Cascadeless: T lê X escrito por committed T w1(x) c1 r2(x) r2(x) depois de c1 (t1 escreve em X) Strict: T não lê/escreve até q. última T :w (X) commit 5. Schedules based on Serializability Serial: S1 e S2 sem intercalação S serial é CORRETA (BD S BD correto) Serializable: S1 equivalente a alguma S2 serial Resultequiv.: S1 e S2 produzem mesmo estado no BD Conflictequiv.: S1 e S2 ordem = de operações em conflito Conflict serializable: S1 é conflict equiv a S2 serial FIGURE 17.7 Constructing the precedence graphs for schedules A and Dfrom Figure 17.5 to test for conflict serializability. (c) Precedence graph for schedule C(not serializable). (d) Precedence graph for schedule D(serializable, equivalent to schedule A). X=X-N read(y) Y=Y+N write(y) X=X+M X=X-N read(y) Y=Y+N write(y) X=X+M 6

2 Recuperação 1 CONCEITOS Purpose of database recovery Types of failure Transaction log Data updates, data caching Transaction Roll-back (Undo) and Roll-Forward WAL, steal/force, checkpointing 2 Recovery schemes: a. Deferred updates b. Immediate updates c. Shadow paging d. ARIES 3 Recovery in Multidatabase System Motivation Atomicity: Transactions may abort ( Rollback ). Durability: What if DBMS stops running? (Causes?) Desired Behavior after system restarts:, & T3 should be durable. T4 & T5 should be aborted (effects not seen). T3 T4 T5 crash! Purpose of Database Recovery Types of Failure To bring the database into the last consistent state(existed prior to the failure) To preserve transaction properties ACID Example: System crashes before a fund transfer transaction completes either one or both accounts may have incorrect value!!!! DB must be restoredto the state before the transaction modified any of the accounts. The database may become unavailable for use due to Transaction failure: Transactions may fail because of incorrect input, deadlock, incorrect synchronization. System failure: System may fail because of addressing error, application error, operating system fault, RAM failure, etc. Media failure: Disk head crash, power disruption, etc (Estratégias Típicas de Recuperação) Defeito físico, catástrofe Restaurar uma cópia anterior do BD Acessa sistema de backup e reconstroi estado velho Refaz as transações que foram terminadas com sucesso Acessa o log das transações e redo Inconsistência, não permanente Reverter qualquer mudança causada pela inconsistência Desfaz algumas operações (undo) Refaz outras operações (redo) Acessa o log das transações tanto para undo quanto redo 11 Transaction Log For recovery from any type of failure data values prior to modification (BFIM BeFore Image) and the new value after modification (AFIM AFter Image) are required. These values and other information is stored in a sequential file called Transaction log. A sample log: T ID Back P Next P Operation Data item BFIM AFIM 0 1 Begin 1 4 Write X X = 100 X = Begin 2 5 W Y Y = 50 Y = R M M = 200 M = 200 T3 0 9 R N N = 400 N = nil End Back P and Next P point to the previous and next log records of the same transaction. 12

3 Data Update 2 techniques for helping recovery (noncatastrophic failure) Immediate Update: As soon as a data item is modified in cache, the disk copy is updated If T fails after IU before C: roll back T undo T [+ redo] Deferred Update: All modified data items in the cache is written after a transaction ends its execution (or after a fixed number of transactions have completed their execution) During commit: updates log; updates DB If T fails before C: no undo (it did not change the DB yet, only the buffers) (BD vs. SO) Processo de recuperação interligado às funções do SO: bufferinge caching de páginas do disco na memória principal Página a ser atualizada cache (buffer mem) memória disco Caching de páginas do disco é uma função do SO (tradicionalmente), MAS por causa da sua importância para a eficiência do processo de recuperação, ela é gerenciada pelo SGBDatravés de chamadas de rotinas de baixo nível do SO Data Caching Data items to be modified are first stored into database cache by the Cache Manager (CM) Dirty bit: indicates cache page updates After modification they are flushed (written) to the disk (dirty bit = 1) The flushing is controlled by: Pin-Unpin bit: Instructs the operating system not to flush the data item Modified bit: Indicates the AFIM of the data item Data Update + Caching 2 options for updating from cache: In-place update: The disk version of the data item is overwritten by the cache version When flushing: flush to original place Shadow update: The modified version of a data item does not overwrite its disk copy but is written at a separate disk location. When flushing: creates new copy of (updated) data item Undo and Redo Undo = Transaction Roll-back Redo = Roll-Forward To maintain atomicity, a transaction s operations are redone or undone. Undo: Restore all BFIMs on to disk (Remove all AFIMs). Redo: Restore all AFIMs on to disk. Database recovery is achieved either by performing only undosor only redosor by a combination of the two. These operations are recorded in the log as they happen. Undo = Transaction Roll-Back We show the process of roll-back with the help of the following three transactions, and and T3. T3 read_item (A) read_item (B) read_item (C) read_item (D) write_item (B) write_item (B) write_item (D) read_item (D) read_item (A) write_item (A) write_item (A) NOTA: roll-back em cascata!!!! Operação de alto custo!!! protocolo de recuperação assegura recoverable schedules mas não necessariamente cascadeless ou strict schedules 17 18

4 Undo = Transaction Roll-Back Roll-back: One execution of, and T3 as recorded in the log. A B C D [start_transaction, T3] [read_item, T3, C] * [write_item, T3, B, 15, 12] 12 [start_transaction,] [read_item,, B] ** [write_item,, B, 12, 18] 18 [start_transaction,] [read_item,, A] [read_item,, D] [write_item,, D, 20, 25] 25 [read_item,, D] ** [write_item,, D, 25, 26] 26 [read_item, T3, A] system crash * T3 is rolled back because it did not reach its commit point. ** is rolled back because it reads the value of item B written by T3. T3 READ(C) Undo = Transaction Roll-Back Roll-back: One execution of, and T3 as recorded in the log. WRITE(B) READ(A) BEGIN READ(B) WRITE(B) READ(D) WRITE(D) BEGIN READ(A) READ(D) WRITE(D) BEGIN Illustrating cascading roll-back Time system crash NOTA: Somente operações de escrita são desfeitas; Operações de leitura são necessárias pra determinar efeito cascata (o que em prática não acontece) Write-Ahead Logging (WAL) Write-Ahead Logging (WAL) In-place update (immediate or deferred) requires LOG log must be available to recovery manager. Write-Ahead Logging (WAL) protocol: For Undo: Beforea data item s AFIM is flushed to the database disk (overwriting the BFIM) its BFIM must be written to the log and the log must be saved on a stable store (log disk). For Redo: Before a transaction executes its commit operation, all its AFIMs must be written to the log and the log must be saved on a stable store. The Write-Ahead Logging Protocol: 1Must forcethe log record for an update before the corresponding data page gets to disk. 2Must write all log records for a Xactbefore commit #1 guarantees Atomicity #2 guarantees Durability Exactly how is logging (and recovery!) done? We ll study the ARIES algorithms Steal/No-Steal and Force/No-Force Flushing DB cache to DB disk: Steal: Cache can be flushed before transaction commits Avoids very large buffer space to store all updated pages in memory Used when cache manager needs free space for another transaction No-Steal: Cache cannot be flushed before transaction commit Force: Cache is immediately flushed (forced) to disk at commit No-Force: Cache is deferred after transaction commits An updated page of a committed T may still be in the buffer when another T needs to updated it eliminate I/O to read that page again from disk save a lot when one page is updated heavily by N Ts These give rise to four different ways for handling recovery: Steal/No-Force (Undo/Redo) typical Steal/Force (Undo/No-redo) No-Steal/No-Force (Redo/No-undo) No-Steal/Force (No-undo/No-redo). Handling the Buffer Pool Forceevery write to disk? Poor response time. But provides durability. Stealbuffer-pool frames from uncommited Xacts? If not, poor throughput. If so, how can we ensure atomicity? Force No Force No Steal Trivial Steal Desired 23 24

5 More on Steal and Force STEAL (why enforcing Atomicity is hard) To steal frame F: Current page in F (say P) is written to disk; some Xact holds lock on P. What if the Xact with the lock on P aborts? Must remember the old value of P at steal time (to support UNDOing the write to page P). NO FORCE (why enforcing Durability is hard) What if system crashes before a modified page is written to disk? Write as little as possible, in a convenient place, at commit time,to support REDOing modifications. 25 Checkpointing Time to time (randomly or under some criteria) the database flushes its buffer to database disk to minimize the task of recovery The following steps defines a checkpoint operation Suspend execution of transactions temporarily. Force write modified buffer data to disk. Write a [checkpoint] record to the log, save the log to disk. Resume normal transaction execution. During recovery redo or undo is required to transactions appearing after [checkpoint] record. [commit, T] + [checkpoint] in the log T does not need REDO write operations in case of failure(all updates recorded on disk during checkpoint) 26 Recovery Scheme: Deferred Update NO UNDO//REDO Algorithm The data update goes as follows: A set of transactions records their updates in the log (and cache buffers) At commit point under WAL scheme these updates are saved on database disk After reboot from a failure the log is used to redo all the transactions affected by this failure. No undo is required because no AFIM is flushed to the disk before a transaction commits. RDU_S Recovery using Deferred Update in a Single-User environment Usa duas listas de transações a. Committed desde o último checkpoint b. Ativas (pelo menos uma transação) 1. Aplica REDO nas operações WRITE da lista a com base no loge na mesma ordem em que foram escritas no log 2. Reinicializa as transações da lista b REDO(WriteOp) 1. Examina a entrada no log: [write_item, T, X, new_value] 2. Troca o valor X no banco de dados para new_value(a qual é a AFIM) Deferred Update in a single-user system (a) read_item (A) read_item (B) read_item (D) write_item (B) write_item (D) read_item (D) write_item (D) (b) [start_transaction, ] [write_item,, D, 20] [commit ] [start_transaction, ] [write_item,, B, 10] [write_item,, D, 25] system crash NOW WHAT?! The [write_item, ] operations of are redone. log entries are ignored by the recovery manager. 29 Deferred Update with concurrent users This environment requires some concurrency control mechanism to guarantee isolation property of transactions. Transactions recorded in the log after the last checkpoint are redone. T3 T4 checkpoint t1 T5 Time system crash Recovery in a concurrent users environment. t2 30

6 Deferred Update with concurrent users T3 T4 read_item (A) read_item (B) read_item (A) read_item (B) read_item (D) write_item (B) write_item (A) write_item (B) write_item (D) read_item (D) read_item (C) read_item (A) write_item (D) write_item (C) write_item (A) [start_transaction, ] [write_item,, D, 20] [commit, ] [checkpoint] [start_transaction, T4] [write_item, T4, B, 15] [write_item, T4, A, 20] [commit, T4] [start_transaction ] [write_item,, B, 12] [start_transaction, T3] [write_item, T3, A, 30] [write_item,, D, 25] system crash NOW WHAT? Deferred Update with concurrent users Two tables are required for implementing this protocol: Active table: All active transactions are entered in this table. Commit table: Transactions to be committed are entered in this table. During recovery All transactions of the commit table are redone All transactions of activetables are ignoredsince none of their AFIMs reached the database. They must then be restarted. It is possible that a commit table transaction may be redone twice but this does not create any inconsistency because of a redone is idempotent, that is, one redone for an AFIM is equivalent to multiple redone for the same AFIM. and T3 are ignored because they did not reach their commit points. T4 is redone because its commit point is after the last checkpoint Processo pode ser otimizado Vantagens NO-UNDO//REDO NO-UNDO//REDO Commit table:,... 0; Active table: 1..0 X foi atualizado por várias transações Pode copiar a AFIM apenas da última transação de a 0 que atualizou X Começa o processo pelo FINAL do log Strict 2PL: limita a concorrência (locks até o commit point) Operações das transações não precisam REDO T não armazena mudanças do BD no disco até depois do commitpoint T nunca é rollback devido a falhas durante a sua execução T nunca lê o valor de um item escrito por transações sem commit itens permanecem bloqueados até commit point no cascading roll-back(porém, concorrência limitada!) Recovery Scheme: Immediate Update UNDO/NO-REDO Algorithm AFIMs of T are flushed to disk under WAL before it commits recovery manager undoesall transactions during recovery No transaction is redone It is possible that a transaction might have completed execution and ready to commit but this transaction is also undone. Immediate Update: single user UNDO/REDO Algorithm No concurrency control is required but a log is maintained under WAL. Note that at any time there will be one transaction in the system and it will be either in the commit table or in the active table. The recovery manager performs: Undo: T active table. Redo: T commit table

7 Immediate Update: concurrent users The Big Picture: What s Stored Where UNDO/REDO Algorithm Concurrency control is required and log is maintained under WAL. Commit table records transactions to be committed and active table records active transactions. Minimize recovery manager work: checkpointing The recovery manager performs: Undo: T active table. Redo: T commit table Sugestões de Exercícios ELMASRI 19.21, 19.22, 19.23, RAMAKRISHNAN