1. Data recovery 1

2. 2 Recovery - introduction recovery restoring a system, after an error or failure, to a state that was previously known as correct have you dealt with recovery (in a form or another …)? principle: redundancy for databases: redundancy at the physical, not logical, level recovery must be performed by the DBMS; it should be transparent to the user

3. Data recovery 3 Failures local failure (soft crash) properly dealt with by transaction recovery global /system failure (soft crash) all transactions currently in progress are affected two-phase commit algorithm media failure (hard crash) different procedures for recovery (backups / dumps)

4. Data recovery 4 Recovery in database systems database recovery from within applications (e.g. errors generated by the backend) ROLLBACK recovery from backend failures RESTART PROCEDURE

5. Data recovery 5 Recall transaction logical unit of work sequence of database operations transforms a consistent state of a db into another consistent state between operations the db can be inconsistent

6. Data recovery 6 ACID properties of transactions Atomicity all or nothing Consistency preserve database consistency Isolation transactions are isolated from one another locking (levels of isolation) Durability committed transaction updates are performed

7. Data recovery 7 Database recovery from within applications (example in pseudocode) // operations before database transaction r = db_execute(BEGIN TRANSACTION); r = db_execute(INSERT INTO customers VALS (v1, v2, v3)); IF (error(r)) THEN db_execute(ROLLBACK TRANSACTION); r = db_execute(INSERT INTO sales VALS (v1, v2, v5)); IF (error(r)) THEN db_execute(ROLLBACK TRANSACTION); r = db_execute(UPDATE stock SET a = a + v6 WHERE...)); IF (error(r)) THEN db_execute(ROLLBACK TRANSACTION); r = db_execute(COMMIT TRANSACTION); // operations after database transaction

8. Data recovery 8 How can a transaction be undone? system log or journal FIRST:write description of operation in log SECOND: perform operation individual statements must be atomic; the system must guarantee that a set level operation is performed on all the corresponding tuples

9. Data recovery 9 Content of Log descriptions of all operations and their result information about each statement INSERT <> UPDATE DELETE <>

10. Data recovery 10 Structure of Log: stack <> <> <>...

11. Data recovery 11 ROLLBACK mechanism unload the stack OPERATION undo each individual operation the existence of old and new values stored in the log provide for an easy algorithm; inverse of INSERT is DELETE inverse of UPDATE IS UPDATE inverse of DELETE is INSERT

12. Data recovery 12 What does COMMIT mean? all the operations of a transaction are guaranteed to be made permanent; what does permanent mean? are operations on a database not permanent, anyway? buffers

13. Data recovery 13 Buffers it would be very expensive for the DBMS to always work directly with the disk therefore, buffers are employed

14. Data recovery 14 Buffers DBMS buffers internal memory disk

15. Data recovery 15 Synchronisation buffers-disk when are the buffers written on disk? at regular intervals of time: CHECKPOINTS what information is written? all the operations performed on buffers, before the previous checkpoint (disregarding whether the transactions they compose have been completed or not)

16. Data recovery 16 The Log and the Buffers is the log stored in buffers or is it always on the disk? why? recovery from system crash

17. Data recovery 17 System crash BEGIN TRANSACTION time COMMIT idle incidentally, this transaction was not completed before the crash

18. Data recovery 18 Redo/Undo If a system crash occurs, how does the system know, after it has been restarted, which transactions to redo and which to undo?

19. Data recovery 19 Types of transactions with regards to system failure time T1 T3 T2 T5 T4 checkpoint system failure

20. Data recovery 20 T1 – no action time T1 checkpoint system failure transaction completed here (in buffers) all the operations of T1 are performed on the disk here

21. Data recovery 21 T2 - redo time T2 checkpoint system failure transaction completed here (in buffers) all these operations of T1 are performed on the disk here these operations of T1 are performed in buffers and recorded in the log but arent physically performed on disk

22. Data recovery 22 T3, T4, T5 homework (or have a look on next page)

23. Data recovery 23 Redo/Undo transactions of type T1 - have already been force-written T2 and T4 - must be redone (their completion was recorded in the log but they have not been force- written) T3 and T5 - must be undone restart procedure

24. Data recovery 24 Restart procedure - homework simplifying assumption: there is one log per transaction no simplifying assumption; there is one log for the DBMS

25. Data recovery 25 Advanced topic: Physically distributed partitions

26. Data recovery 26 The co-ordinator data can be physically distributed each physical partition can be regarded as an individual database resource manager (something like a local DBMS) the DBMS (for the overall database) has a module co-ordinator that manages the transactions

27. Data recovery 27 Two-phase commit algorithm suppose that each local transaction was completed successfully, then: co-ordinator sends: get ready message each resource manager: force write in log the complete descriptions of their operations; then they answer OK or not OK all answers OK: co-ordinator decides to commit, force writes it in its own log, and sends COMMIT to all resource managers at least one answer not OK: co-ordinator writes ROLLBACK in own log and sends message to all resource manages

28. Data recovery 28 Conclusions data recovery is done based on TRANSACTIONS