Data might get lost We don t like that, because Solutions are based on logging techniques General term: write ahead logging

Transcription

1

2

3

4 Data might get lost We don t like that, because Solutions are based on logging techniques General term: write ahead logging

5 Wrong user data: avoid by using constraints System failure: loss of main memory (= volatile memory) Media failures (disk errors) Catastrophe (several levels possible)

6

7 Traffic between disk and main memory: IO Unit size: page or block Block in memory is buffered Typically 8-32 kbyte Access time: 5 10 msec Block is sometimes unit for concurrency

8 Log file is a separate file, containing information to support database reconstruction Entries have record structure Entries are (in most cases) related to a specific transaction Good practice: log file on separate disk Recent development: log files on SSD

9 INPUT(X): copy block X from disk to memory READ(X,t): assign value of X to variable t WRITE(X,t): copy value of t into X in memory OUTPUT(X): copy block X from memory to disk (also called flushing X) Example (financial transaction): INPUT(Account1); READ(Account1, v1); v1 := v1 200; WRITE(Account1, v1); OUTPUT(Account1); INPUT(Account2); READ(Account2, v2); v2 := v ; WRITE(Account2, v2); OUTPUT(Account2);

10 INPUT(Account1); READ(Account1, v1); v1 := v1 200; WRITE(Account1, v1); OUTPUT(Account1); >> CRASH << INPUT(Account2); READ(Account2, v2); v2 := v ; WRITE(Account2, v2); OUTPUT(Account2);

11 Basic solution 1. Rollback transaction (undo partial changes) 2. If necessary/possible: Restart transaction

12 Old values of each data element X should be written to the log file: <T, X, oldvalue> This value is often called the before image of X Before doing an OUTPUT(X), the log record for this X should be flushed The <T, commit> record is written to the log after all database elements have been updated on disk

13 Example transaction run + log entries Distinguish values in M(emory) and on D(isk) Note: FLUSH LOG means FLUSH M-Log; after FLUSH LOG: D-Log = M-Log

14 Check the log file for uncommitted transactions Rollback these transactions using the before images The order of undoing transactions is essential What about a crash during the recovery process? By the way: restart the transactions that are undone

15 Dealing with all the transactions since the DB started operating (possibly a few years ago) may be less desirable Checkpoint steps: 1. No new transactions accepted 2. Be sure that all active transactions are finished (COMMIT or ABORT) and the log records have been flushed 3. Write a <CKPT> record into the log and flush the log 4. Resume transaction processing

16 INPUT(Account1); READ(Account1, v); v := v 200; WRITE(Account1, v); INPUT(Account2); READ(Account2, v); v := v + 200; WRITE(Account2, v); COMMIT; >> CRASH << OUTPUT(Account1); OUTPUT(Account2);

17 Why would you delay OUTPUT?

18 Why would you delay OUTPUT?

19 Before commitment, the new value of X should be written to the log file: <T, X, newvalue> This record is often called the after image of X After the logging of all after images, the <T, commit> is written to the log

20 Example transaction run + log entries Distinguish values in M(emory) and on D(isk)

21 Check the log file for committed transactions Restore the effects of these transactions using the after images The order of redoing transactions is essential What about a crash during the recovery process?

22 Combining before image and after image: <T, X, oldvalue, newvalue> Optimal freedom for buffer manager: The UNDO logging gives the buffer manager the freedom to write data to disk before the COMMIT The REDO logging gives the buffer manager the freedom to write data to disk after the COMMIT

23 Definition: Tj RF (reads from) Ti if there is an X such that Wi[X] is the last write on X before Rj[X] Definition: IF Tj RF Ti and Ti is not yet committed, then this read is called a dirty read; uncommitted data are often called dirty data A schedule is recoverable if for each pair of transactions the following property holds: Tj RF Ti => COMMIT i < COMMIT j (on log) Recoverability ensures a minimal level of safety, but might lead to cascading aborts

24 A schedule is strict if: Wi[X] < Oj[X] => COMMITi < Oj[X] or ABORTi < Oj[X] for any read or write operation Oj[X] Implementation of strictness by 2PL: hold all your locks until ABORT/COMMIT Relates to SQL Isolation Levels

25 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; Corresponds to STRICT SR SQL default SET TRANSACTION ISOLATION LEVEL READ COMMITTED; Corresponds to RC SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; Allows dirty reads

26 Up till now: system failures Memory lost; data on disk undamaged What to do in case of disk failure? Archiving: always keep a copy of your entire DB Full dump or incremental dump Keep logs since last dump Archive copy + log = actual DB that s why you should keep your log file on a separate disk

27 Checkpoint for REDO Non-quiescent checkpoint >> see the exercises