Presentation is loading. Please wait.

Presentation is loading. Please wait.

 Databases might get lost  We don’t like that, because …  Solutions are based on logging techniques  General term: write ahead logging.

Similar presentations


Presentation on theme: " Databases might get lost  We don’t like that, because …  Solutions are based on logging techniques  General term: write ahead logging."— Presentation transcript:

1

2

3  Databases might get lost  We don’t like that, because …  Solutions are based on logging techniques  General term: write ahead logging

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

5

6  Traffic between disk and main memory: IO  Unit size: page or block  Block in memory is buffered  Typically 32 kbyte  Access time: 5 – 10 msec  Block is often unit for concurrency (sometimes tuple)

7  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

8  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);

9 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);

10  Old values of each data element X should be written to the log file:  Such a record is often called the before image of X  Before doing an OUTPUT(X), the log record for this X should be flushed  The record is written to the log after all database elements have been updated on disk

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

12  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

13 Checkpointing  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.Wait until all active transactions are finished (COMMIT or ABORT) 3.Flush the log records 4.Write a record into the log 5.Resume transaction processing

14 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);

15  Why would you delay OUTPUT?

16

17  Before commitment, the new value of X should be written to the log file:  Such a record is often called the after image of X  After the logging of all after images, the is written to the log

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

19  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?

20  Combining before image and after image:  Optimal freedom for buffer manager

21  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  A schedule is recoverable if for each pair of transactions the following property holds: Tj RF Ti => COMMIT i < COMMIT j (in log)  A schedule avoids cascading rollbacks if: Tj RF Ti => COMMIT i < Rj[X]

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

23  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

24  Checkpoint for REDO  Non-quiescent checkpoint >> see the exercises


Download ppt " Databases might get lost  We don’t like that, because …  Solutions are based on logging techniques  General term: write ahead logging."

Similar presentations


Ads by Google