databases might get lost we don’t like that, because … solutions are based on logging...
TRANSCRIPT
Databases might get lost We don’t like that, because … Solutions are based on logging techniques General term: write ahead logging
Wrong user data: avoid by using constraints System failure: loss of main memory (= volatile
memory) Media failures (disk errors) Catastrophe (several levels possible)
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)
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
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 := v2 + 200;WRITE(Account2, v2); OUTPUT(Account2);
INPUT(Account1); READ(Account1, v1); v1 := v1 – 200;WRITE(Account1, v1); OUTPUT(Account1);
>> CRASH <<
INPUT(Account2); READ(Account2, v2); v2 := v2 + 200;WRITE(Account2, v2); OUTPUT(Account2);
Old values of each data element X should be written to the log file: <T, X, oldvalue>
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 <T, commit> record is written to the log after all
database elements have been updated on disk
Example transaction run + log entriesDistinguish values in M(emory) and on D(isk)
Note: Log means M-Log; after FLUSH LOG: D-Log = M-Log
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
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 accepted2. Wait until all active transactions are finished
(COMMIT or ABORT)3. Flush the log records4. Write a <CKPT> record into the log5. Resume transaction processing
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);
Why would you delay OUTPUT?
Why would you delay OUTPUT?
Before commitment, the new value of X should be written to the log file: <T, X, newvalue>
Such a record is often called the after image of X After the logging of all after images,
the <T, commit> is written to the log
Example transaction run + log entriesDistinguish values in M(emory) and on D(isk)
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?
Combining before image and after image:<T, X, oldvalue, newvalue>
Optimal freedom for buffer manager
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]
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 your locks until ABORT/COMMIT
Relates to SQL Isolation Levels
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
Checkpoint for REDO Non-quiescent checkpoint
>> see the exercises