(资料库系统).pptVIP

Database Systems(資料庫系統) January 2, 2006 Last Day of Class ? Announcements Final exam covers chapters [10,11,12,13,14,16,17.1~17.4, 18] The exam will be on 1/9/2006 9:10~12:00 Place: CSIE 103/105 Closed book No calculator Assignment #6 is due on 1/4 next Wed. Practicum #4 is due on 1/11. Crash Recovery Chapter 18 Overview Many types of failures: Transaction failure: bad input, data not found, etc. System crash: bugs in OS, DBMS, loss of power, etc. Disk failure: disk head crash Recovery manager is called after a system crash to restore DBMS to a consistent state before the crash. Recovery manager ensures two transaction properties: Atomicity: undo all actions of uncommitted transactions. Durability: actions of committed transactions survives failures. (redo their update actions if they have not been written to disks). ARIES: log-based recovery algorithm. ARIES Overview Assume HW support: Log actions on an independent “crash-safe” storage What are SW problems? Results of uncommitted transactions may be written to disks → undo them Results of committed transactions may not be written to the disk → redo them Questions: What are the states of transactions at the time of crash? What are the states of page (dirty?) at the time of the crash? Where to start undo redo? ARIES General Approach Before crash: Log changes to DB (WAL) Checkpoints After crash: Analysis phase Figure out states of [committed vs. uncommitted] transactions pages [dirty or clean] After crash [continue]: Redo phase Repeat actions from uncommitted committed transactions [till the time of the crash] Undo phase Undo actions of uncommitted transactions Do we really need “redo” “undo”? Three Phases of ARIES Steal Policy ARIES is designed to work with a steal, no-force approach. Steal property: Can the changes made to an object O in the buffer pool by T1 be written to disk before T1 commits? If yes, we have a steal (T2 steals a frame from T1). Say T2 wants to bring a new page (Q), and buffer pool repl