Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Database systems Implementation Third year, first Semester 2010/2011 Database Backups and Recovery Backup and Recovery Database Backups A backup is a copy of data. This copy can include important parts of the database, such as the control file and data files. A backup is a safeguard against unexpected data loss and application errors. If you lose the original data, then you can reconstruct it by using a backup. Note: • .LOG files are typically generated automatically, while .TXT files are created by the • user. For example, when a software installer is run, it may create a log file that contains a log of files that were installed. Standard text files, on the other hand, are typically created in a word processor by a user. For example, if you create a new file with Notepad, it saves the file with a ".txt" extension. Backups are divided into physical backups and logical backups. Physical backups, which are the primary concern in a backup and recovery strategy, are copies of physical database files. You can make physical backups with either the Recovery Manager (RMAN) utility or operating system utilities. In contrast, logical backups contain logical data (for example, tables and stored procedures) extracted with an Oracle utility and stored in a binary file. You can use logical backups to supplement physical backups. Backups cont.. A backup and recovery strategy is essential to prevent data loss regardless of your database management system; this is one of the most important aspects of database administration. Oracle database, backup categories in physical that copied of the physical database file and logical backup that able to recover at the individual schema object level this performance by export utility, export the object into a binary file which can only read by import utility. Database Recovery To restore a physical backup of a data file or control file is to reconstruct it and make it available to the Oracle database server. To recover a restored data file is to update it by applying archived redo logs and online redo logs, that is, records of changes made to the database after the backup was taken. • Process of restoring database to a correct state in the event of a failure. • Need for Recovery Control Database Recovery cont.. Two types of storage: volatile (main memory) and nonvolatile. • Volatile storage does not survive system crashes. • Stable storage represents information that has been replicated in several nonvolatile storage media with independent failure modes. Types of Failures • System crashes, resulting in loss of main memory. • Media failures, resulting in loss of parts of secondary storage. • Application software errors. • Natural physical disasters. • Carelessness or unintentional destruction of data or facilities. • Sabotage (damage). Transactions and Recovery • Transactions represent basic unit of recovery. • Recovery manager responsible for atomicity and durability. • If failure occurs between commit and database buffers being flushed to secondary storage then, to ensure durability, recovery manager has to redo (roll forward) transaction’s updates. Transactions and Recovery • If transaction had not committed at failure time, recovery manager has to undo (rollback) any effects of that transaction for atomicity. • Partial undo - only one transaction has to be undone. • Global undo - all transactions have to be undone. Example • DBMS starts at time t0, but fails at time tf. • Assume data for transactions T2 and T3 have been written to secondary storage. • T1 and T6 have to be undone. In absence of any other information, recovery manager has to redo T2, T3, T4, and T5. Recovery Facilities DBMS should provide following facilities to assist with recovery: • Backup mechanism, which makes periodic backup copies of database. • Logging facilities, which keep track of current state of transactions and database changes. • Checkpoint facility, which enables updates to database in progress to be made permanent. • Recovery manager, which allows DBMS to restore database to consistent state following a failure. Log File A .log file is a text file that can be found in many locations on your computer. It can be found in your root drive, your Windows folder. It Contains information about all updates to database: • Transaction records. • Checkpoint records. • Often used for other purposes (for example, auditing). Log File Transaction records contain: • Transaction identifier. • Type of log record, (transaction start, insert, update, delete, abort, commit). • Identifier of data item affected by database action (insert, delete, and update operations). • Before-image of data item. • After-image of data item. • Log management information. Sample log file 1. INFO----**** New configuration **** 2. 3. Section name : Test2 4. grfFlags : 63 5. cAttributes : 0 6. aAttributes : NONE 7. pdwFlags : 0 8. 9. INFO----Successfully bound filter. 10. 11. PASS----Init() returned a valid value for pdwFlags. 12. 13. INFO----Successfully initialized filter. 14. 15. INFO----Performing validation test. In this part of the test, the chunks structures 16. returned by the filter are checked for correctness, and the return values 17. of the filter calls are checked. 18. 19. PASS----GetChunk() succeeded. 20. 21. PASS----The current chunk has a legal value for the flags field. Check pointing Checkpoint is a Point of synchronization between database and log file. All buffers are force-written to secondary storage. • Checkpoint record is created containing identifiers of all active transactions. • When failure occurs, redo all transactions that committed since the checkpoint and undo all transactions active at time of crash. Check pointing • In previous example, with checkpoint at time tc, changes made by T2 and T3 have been written to secondary storage. Thus: • only redo T4 and T5, • undo transactions T1 and T6. Recovery Techniques If database has been damaged: • Need to restore last backup copy of database and reapply updates of committed transactions using log file. If database is only inconsistent: • Need to undo changes that caused inconsistency. May also need to redo some transactions to ensure updates reach secondary storage. • Do not need backup, but can restore database using before- and after-images in the log file. Log based recovery The most widely used structure for recording database modifications is the log. The log is a sequence of log records and maintains a history of all update activities in the database. There are several types of log records. • An update log record describes a single database write: • Transactions identifier. • Data-item identifier. • Old value. • New value. Shadow paging Shadow paging is an alternative to logbased recovery techniques, which has both advantages and disadvantages. It may require fewer disk accesses, but it is hard to extend paging to allow multiple concurrent transactions. The paging is very similar to paging schemes used by the operating system for memory management. Cont.. The idea is to maintain two page tables during the life of a transaction: the current page table and the shadow page table. When the transaction starts, both tables are identical. The shadow page is never changed during the life of the transaction. The current page is updated with each write operation. Each table entry points to a page on the disk. Cont.. When the transaction is committed, the shadow page entry becomes a copy of the current page table entry and the disk block with the old data is released. If the shadow is stored in nonvolatile memory and a system crash occurs, then the shadow page table is copied to the current page table. This guarantees that the shadow page table will point to the database pages corresponding to the state of the database prior to any transaction that was active at the time of the crash, making aborts automatic. Shadow paging cont.. There are drawbacks to the shadow-page technique: • Commit overhead. The commit of a single transaction using shadow paging requires multiple blocks to be output -- the current page table, the actual data and the disk address of the current page table. Log-based schemes need to output only the log records. • Data fragmentation. Shadow paging causes database pages to change locations (therefore, no longer contiguous. Garbage collection. Each time that a transaction commits, the database pages containing the old version of data changed by the transactions must become inaccessible. Such pages are considered to be garbage since they are not part of the free space and do not contain any usable information. Periodically it is necessary to find all of the garbage pages and add them to the list of free pages. This process is called garbage collection and imposes additional overhead and complexity on the system. The end Questions and Answers..!