Course Content Database Management Systems • Introduction • Database Design Theory • Query Processing and Optimisation Winter 2003 • Concurrency Control • Data Base Recovery and Security CMPUT 391: Database Recovery and Security • Object-Oriented Databases • Inverted Index for IR Dr. Osmar R. Zaïane • XML • Data Warehousing • Data Mining • Parallel and Distributed Databases University of Alberta Chapters 18 and • Other Advanced Database Topics 21 of Textbook Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 Database Management Systems University of Alberta 1 Database Management Systems University of Alberta 2 2 Database Recovery and Objectives of Lecture 5 Security Database recovery and security • Motivation and Assumptions • Review some causes of database failure and • Types of Failures and Recovery Manager introduce the procedures to recover after such • Transaction Logging and Checkpointing failures. • Discuss the purpose of transaction log file and • Recovery Strategies checkpointing during transaction logging. • Introduction to Database Security • Review the kind of threats that can affect a • Discretionary and Mandatory Access Control database and discuss the scope of database • Statistical Database Security security. Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 3 4 Database Management Systems University of Alberta Database Management Systems University of Alberta
Recovery and the ACID properties Motivation A tomicity: All actions in the transaction happen, or none happen. • Atomicity: C onsistency: If each transaction is consistent, and the DB starts consistent, it – Transactions may abort due to concurrency, system crash, or unilaterally (“Rollback”). ends up consistent. I solation: Execution of one transaction is isolated from that of other transactions. • Durability: – What if DBMS stops running? (Causes?) D urability: If a transaction commits, its effects persist . • The Recovery Manager is responsible for ensuring two important • Example: Desired Behavior crash! properties of transactions: Atomicity and Durability . after system restarts: T1 • Atomicity is guaranteed by undoing the actions of the transactions T2 – T1, T2 & T3 should be that did not commit (rollback aborted transaction). T3 durable. • Durability is guaranteed by making sure that all actions of T4 – T4 & T5 should be committed transactions survive crashes and failures. T5 aborted (effects not seen). Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 Database Management Systems University of Alberta 5 Database Management Systems University of Alberta 6 Another Motivating Example Role of DB Main Memory Buffers crash! t f is the time of failure. T1 t c is the time at which T2 • Database pages (blocs) are read from disk and put the cache was certainly T3 into DB buffers inn main memory reflected on disk. ÿ T4 Anything after t c may • Read and Write operations are executed on pages T5 still be in buffer. T6 in the DB buffer. t 0 t f t c • Pages stay in buffers until explicitly written back • Clearly T1 and T6 are not committed at time of crash ÿ undo to disk (if they were updated) T1 and T6 at restart. • Changed pages may remain in the buffer for • T2 and T3 made it to secondary storage before failure. efficiency • What about T4 and T5? They committed, but did they make it – Updates may not be reflected on disk immediately from the volatile database buffer to the non-volatile storage? (saves write access) • Since we do not know, Recovery manager may have to redo – Other transactions can read from the changed buffers T2, T3, T4, and T5. (saves read access) Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 7 8 Database Management Systems University of Alberta Database Management Systems University of Alberta
Database Recovery and Assumptions Security • Concurrency control is in effect. – Strict 2PL, in particular, with some deadlock resolution • Motivation and Assumptions mechanism. • Types of Failures and Recovery Manager • Updates are happening “in place”. – i.e. data is overwritten on (or deleted from) the disk. • Transaction Logging and Checkpointing • Some Buffer Manager � � Recovery Manager • Recovery Strategies interaction strategies. • Introduction to Database Security • Is there a simple scheme to guarantee Atomicity & Durability? • Discretionary and Mandatory Access Control • Remember the transaction log and the Aries Algorithm • Statistical Database Security we introduced in Lecture 4? Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 Database Management Systems University of Alberta 9 Database Management Systems University of Alberta 10 General Failures Types of Failures • System crashes : due to hardware or software errors, • Transaction failures resulting in loss of main memory – Transaction aborts (unilaterally or due to deadlock) • Media failures : due to problems with disk head or – 3% of transaction abort abnormally on average unreadable media, resulting in loss of parts of secondary • System failures storage. – Failure of processor, main memory, power supply… • Application errors : due to logical errors in the program – Main memory contents are lost but not secondary storage which may cause transactions to fail. • Media failures • Natural disasters : physical loss of media (fire, flood, – Failure of secondary storage earthquakes, terrorism, etc.) – Head crash or controller failure • Sabotage : intentional corruption or destruction of data • Carelessness : unintentional destruction of data by user or operator. Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 11 12 Database Management Systems University of Alberta Database Management Systems University of Alberta
Recovery Manager Database Recovery and Transaction Security Secondary commands Main memory storage Recovery Manager • Motivation and Assumptions Fetch Flush Database • Types of Failures and Recovery Manager DB buffer Buffer Manager • Transaction Logging and Checkpointing Read/Write • Recovery Strategies • Volatile storage: main memory (DB buffer) • Introduction to Database Security • Stable storage: disks and other media. Resilient to failure and loses its content only • Discretionary and Mandatory Access Control in the presence of media failure or • Statistical Database Security intentional attacks (Database and logs) Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 Database Management Systems University of Alberta 13 Database Management Systems University of Alberta 14 Action Logging Database Log • The log contains records (or entries) that are appended. • Every update action of a transaction must also write a • For recovery, the log is read backwards log entry to an append-only file. • An entry in the log contains: • No record needs to be appended in the log if the – A transaction identifier action merely reads the database – Type of operation • Why do we need a log? The log is consulted by the – Objects accessed to perform action system to achieve both atomicity and durability. – Old value of object (before image) • The log is generally stored on a different mass storage – New value of object (after image) device than the database. – … • Log entries (also called update records) are used to New Stable Old Update DB state undo changes in case of aborts: using transacion ID Stable Operation DB state Database replace object value in database with before image Log Dr. Osmar R. Zaïane, 2001-2003 Dr. Osmar R. Zaïane, 2001-2003 15 16 Database Management Systems University of Alberta Database Management Systems University of Alberta
Recommend
More recommend
