Backup and Recovery ' e Lee ; x Bes and recovery refers to the various | eee n Introduction strategies and procedures involved in protect- epee Backups ing the database against data loss and recon- «= Need for Backup Planning structing the data ifthe loss occurs. A recovery "Hardware Protection and Redundancy scheme is an integral part of a database system that is responsible for restoring the database to consistent state—state in which the database was, prior to the occurrence of failure. This chapter highlights the significance of backup and explores various recovery i Concepts and Terminology Faclities | techniques for ensuring database consistency. Recovery Techniques | Detached Transaction Actions FAILURES Recovery in Multi-Database Systems A computer system, like any other electrical Database Recove jilures fery from Catastrophic Fallare> | device is falure-prone. A failure canbe defined [bly ofthe system to provide required functionality correctly. Failure can result due to variety of tans such as disk crash, power failure, software error or even sabotage. Information may be lost in ehofthese cases. Therefore, measures should be taken in advance to ensure that the database is safe ‘ie of such failures. ‘ gab erate achon ‘hes of Failures c ‘pes of failures may occur in a system and each must be dealt with in a different manner. The that ae most difficult to tackle are those that put the information in the Ofthe most common types of failures are: a a i fail are: " failure Two types of errors that may cause @ transaction to fé due to some internal conditio ors The transaction may discontinue , 5 1 found, overflow or resource limit exceeded: yn, such as bad © scanned with OKEN ScannerRendled fa ome net hey M Yn up fo “uN ’ dy 4 m4 jorgmibely | utthen “tenon eee Mo ew ane Wanuiaen NO be ii ee aol iurucrion o Database Management stems ryan a action may be disrupted a e normal execution of a trans ue to * System Errors The normal execution Fr) the sy entering into an undesirable » brought to @ halt due to hardwa x may be brought (0 4 Ate malfunt System crash ‘Transaction processing fi Disk failure A head crash or failure dur ring a data transfer operation may result in tags o¢ or disks from a disk block, Copies of the data on other disk or backups on media such as tape, 9 ey ed g recover from the failure, | / Causes of Failures hey might Oneal Vv el yme others mi; e trivial. Some failures might render the database inoperative. Somme © ae Ee fa Similar, od recovery side, some recovery procedures require DBA interyention- S Some of the internal, mechanisms are transparent to the DBA. For example, in some database management syst process dies abnormally while modifying a block, the DBMS will perform a block-level recovery is automatic. On the other hand, i a datafile has been lst recovery requires additonal py gat common causes of failures-inglude:—~ m Crashes Can result in loss of memory due to hardware or software errors, wuen a user unintentionally deletes a User error A user error occurs, for example, y deletes a ow or dp, table. Carelessness It is damage done to data or facilities by operators or users due to their lack concentration on the task at hand. Sabotage It is the intentional damage done to data, hardware or software facilities. Statement failure tis the inability of the database to execute an SQL statement. For example, ifyo, try to select from a non-existent table or try to insert and there is lack of space. The application softwar or the operating system generates error codes in case of such failures. Recovery from such failures automatic. Application software errors include logical errors in the program that is accessing the databae, which causes one or ions t Network failure can occur while using a client-server configuration or a distributed database sea where multiple database servers are connected by communication network. Network failures such 8 Communication software ftilures or aborted asynchronous connections will interrupt the normal oper of the database system, 4“ 4 Media failure are the most dangerous failures. Not only is there a isk of loosing data if pope aa procedures are not followed, but it usually takes m th other kinds of failures crucial factor in determining the kind of media rae ‘dure ant : i f al example of ames failure is a disk controller failure or disk ead c nae is disk : reagan Gisks 10 Be Te PR lito disk head crash which causes all databases residing 0” fares" OS B°®1) DBA netds to plan appropriate backup procedures to “A Procedure to use to bring the database u © scanned with OKEN Scannerand SOWA de to natural disasters like Arion 4 tabase consistence: 'YPes of failures by either Yand transaction atomicity logical backups. Physical backups, which are the Copies of physical database files, Yc Se otey mmerh of the DBMS or stem Ps contain logical data, (for example, 13 ’ PS depend very much on the system. On | environment is a difficult task. So: to provide information to the end-user. In a fraction of a second, the SQL comm: g system, where it is broken into packages by the network layer and transmitted over he server. At the server, the packages are recompiled and sent from the host network layer ig system, Which finally arrive at the server program. This is just the transmission process. server receives the request, many other processes are executed before data is sent client machine. Various types of failures may occur in such a complex system. fing to IEEE, failures sified according to outage types and can be grouped into the large systems, managing a large database in ftware and hardware components must be For example, consider a simple SQL query and is parsed, passed from the application Physical ign (Software bug) outages i ia fai failure. Design are usually caused by hardware failures—media failure or a CPU = are caused by Software failures. Any software bug, whether in the operating system, database % OF application software results in the design outage. Operation outages on the other hand, are [Eby poor human intervention. Some examples of operation outages are failures atributed due “0 Pr DBA . user errors, inappropriate system setup or inadequate backup Epes enPealotage results from external causes like earthquakes, power surges and abnormal L © Scanned with OKEN Scanneray Bs Introduction 0 Database Management Systems «. Though he/she may not be able t n outage’ ¢ should be prepared deal with fait cer operation 1 problems but he/sh firm backup procedure » Pre res het A DBA can exercise control ov and periodically test the Procedare (2 physical, design and environments cause, The DBA should established « recovery methods by failure simulation on test S NEED FOR BACKUP PLANNING safeguard against failures of media, operating systems, software o¢ re oss of database files. The better the backup plan, the more g any {\ proper backup and recovery procedure requires discp ing ystems, Database backup is the only ‘other kind of failures that resu! will be available to you during recovery: and practice. “The ever-changing technology has made bacl restore the database depends on the types of bac! HARDWARE PROTECTION AND REDUNDANCY up planning a complicated task. The time it takes cups that are available. t of today’s software, itis important to protect hardware and sy by having systems redundancy. With mission-critical systems, even a few minutes of down ima play havoc in terms of business loss. To implement stable storage and to ensure high availabilie a vstems, many corporation employ Foolproof techniques. Some ofthese techniques are: "¢ Considering the growing complexity + UPS, or Uninterrupted Power Supply. * On-site spare parts. * Redundant switchover systems or switchover sites. + Disk mirroring or RAID (Redundant Array of Independent Disks) technology. ‘The simplest approach to introducing redundancy is to dupli is techni ne sm iplicate every disk. This technique is mirroring orshadowing. Here a logical disk contains two physical disks, and every write is cared ae disks, If one of the disks fails, the data can be read from the other. 7 Pete ge ie idena: ander formancerare cofiidered by organizat id particular hardware protection method. SE TRANSACTIONS “ec , , gears ae the unit of processing but also the unit of recovery. To recover from faut ee a eee wa a1log to keep track of al transaction operations. The logit ri ly up to archival storage (tape) to prevent it from catastrophe A commit point of i paces i Pn aR BL after a logical unit of work is done and when the databs®_ pect te point the effect of all the transaction operations on the database Properties of Transactions a ‘Transactions ha’ i r ee We four important properties which are often called the ACID properties. They 2: ransactions " a 7 . sare atomic, They are either performed in their entirety or not performed # sites © scanned with OKEN ScannerBackup and Recovery 5 saeney A transaction takes the database from one conistent a State to another. can The execution of @ (ransaction should not meddle with an cet YY other transaction executing ‘The changes made to the database by a committed tra mc ngs not Be Hs due to any failure msaction must survive, ie NIFICANCE OF BACKUPS «are as vital a8 insurance on our prized possessions. The i pst gata is put at risk due to any kind of failure. importance of backups is realized seed and success of the data recovery de ine speed an ; Ty depends on the type ‘pA determines the kind of backup procedures that should be Set ace of ee backups considering the setup of wher sie be classified into t a packops can broadly ie wn the database files are copied from on eS faa Poe inde ple, an operating system backup. The backup copy can be used to restore the database i rophic failure. a ical backups, on the contrary, store the data in binary files by ting it database or 9 extracting it from the sing SQL tools. The logical backup utilities store the data in the binary files fc reiting i eee selected database objects can be backed up and retrieved by the DBAs using the logical backup ses Generally, DBMSs offer a backup utility as part of the system, For example, the Expor/Import slits provided by Oracle can be used to create logical backups DATA STORAGE pata items in the database may be stored in a number of different storage media, Better understanding of storage media help us ensure the atomicity and durability properties of a transaction. Some of the ous types of storage media are discussed below. blale storage Information stored in volatile storage is lost in case of system crashes. For example, sin memory and cache memory. Volatile storage can be accessed extremely fast due to the memory speed and direct access. volatile storage Information stored in non-volatile storage survives system crashes. For example, metic disks which provide online storage and magnetic tapes which provide offline storage. Noo- ile storage is slower than volatile storage. In database systems, disks are mostly used for non- storage whereas other non-volatile media are used for backup data. file storage For stable storage, the information is replicated in several non-volatile storage media. example, RAID (Redundant Arrays of Independent Disks) technology, which ensures that the ie of a single disk does not result in loss of data. DATABASE RECOVERY Tecovery usually implies that the database is restored to the time of failure. Recovery techniques go hand in hand with concurre to the most recent consistent state just mney control mechanisms. © scanned with OKEN ScannerIntroduction to Database ‘Management Systems, .« to prepare for the eventuality of he database administrH at of a failure, the DBA soa Jd system failure. 10 the © quickly as possible and with litte of yo correct sta . he core ype of failure that has occurred, the rictres a that is desired. A. major responsibility of software, network, process prepared to bring the database back to t joss. Recovery processes differ, depending have Keen affected and the type of recovery _ RECOVERY CONCEPTS AND TERMINOLOGY tored to the most recent consistent .s that the database is rest 7 Ree fm ans aera ees cy ‘state H was recorded in the database hhould be discarded. ae ae se epend onthe kind of damage done tothe database Inq koe to the database, such as ‘a disk crash, the recovery method should restore 4 co database from the archival storage. a ie event bes fission becoming inconsistent, the strategy should be to undo some op that caused the inconsistency. There may also be a need to redo some operations in order to bring database to a consistent state In such a case, the entries stored in the online system log are used for recovery. The d update and the immediate update are two main techniques used for recovery from non-cata Tensaction failures. These techniques have been discussed later in the chapter. Disk Block Caching Disk pages that include the data items to be updated are cached into main memory buffers. The DB) i buffers—is used by DBMS for holding buffers. A directory for page addres, buffer location > entries. Any update operation is treated as permanent only when t buffers are emptied to secondary storage. A dirty bit is associated with each buffer in the cache, which can be included in the directory, to specify whether the buffer has been modified or not. The dirty bitis set to 0 (zero) when a page is read from the database into a cache buffer. On buffer modification, th ity bit is set to 1 (one). A bit called the pin-unpin bit is also used with the dirty bit. A page in thecad is pinned (bit value 1) if it cannot be written back to disk. ; The following two strategies can be used when flushing a modified buffer back to the disk: In-place updating Writes the buffer back to the same original disk location, i.e. overwrites the 0 value of any changed data items on disk. 5 Shadowing Writes an updated buffer at a different disk location. The value of the data item before updating is known as before i erie faa tee rec fore image (BFIM), and the new Write-Ahead Logging, Steal/No-Steal and Force/No-Force pied eee o oe Bs ee bak recovery in case of in-place updating, The recovery mechanism mu cons a * ie is stored in the log entry and that the log entry is emptied to disk befo replaced AFIM in the database on disk. This process is known as write-ab © scanned with OKEN ScannerBackup and Recovery co artog entry information included for a write command are nation required for UNDO and ifort” I ane mui for REDO that Jog entry contains the new value (AFIM). This is ype 108 sno" the log. The UNDO-type log entries include the old on fect of the operation from the log equired to redo the effect of the value (BFIM) since this is needed } : sc simply sequential disk file and the DBMS cache may contain many log blocks that will be 40 eeaee terminology includes the terms steal/no-steal and force-no- rom the database can be written to disk from the cache, ve page modified by a transaction cannot be written to the disk before the transact i an no-steal approach. The pin-unpin bit denotes whether a page can wa facGes +i Ifthe protocol allows writing an updated buffer before the transaction commits, it is called sal ig used when the DBMS buffer manager requires a buffer for another transaction and the ger replaces an existing page that had been updated but whose transaction has not committed. all pages updated by a transaction are immediately written to disk when the transaction commits, E caled force approach and the writing is called force-writng, Ifthe pages are emptied tothe when they are full or at some time interval, then itis called no-force approach. ical recovery mechanism uses a steal/ no-force approach. The advantage of steal technique is ‘avoids the need for very large buffer space to store all updated pages in the memory. The tage of no force strategy is that an updated page of a committed transaction may still be in the when another transaction might need to update it, thus reducing the disk I/O cost to read the page from the secondary storage (disk). If a specific page is updated heavily by multiple transactions, approach can result in substantial savings in the I/O cost. in-place updating is used, to permit recovery, the entries required for recovery must be sily recorded in the log on disk before the changes are made to the database. We will now see the write-ahead logging (WAL) protocol is implemented. The before-image of an item cannot be mitten by its after-image in the database until all undo-type log records for the updating transaction teen force-written to the disk. The commit operation of a transaction cannot be completed until e and undo-type log records for that transaction have been force-written to the disk. DBMS recovery component must maintain a number of details related to transactions that are processed in the system. These include a list of active transactions that have started but have not ited yet, alist of all committed and aborted transactions since the last checkpoint and so on. ery Facilities folowing facilities should be provided by a database management system to facilitate recovery: force. They specify 2 only mechanism that makes periodic backup copies of the database. ing facilities that keep track of the current state of transactions and database changes. point facility that enables updates to the database that are in progress to be made permanent ‘manager that allows the system to restore the database to a consistent state following a © scanned with OKEN Scanner© Scanned with OKEN Scanner© Scanned with OKEN ScannerManagement Systems a Introduction to Database A Undo logs Redo logs —_—— ‘Undo logs fray ~ Sea applied Database that is ihe 2PPlied — atabase with eh committed and recovered and database that restored ery uncommitted ee transactions yack phase Ee _Rolbesk eam 17.2. Rolling Forward and Rolling Back Fig. ffect may not yet have been recorded in the database. Hence the deferred update technique i a, effec a known as NO-UNDO/REDO algorithm. ited by some operations in Immediate update is a technique where database may be updated by Perations Of a transaction on reaches its commit pin. However, before these operations are applied tp See eer recorded inthe logon disk by foree-wrting aha peo falls after recording changes in the database but before reaching the commit point, the ect of the transaction og the database must be undone, i. the wansaction must be rolled back. So in the case ofthe immediate update technique, both undo and redo operations are needed during recovery. Hence, the immediate update technique is also known as the UNDO/REDO algorithm. A variation of the algorithm where a updates are recorded in the database before a transaction commits requires undo only. It is known as the UNDO/NO-REDO algorithm. F In the shadow paging technique, transaction logs are not requited. Two directories for each database Page are created during the life of a transaction—the current directory and the shadow directory. When the transaction commences, both the directories are the identical. The shadow directory is never altered during the duration of the transaction and the current directory is updated when the transaction performs a write operation, All VO operations use the current directory to locate the database pages on the disk When a value in the database is updated, the old record is not updated but a new one is created and the link in the current directory is changed to point to the newly created record. When a the shadow directory is discarded and the current directory becomes the database transaction aborts, the current directory is discarded. Deferred Update The deferred update technique aims at deferring or the transaction completes successfully and reaches Approach. In this protocol transaction commits, age directory. Ifthe Postponing any actual updates to the database until its commit point, So, deferred update is a no-steal } updates are not recorded to the database until © scanned with OKEN Scanner© Scanned with OKEN Scanner© Scanned with OKEN Scanner