2 Backup and Recovery Strategies</titl e> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta http-equiv="Content-Language" content="EN"> <meta h ttp-equiv="Content-Style-Type" content="text/css"> <meta http-equiv="Content-Script-Type" content="text/javascript"> <meta name="robo ts" content="all" scheme="http://www.robotstxt.org/"> <meta name="doctitle" content="Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1)"> <meta name="partno" content="B10735-01"> <meta name="docid" content="BRBSC"> <link rel="Start" href="../../ind ex.htm" title="Home" type="text/html"> <link rel="Copyright" href="../../dcommon/html/cpyr.htm" title="Copyright" type="text/html"> < link rel="Stylesheet" href="../../dcommon/css/doccd.css" title="Default" type="text/css"> <link rel="Contents" href="toc.htm" title=" Contents" type="text/html"> <link rel="Index" href="index.htm" title="Index" type="text/html"> <link rel="Glossary" href="glossary.ht m" title="Glossary" type="text/html"> <link rel="Prev" href="intro.htm" title="Previous" type="text/html"> <link rel="Next" href="set up.htm" title="Next" type="text/html"> <link rel="alternate" href="../b10735.pdf" title="PDF version" type="application/pdf"> </head> <body> <div class="header"> <p><a name="top" id="top" href="#BEGIN">Skip Headers</a></p> <table summary="" cellspacing="0" cellpaddi ng="0" width="100%"> <tr> <td align="left" valign="top"><font color="#330099" face="Helvetica, Arial, sans-serif"><strong>Oracle® Database Backup and Recovery Basics<br> 10<i>g</i> Release 1 (10.1)</strong><br> Part Number B10735-01</font></td> <td valign="bott om" align="right"> <table summary="" cellspacing="0" cellpadding="0" width="270"> <tr> <td align="center" valign="top"><a href="../.. /index.htm"><img src="../../dcommon/gifs/prodicon.gif" alt="Go to Documentation Home" border="0"><br> <font size="-2">Home</font></a> </td> <td align="center" valign="top"><a href="../../nav/portal_3.htm"><img src="../../dcommon/gifs/bookicon.gif" alt="Go to Book Lis t" border="0"><br> <font size="-2">Book List</font></a></td> <td align="center" valign="top"><a href="toc.htm"><img src="../../dcommo n/gifs/conticon.gif" alt="Go to Table of Contents" border="0"><br> <font size="-2">Contents</font></a></td> <td align="center" valign ="top"><a href="index.htm"><img src="../../dcommon/gifs/indxicon.gif" alt="Go to Index" border="0"><br> <font size="-2">Index</font>< /a></td> <td align="center" valign="top"><a href="../../mix$101/b12039/toc.htm"><img src="../../dcommon/gifs/mix.gif" alt="Go to Mast er Index" border="0"><br> <font size="-2">Master Index</font></a></td> <td align="center" valign="top"><a href="../../dcommon/ht ml/feedback.htm"><img src="../../dcommon/gifs/feedback.gif" alt="Go to Feedback page" border="0"><br> <font size="-2">Feedback</font> </a></td></tr></table></td></tr></table> <hr> <table summary="layout table" cellspacing="0" cellpadding="0" width="100%"> <tr> <td al ign="left" valign="top"> <table summary="layout table" cellspacing="0" cellpadding="0" align="left" width="90"> <tr> <td align="cente r" valign="top"><a href="intro.htm"><img src="../../dcommon/gifs/larrow.gif" alt="Go to previous page" border="0"><br> <font size="-2 ">Previous</font></a></td> <td align="center" valign="top"><a href="setup.htm"><img src="../../dcommon/gifs/rarrow.gif" alt="Go to ne xt page" border="0"><br> <font size="-2">Next</font></a></td></tr></table></td> <td align="right" valign="top"><a href="../b10735.pdf "><font size="-2">View PDF</font></a></td></tr></table> <a name="BEGIN"></a></div> <div class="IND"> <a name="1656 "></a>  <h1 class="Title"><font face="Arial, Helvetica, sans-serif" color="#330099">2<br> <a name="BRBSC008"> Backup and Recovery Strategies</a></font></h1>  <a name="1006919"></a> <p class="BP">This chapter offers guidelines and considerations for developing an effective backup and recovery strategy.</p> <a name="1006920"></a> <p class="BP">This section includes the following topics:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1007521"></a><a href="strategy.htm#1007632"> Data Recovery Strategy Determines Backup Strategy</a></li> <li class="LB1" type="disc"><a name="1007532"></a><a href="strategy.htm#10 09758">Planning Data Recovery Strategy</a></li> <li class="LB1" type="disc"><a name="1007630"></a><a href="strategy.htm#1011334">Plan ning Backup Strategy</a></li> <li class="LB1" type="disc"><a name="1008319"></a><a href="strategy.htm#1008276">Validating Your Data R ecovery Strategy</a></li></ul> <a name="1007632"></a>  <h2 class="H1"><font face="Arial, Helvetica, sans-serif " color="#330099"><strong class="Bold"><a name="BRBSC511">Data Recovery Strategy Determines Backup Strategy</a></strong></font></h2>  <a name="1007633"></a> <p class="BP">To decide on backup strategies, start with your data recovery requirements and y our data recovery strategy. Each type of data recovery will require that you take certain types of backup.</p> <a name="1009701"></a> <p class="BP">Failures can run the gamut from user error, datafile block corruption and media failure to situations like the comple te loss of a data center. How quickly you can resume normal operation of your database is a function of what kinds of restore and rec overy techniques you include in your planning. Each restore and recovery technique will impose requirements on your backup strategy, including which features of the Oracle database you use to take, store and manage your backups.</p> <a name="1009702"></a> <p class= "BP">When thinking about recovery strategies, ask yourself questions like these:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1007141"></a>If a disk failed and destroyed some of the database files, such as datafiles or redo logs, how would you recover t he lost files? As described in <a href="strategy.htm#1011383">"Planning a Response to Media Failure: Restore and Media Recovery"</a>< a href="strategy.htm#1011383"></a>, you should be able to handle the loss of datafiles, control files, and online redo logs.</li> <li class="LB1" type="disc"><a name="1007148"></a>If a logic error in an application or a user error caused the loss of important data f rom one or several tables or tablespaces, how could you recover that data, and what would happen to database updates since the error? Could you determine the cause of the error, to prevent it from happening again? As described in <a href="strategy.htm#1013229">"Plan ning a Response to User Error: Point-in-Time Recovery and Flashback Features"</a><a href="strategy.htm#1013229"></a>, techniques avai lable to you include point-in-time recovery of the whole database or one or more tablespaces, importing data from earlier logical exp orts with one of the data import utilities, and using the Oracle database's flashback features.</li> <li class="LB1" type="disc"><a n ame="1007155"></a>If the instance alert log indicates that one or more tables contains corrupt blocks, how can you repair the corrupt ion? Does the tablespace have to remain available during the repair? As described in <a href="strategy.htm#1011346">"Planning a Respo nse to Datafile Block Corruption: Block Media Recovery"</a><a href="strategy.htm#1011346"></a>, the RMAN <code>BLOCKRECOVER</code> co mmand can help you in this situation. Also, troubleshoot recovery with the SQL*Plus <code>RECOVER</code> <code>...</code> <code>TEST< /code> command.</li> <li class="LB1" type="disc"><a name="1007162"></a>If the entire data center is destroyed, can you perform disast er recovery? Assume that all you have is an archive tape containing backups. How would you recover the database? How long would that recovery take?</li> <li class="LB1" type="disc"><a name="1007217"></a>If you were not available to recover your database, could someo ne else recover it in your absence? Are your recovery procedures sufficiently automated and documented?</li></ul> <a name="1007648">< /a> <p class="BP">With these needs in mind, decide how you can take advantage of features related to backup and recovery, and look a t how each feature meets some requirement of your backup strategy. For example:</p> <ul class="LB1"> <li class="LB1" type="disc"><a n ame="1011089"></a>Using Recovery Manager simplifies most backup and recovery operations compared to user-managed backup and recovery. It automates management of most backup files, including the deletion of backups and archived redo logs from disk or tape when no lon ger needed to meet recovery goals. It provides detailed reporting on backup activities, can verify that your available backups can be used to recover your database. Finally, RMAN makes possible many recovery techniques not available if you are using user-managed bac kup and recovery, such as incremental backups.</li> <li class="LB1" type="disc"><a name="1009888"></a>Flashback Database will help yo u restore a database to a previous time much faster than media recovery. However, you must decide in advance to keep flashback logs, and keeping flashback logs requires that you configure a flash recovery area.</li> <li class="LB1" type="disc"><a name="1009889"></a> Block media recovery may be better than datafile media recovery if availability is critical. While block media recovery is possible e ven if you do not base your backup and recovery strategy on RMAN, RMAN-based block media recovery can be performed more quickly and w ith less effort.</li></ul> <a name="1007410"></a> <p class="BP">Once you decide which features to use in your recovery strategy, you can plan your backup strategy, answering the following questions, among others:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1008604"></a>How and where will you store your recovery-related files? Will you use a flash recovery area? Will you use an ASM disk group? Will you store backups on tape or other offline storage, or only on disk?</li> <li class="LB1" type="disc"><a name="10097 37"></a>At what intervals will you take scheduled backups? And what form of physical backups will you take in each situation?</li> <l i class="LB1" type="disc"><a name="1011166"></a>What situations require you to take a database backup outside of the regular schedule ? Sometimes you must take an unscheduled backup to ensure that you can recover your data, such as after an <code>OPEN RESETLOGS</code > or after changes to your database such as NOLOGGING operations that do not appear in the redo log. You may also have business requi rements that require backups for auditing purposes or other reasons not related to database recovery.</li> <li class="LB1" type="disc "><a name="1011167"></a>How can you validate your backups, to ensure that you can recover your database when necessary?</li> <li clas s="LB1" type="disc"><a name="1007096"></a>How do you manage records of your backups?</li> <li class="LB1" type="disc"><a name="100975 3"></a>Do you have detailed recovery plans that cover each type of failure? How do your DBAs can execute these plans in a crisis? Can scripts be written to automate execution of these plans in a crisis?</li> <li class="LB1" type="disc"><a name="1010423"></a>Can you apply Oracle database availability technologies, such as Data Guard or Real Application Clusters, to improve availability during a da tabase failure? How does using these availability technologies affect your backup and recovery strategy?</li></ul> <a name="1009754"> </a> <p class="BP">These are of course only a few of the considerations you should take into account. Available resources (hardware, media, staff, budget, and so on) will also be factors in your decision.</p> <a name="1009758"></a>  <h2 class ="H1"><font face="Arial, Helvetica, sans-serif" color="#330099"><strong class="Bold"><a name="BRBSC182">Planning Data Recovery Strate gy</a></strong></font></h2>  <a name="1008328"></a> <p class="BP">Your data recovery strategy should include responses to any number of database failure scenarios. The key to an effective, efficient strategy is envisioning failure modes, matching Orac le database recovery techniques and tools to the failure modes in which they are useful, and then making sure you incorporate the nec essary backup types to support those recovery techniques.</p> <a name="1007904"></a> <p class="BP">To help match failure modes to re covery techniques that can help resolve them, refer to the following sections:</p> <ul class="LB1"> <li class="LB1" type="disc"><a na me="1011187"></a><a href="strategy.htm#1013229">Planning a Response to User Error: Point-in-Time Recovery and Flashback Features</a>< /li> <li class="LB1" type="disc"><a name="1006753"></a><a href="strategy.htm#1011383">Planning a Response to Media Failure: Restore a nd Media Recovery</a></li> <li class="LB1" type="disc"><a name="1013227"></a><a href="strategy.htm#1011346">Planning a Response to Da tafile Block Corruption: Block Media Recovery</a></li></ul> <a name="1013229"></a>  <h3 class="H2"><font face= "Arial, Helvetica, sans-serif" color="#330099">Planning a Response to User Error: Point-in-Time Recovery and Flashback Features</font ></h3>  <a name="1011209"></a> <p class="BP">Your backup and recovery strategy should enable you to handle situations in which a user or application makes unwanted changes to database data, such as deleting the contents of a table or making incorrect updates during a batch run. The goal in such a case will be to restore the affected parts of your database to their state before the user error.</p> <a name="1011210"></a> <p class="BP">Depending on the situation, your appropriate response will be one of the follow ing:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1011211"></a>If you have performed a logical backup by exporting the c ontents of the affected tables, sometimes you can import the data back into the table. This technique presumes that you are regularly exporting logical backups of your data, and that any changes between exports are unimportant.</li> <li class="LB1" type="disc"><a na me="1011212"></a>You can perform point-in-time recovery, bringing one tablespace or the whole database back to its state before the t ime of the error. In either case, you need backups from before the time of the error, plus the redo logs from the time of the backup to the time of the error. <div align="center"> <table class="Note" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="Note"> <td class="Note" > <hr> <a name="1011222"></a><font face="Arial, Helvetica, sans-serif"><strong class="NH">Note:</strong></font> <a name="1011223"></a > <p class="NB">Oracle's Flashback Technology provides faster and less disruptive alternatives to media recovery in many circumstanc es.</p> <ul class="NL"> <li class="NL" type="disc"><a name="1012415"></a>Oracle Flashback Database is a physical-level recovery mecha nism similar to media recovery, but generally faster and not requiring the restore of data from backup.</li> <li class="NL" type="dis c"><a name="1013269"></a>Oracle Flashback Table and Oracle Flashback Drop work at the logical level, undoing unwanted changes to tabl es, including reversing the effects of <code>DROP TABLE</code> statements.</li> <li class="NL" type="disc"><a name="1013270"></a>Orac le Flashback Query and Oracle Flashback Version Query are useful in viewing past contents of tables and investigating how and when lo gical corruptions affected your database.</li></ul> <a name="1013259"></a> <p class="NB">Information about these features is collect ed in <em class="Italic"><a class="xlinkSRC BRADV94301" href="../../server$101/b10734/rcmflash.htm#BRADV94301">Oracle Database Backup and Recovery Advanced User's Guide</a></em>. This document will allude to such features where they can be helpful and provide pointe rs for more information. Familiarize yourself with these features before planning your backup and recovery strategy, because you may find that they can be quite valuable and require limited advanced planning.</p> <hr></td></tr></table></div></li></ul> <a name="10113 83"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Planning a Response to Medi a Failure: Restore and Media Recovery</font></h3>  <a name="1011384"></a> <p class="BP">A media failure occurs when a problem external to the database prevents Oracle from reading from or writing to a file during database operations. Typical media fai lures include physical failures, such as head crashes, and the overwriting, deletion or corruption of a database file. Media failures are less common than user or application errors, but your backup and recovery strategy should prepare for them.</p> <a name="1009773 "></a> <p class="BP">The type of media failure determines the recovery technique to use. For example, the strategy you use to recove r from a corrupted datafile is different from the strategy for recovering from the loss of the control file.</p> <a name="1009775"></ a>  <h4 class="H3"><font face="Arial, Helvetica, sans-serif" color="#330099">Example: Online Redo Log Recovery </font></h4>  <a name="1006823"></a> <p class="BP">The method of recovery from loss of all members of an online log gr oup depends on a number of factors, such as:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1006824"></a>The state of the database (open, crashed, closed consistently, and so on)</li> <li class="LB1" type="disc"><a name="1006825"></a>Whether the lost redo log group was current</li> <li class="LB1" type="disc"><a name="1006826"></a>Whether the lost redo log group was archived</li></ul> <a name="1006827"></a> <p class="BP">For example:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1011443"></a>If you lose the current group, and the database is not closed consistently (either it is open, or it has crashed), then you will have to restore an old backup and perform point-in-time recovery, followed by <code>OPEN</code> <code>RESETLOGS</code>. You will lose all transactio ns that were in the lost log. You should take a new full database backup immediately after the <code>OPEN RESETLOGS</code>. Backups f rom before the <code>OPEN RESETLOGS</code> will not be recoverable because of the lost log.</li> <li class="LB1" type="disc"><a name= "1011444"></a>If you lose the current redo log group, and if the database is closed consistently, then you can perform <code>OPEN</co de> <code>RESETLOGS</code> with no transaction loss. However, you should take a new full database backup. Backups from before the OPE N RESETLOGS will not be recoverable because of the lost log.</li> <li class="LB1" type="disc"><a name="1011329"></a>If you lose a non current redo log group, then you can use the <code>ALTER</code> <code>DATABASE</code> <code>CLEAR</code> <code>LOGFILE</code> stateme nt to re-create all members in the group. No transactions are lost. If the lost redo log group was archived before it was lost, then nothing further is required. Otherwise, you should immediately take a new full backup of your database. Backups from before the log w as lost will not be recoverable because of the lost log.</li></ul> <a name="1011346"></a>  <h3 class="H2"><fon t face="Arial, Helvetica, sans-serif" color="#330099">Planning a Response to Datafile Block Corruption: Block Media Recovery</font></ h3>  <a name="1011347"></a> <p class="BP">If a small number of blocks within one or more datafiles are corrupt, you ca n perform <strong class="GlossaryTerm">block media recovery</strong> instead of restoring the datafiles from backup and performing co mplete media recovery of those files. The Recovery Manager <code>BLOCKRECOVER</code> command can be used to restore and recover speci fied data blocks while the database is open and the corrupted datafile is online.</p> <a name="1011357"></a> <div align="center"> <t able class="NoteAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a no te" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class="NoteAlso"><a name="1011350"></a><font face="Ari al, Helvetica, sans-serif"><strong class="NH">See Also:</strong></font> <a name="1011356"></a> <p class="NB"><em class="Italic"><a c lass="olinkSRC BRADV" href="../../server$101/b10734/toc.htm">Oracle Database Backup and Recovery Advanced User's Guide</a></em> to le arn how to perform block media recovery with RMAN.</p></td></tr></table></div> <a name="1011334"></a>  <h2 cla ss="H1"><a name="BRBSC181"><font face="Arial, Helvetica, sans-serif" color="#330099">Planning Backup Strategy</font></a></h2>  <a name="1011279"></a> <p class="BP">Your plans for data recovery strategies are the basis of your plans for backup strategy . This discussion describes general guidelines that can help you decide when to perform database backups, which parts of a database y ou should back up, what tools Oracle provides for those backups, and how to configure your database to improve its robustness and mak e backup and recovery easier. Of course, the specifics of your strategy must balance the needs of your restore strategy with question s of cost, resources, personnel and other factors.</p> <a name="1004641"></a>  <h3 class="H2"><font face="Aria l, Helvetica, sans-serif" color="#330099">Protecting Your Redundancy Set</font></h3>  <a name="1004643"></a> <p class= "BP">The set of files needed to recover an Oracle database from the failure of any of its files--a datafile, control file, or online redo log--is called the <strong class="GlossaryTerm"><a href="glossary.htm#997928">redundancy set</a></strong>. The redundancy set sh ould contain:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1004647"></a>The last backup of the control file and all the datafiles</li> <li class="LB1" type="disc"><a name="1004648"></a>All archived redo logs generated after the last backup was taken</li > <li class="LB1" type="disc"><a name="1004649"></a>Duplicates of the online redo log files, generated by Oracle database multiplexin g, operating system mirroring, or both</li> <li class="LB1" type="disc"><a name="1004650"></a>Duplicates of the current control file, generated by Oracle database multiplexing, operating system mirroring, or both</li> <li class="LB1" type="disc"><a name="1004651"></ a>Copies of configuration files such as the server parameter file, <code>tnsnames.ora</code>, and <code>listener.ora</code></li></ul> <a name="1004652"></a> <p class="BP">The first rule of protecting your redundancy set is:</p> <div style="margin-left: 2em"><a name ="1006490"></a> <p class="BP1"><em class="Italic">The set of disks or other media that contain the redundancy set for your database should be separate from the disks that contain the datafiles, online redo logs, and control files.</em></p></div> <a name="1008431">< /a> <p class="BP">This practice ensures that the failure of a disk that contains a datafile does not also cause the loss of the back ups or redo logs needed to recover the datafile. Consequently, a minimal production-level database requires at least two disk drives: one to hold the files in the redundancy set and one to hold the database files. Ideally, separate the redundancy set from the primar y files in every way possible: on separate volumes, separate file systems, and separate RAID devices. Keeping the redundancy set sepa rate from the primary files ensures that you will not lose committed transactions in a disk failure.</p> <a name="1006473"></a> <p c lass="BP">The simplest way to manage your redundancy set is to use a flash recovery area, on a separate device from the working set f iles. All recovery-related files will be stored in a single location on disk, disk space usage is managed automatically, backups requ ired to meet your data recovery requirements are never deleted from disk while they are still needed, and recovery time is minimized without compromising the completeness of the redundancy set.</p> <a name="1006025"></a> <p class="BP">Whether or not you use a flash recovery area, Oracle Corporation recommends following these guidelines:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1 004655"></a>Multiplex the online redo log files and current control file at the database level. (For instance, configure the database to write its online logs to two or more destinations, so that each write is a separate operation carried out by the database, rather than by operating system-level or hardware-level redundancy.) If you multiplex at the database level, then an I/O failure or lost wr ite should only corrupt one of the copies. <p><a name="1010305"></a></p> <p class="BP1">Ideally, the multiplexed files should be on different disks mounted under different disk controllers. The flash recovery area is an excellent location for one copy of these file s.</p> <a name="1010314"></a> <p class="BP1">You can also mirror the online redo logs and current control file at the operating syst em or hardware level, but this is not a substitute for multiplexing at the database level.</p></li> <li class="LB1" type="disc"><a na me="1006057"></a>If running in ARCHIVELOG mode, archive the redo logs to multiple locations, ideally on different disks. If you are u sing a flash recovery area, use it as one of the archiving locations.</li> <li class="LB1" type="disc"><a name="1010331"></a>Use oper ating system or hardware mirroring for the control file. All copies of the control file multiplexed at the database level must be ava ilable at all times, or the instance will crash. If you use operating system or hardware mirroring for your control file, your databa se can continue to operate even if one copy of the control file mirrored at the operating system level is unavailable due to a disk f ailure.</li> <li class="LB1" type="disc"><a name="1004657"></a>Use operating system or hardware mirroring for the primary datafiles i f possible, to avoid having to perform media recovery for simple disk failures.</li> <li class="LB1" type="disc"><a name="1004658"></ a>Keep at least one copy of the entire redundancy set--including the most recent backup--on disk. The flash recovery area is the idea l location for the redundancy set. <p><a name="1006042"></a></p></li> <li class="LB1" type="disc"><a name="1004660"></a>If the targe t database is stored on a RAID device, then store the redundancy set on a set of disks that are not in the same RAID device.</li> <li class="LB1" type="disc"><a name="1004661"></a>If you store the redundancy set on tape, then maintain at least two copies of the data to protect against the risk of tape failure. Also, if you have more than one copy of the same data, then consider keeping backups fr om different points in time. In this way, if one backup or split mirror was done when the database was corrupted, then you have an ol der backup when the database was not corrupted.</li></ul> <a name="1004664"></a>  <h3 class="H2"><font face="A rial, Helvetica, sans-serif" color="#330099">Deciding Between ARCHIVELOG and NOARCHIVELOG Mode</font></h3>  <a name="10 12078"></a> <p class="BP">The redo logs of your database provide a complete record of changes to the datafiles of your database (wit h a few exceptions, such as direct path loads).</p> <a name="1012092"></a> <p class="BP">You can run your database in one of two mod es: ARCHIVELOG mode or NOARCHIVELOG mode. In ARCHIVELOG mode, a used online redo log group must be copied to one or more archive dest inations before it can be reused. Archiving the redo log preserves all transactions stored in that log, so that they can be used in r ecovery operations later. In NOARCHIVELOG mode, the online redo log groups are simply overwritten when the log is re-used. All inform ation about transactions recorded in that redo log group is lost.</p> <a name="1011595"></a>  <h4 class="H3">< font face="Arial, Helvetica, sans-serif" color="#330099">Implications of Running in NOARCHIVELOG Mode</font></h4>  <a n ame="1012420"></a> <p class="BP">Running your database in NOARCHIVELOG mode imposes severe limitations on your backup and recovery s trategy.</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1011823"></a>You cannot perform online backups of your database. Y ou must shut your database down cleanly before you can take a backup in NOARCHIVELOG mode.</li> <li class="LB1" type="disc"><a name=" 1012438"></a>You cannot use any data recovery techniques that require the archived redo logs. These include complete and point-in-tim e media recovery, as described in <a href="intro.htm#1016338">"Forms of Data Recovery"</a><a href="intro.htm#1016338"></a>, and more advanced recovery techniques such as point-in-time recovery of individual tablespaces and Flashback Database (described in <a class=" xlinkSRC BRADV155" href="../../server$101/b10734/rcmflash.htm#BRADV155"><em class="Italic">Oracle Database Backup and Recovery Advanc ed User's Guide</em></a>.).</li></ul> <a name="1012450"></a> <p class="BP">If you are running in NOARCHIVELOG mode and you must reco ver from damage to datafiles due to disk failure, you have two main options for recovery:</p> <ul class="LB1"> <li class="LB1" type=" disc"><a name="1011965"></a>Drop all objects that have any extents located in the affected files, and then drop the files. The remain der of the database is intact, but all data in the affected files is lost.</li> <li class="LB1" type="disc"><a name="1011971"></a>Res tore the entire database from the most recent backup, and lose all changes to the database since the backup. (Recovering changes sinc e the backup would require performing media recovery, which uses the archived redo logs.)</li></ul> <a name="1012457"></a>  <h4 class="H3"><font face="Arial, Helvetica, sans-serif" color="#330099">Implications of Running in ARCHIVELOG Mode</fo nt></h4>  <a name="1012006"></a> <p class="BP">For most applications, running in ARCHIVELOG mode is preferable to runn ing in NOARCHIVELOG mode because you have more flexible recovery options after a data loss. There are, however, associated costs of r unning in ARCHIVELOG mode:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1012023"></a>Space must be set aside for archivi ng destinations, locations on disk where the archived redo logs will be stored. These can become quite large in databases with large numbers of updates.</li> <li class="LB1" type="disc"><a name="1012131"></a>The stored archived redo logs must be managed. To limit th e disk space used by archived redo logs, archived redo logs can be moved to tape for longer-term storage, and older logs no longer ne eded to meet your recoverability goals should be deleted. (RMAN can automate most of the management of archived redo logs, by recordi ng the location and contents of all archived redo logs, making it easy to move archived logs to tape, and identifying and deleting re do logs no longer required to meet your recoverability objectives.)</li> <li class="LB1" type="disc"><a name="1012037"></a>Some perfo rmance overhead is associated with the background processes ARC0 through ARC<em class="Italic">n</em> which copy filled online redo l ogs to the archiving destinations.</li></ul> <a name="1012161"></a> <p class="BP">When performance requirements are extreme or disk space limitations are severe, it may be preferable to run in <code>NOARCHIVELOG</code> mode in spite of the restrictions imposed.</p> <a name="1009905"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Deciding Whe ther to Use a Flash Recovery Area</font></h3>  <a name="1009906"></a> <p class="BP">It is recommended that you take ad vantage of the flash recovery area to store as many backup and recovery-related fileas as possible, including disk backups and archiv ed redo logs.</p> <a name="1012779"></a> <p class="BP">Some features of Oracle database backup and recovery, such as Oracle Flashbac k Database, require the use of a flash recovery area. In such cases, you must create a flash recovery area, though you do not have to use it to store all recovery-related files.</p> <a name="1012805"></a> <p class="BP">Even when its use is not required, however, th e flash recovery area offers a number of advantages over other on-disk backup storage methods. Backups moved to tape from the flash r ecovery area are retained on disk until space is needed for other required files, reducing the need to restore backups from tape. At the same time, obsolete files no longer needed to meet your recoverability goals and files backed up to tape become eligible for dele tion and are deleted when space is needed, eliminating the need for DBA intervention to clear out old files.</p> <div align="center"> <table class="NoteAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class="NoteAlso"><a name="1012782"></a><font face=" Arial, Helvetica, sans-serif"><strong class="NH">See Also:</strong></font> <a name="1012788"></a> <p class="NB"><a href="setup.htm#1 019162">"Setting Up a Flash Recovery Area for RMAN"</a><a href="setup.htm#1019162"></a> for more about the uses and benefits of the f lash recovery area.</p></td></tr></table></div> <br> <br> <a name="1012792"></a>  <h3 class="H2"><font face=" Arial, Helvetica, sans-serif" color="#330099">Choosing a Backup Retention Policy</font></h3>  <a name="1012701"></a> < p class="BP">Your backup retention policy is the rule you set regarding which backups must be retained (whether on disk or other back up media) to meet your recovery and other requirements.</p> <a name="1010666"></a> <p class="BP">Backup retention policy can be base d on <strong class="GlossaryTerm">redundancy</strong> or a <strong class="GlossaryTerm">recovery window</strong>. In a redundancy-bas ed retention policy, you specify a number <em class="Italic">n</em> such that you always keep at least <em class="Italic">n</em> dist inct backups of each file in your database. In a recovery window-based retention policy, you specify a time interval in the past (for example, one week, or one month) and keep all backups required to let you perform point-in-time recovery to any point during that wi ndow.</p> <a name="1012736"></a> <p class="BP">A backup no longer needed to satisfy the backup retention policy is said to be <stron g class="GlossaryTerm">obsolete</strong>.</p> <a name="1010863"></a>  <h4 class="H3"><font face="Arial, Helvet ica, sans-serif" color="#330099">Implementing Backup Retention Policy with RMAN</font></h4>  <a name="1010645"></a> <p class="BP">RMAN automates the implementation of a backup retention policy, using the following commands:</p> <ul class="LB1"> <li cl ass="LB1" type="disc"><a name="1010771"></a><code>CONFIGURE RETENTION POLICY</code> command lets you set the retention policy that wi ll apply to all of your database files by default.</li> <li class="LB1" type="disc"><a name="1010826"></a><code>REPORT</code> <code>O BSOLETE</code> command lets you list backups currently on disk that are obsolete under the retention policy. You can also specify par ameters to see which files would be obsolete under different retention policies.</li> <li class="LB1" type="disc"><a name="1010827">< /a><code>DELETE</code> <code>OBSOLETE</code> command deletes the files which <code>REPORT OBSOLETE</code> would list as obsolete.</li > <li class="LB1" type="disc"><a name="1010785"></a><code>CHANGE</code>... <code>KEEP</code> lets you set a separate retention policy for specific backups, such as <strong class="GlossaryTerm">long-term backups</strong> kept for archival purposes. You can specify th at a given backup must be kept until a future time, or even specify that a backup be kept forever. <code>CHANGE</code>... <code>NOKEE P</code> is used to let the retention policy apply to a backup previously protected by <code>CHANGE</code>... <code>KEEP</code>.</li> </ul> <a name="1012844"></a> <p class="BP">If you use a flash recovery area to store your backups, the database will delete obsolete backups automatically as disk space is needed for newer backups, archived logs and other files. For backups stored on disk outside a flash recovery area and for backups stored on tape, you should periodically run the <code>DELETE OBSOLETE</code> command to remove o bsolete backups.</p> <a name="1009933"></a>  <h4 class="H3"><font face="Arial, Helvetica, sans-serif" color="# 330099">Recovery Window-Based Backup Retention Policy</font></h4>  <a name="1008998"></a> <p class="BP">A recovery win dow-based retention policy lets you guarantee that you can perform point-in-time recovery to any point in the past, up to a number of days that you specify. The earliest point in time to which you can recover your database under your retention policy is known as the <strong class="GlossaryTerm">point of recoverability</strong>. All backups required for recovery or point-in-time recovery back to t hat time will be retained.</p> <a name="1012711"></a> <p class="BP">Note that this will generally require that you keep backups olde r than the beginning of the recovery window. A point-in-time recovery to the beginning of the recovery window would require a restore from this backup, and then applying all changes between the backup time and the point of recoverability. For example, you might conf igure a recovery window of three days:</p> <pre class="CE"><a name="1009190"></a>RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WIND OW OF 3 DAYS; <a name="1009194"></a> </pre> <a name="1009660"></a> <p class="BP">If your last full database backup was six days ago, RMAN will keep the six-day-old backup, and all redo logs required to roll the database forward to the beginning of the recovery wind ow three days ago, in addition to any backups and redo logs needed to recover the database to all points in time within the three day window.</p> <a name="1009661"></a> <p class="BP">A recovery window-based backup retention policy provides the most certain recovera bility for your data. The disadvantage is that more careful disk space planning is required, since it may not be obvious how many bac kups of datafiles and archived logs must be retained to guarantee the recovery window.</p> <a name="1009139"></a>  <h4 class="H3"><font face="Arial, Helvetica, sans-serif" color="#330099">Redundancy-Based Backup Retention Policy</font></h4> <! --/TOC=h3--> <a name="1009184"></a> <p class="BP">A redundancy-based backup retention policy determines whether a backup is obsolete based on how many backups of a file are currently on disk. You might configure a redundancy level of 3:</p> <pre class="CE"><a name= "1009679"></a>RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3; <a name="1012877"></a> </pre> <a name="1012878"></a> <p class="BP ">In this case, RMAN keeps three backups of each database file, and all redo logs required to recover all retained datafile backups t o the current time. Any older backups will be considered obsolete.</p> <a name="1013420"></a> <p class="BP">Assume, for instance, th at you make backups of a datafile every day, starting on a Monday. On Thursday, you make your fourth backup of the datafile, and the backup from Monday becomes obsolete because you have the backups from Tuesday, Wednesday and Thursday. On Friday, the backup from Tue sday becomes obsolete, because you have the backups from Wednesday, Thursday and Friday.</p> <a name="1009219"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Archiving Older Backups</font></h3>  <a name="1008865"></a> <p class="BP">There are several reasons to keep older backups of datafiles and archived logs:</p> <ul class="LB 1"> <li class="LB1" type="disc"><a name="1008866"></a>An older backup of datafiles and archived logs is necessary for performing poin t-in-time recovery to a time before your most recent backup.</li> <li class="LB1" type="disc"><a name="1008867"></a>If your most rece nt backup is corrupt, you can still recover your database using an older backup and the complete set of archived logs since that olde r backup.</li> <li class="LB1" type="disc"><a name="1008868"></a>You may want to keep a copy of the database for archival purposes.</ li></ul> <a name="1008869"></a> <p class="BP">To perform point-in-time recovery to a given target time earlier than your current poi nt of recoverability, then you need a database backup that completed before the target time, as well as all of the archived logs crea ted between the time the backup was started and the target time. For example, if you take full database backups starting at 1:00 AM o n February 1 (at SCN 10000) and on February 14 (at SCN 20000), and if you decide on February 28 to use point-in-time recovery to brin g your database to its state at 9:00AM February 7 (SCN 13500), then you must use the February 1 backup, plus all redo logs containing changes from between the beginning of the creation of the backup (SCN 10000) and 9:00AM February 7 (SCN 13500).</p> <a name="1012912 "></a> <p class="BP">Note that point-in-time recovery to a time between backups is not an option for a database operating in <code>N OARCHIVELOG</code> mode. You can only restore your entire database from a consistent whole database backup, and re-open the database as of the time of that backup. You will lose all changes since the backup was taken.</p> <a name="1008697"></a>  < a name="1004728"></a> <p class="BP">Frequent backups are essential for any recovery scheme. Base the frequency of backups on the rat e or frequency of database changes such as:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1004729"></a>Addition and delet ion of tables</li> <li class="LB1" type="disc"><a name="1004730"></a>Insertions and deletions of rows in existing tables</li> <li cla ss="LB1" type="disc"><a name="1004731"></a>Updates to data within tables</li></ul> <a name="1004732"></a> <p class="BP">The more fre quently your database is updated, the more often you should perform database backups. The scenario in <a href="bkup.htm#1018230">"Bac kup Scripts When Blocks Change Frequently"</a><a href="bkup.htm#1018230"></a> backs up the database every week.</p> <a name="1006078" ></a> <p class="BP">If database updates are relatively infrequent, then you can make whole database backups infrequently and supplem ent them with incremental backups (which will be relatively small because few blocks have changed). The scenario in <a href="bkup.htm #1027628">"Backup Scripts When Few Data Blocks Change"</a><a href="bkup.htm#1027628"></a> describes how to develop a backup strategy based on a single whole database backup.</p> <a name="1004743"></a> <div align="center"> <table class="NoteAlso" border="0" width="8 0%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to form at a note"> <tr class="NoteAlso"> <td class="NoteAlso"><a name="1006168"></a><font face="Arial, Helvetica, sans-serif"><strong class= "NH">See Also:</strong></font> <a name="1006171"></a> <ul class="NL"> <li class="NL" type="disc"><a name="1006178"></a><a href="bkup .htm#1027313">"Backing Up to the Flash Recovery Area: Basic Scenarios"</a><a href="bkup.htm#1027313"></a></li> <li class="NL" type="d isc"><a name="1006152"></a><a href="bkup.htm#1010675">"Backing Up to the Flash Recovery Area and to Tape: Basic Scenarios"</a><a href ="bkup.htm#1010675"></a></li></ul></td></tr></table></div> <a name="1004745"></a>  <h3 class="H2"><font face=" Arial, Helvetica, sans-serif" color="#330099">Performing Backups Before and After You Make Structural Changes</font></h3>  <a name="1004747"></a> <p class="BP">There are times when you will need to take a backup of your database independent of your re gular backup schedule. If you make any of the following structural changes, then perform a backup of the appropriate portion of your database immediately before and after completing the following changes:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="100 4748"></a>Create or drop a tablespace.</li> <li class="LB1" type="disc"><a name="1004749"></a>Add or rename a datafile in an existing tablespace.</li> <li class="LB1" type="disc"><a name="1004750"></a>Add, rename, or drop an online redo log group or member.</li></ul > <a name="1004751"></a> <p class="BP">The part of the database that you should back up depends on your archiving mode.</p> <a name= "1007836"></a> <table summary="" class="RuleInformal" border="1" width="100%" cellpadding="3" cellspacing="0" dir="ltr" title=""> <t head> <tr class="Informal"> <th class="Informal" align="left" valign="bottom" scope="col"><a name="1007825"></a> <font face="Arial, H elvetica, sans-serif"><strong>Mode</strong></font></th> <th class="Informal" align="left" valign="bottom" scope="col"><a name="100782 7"></a> <font face="Arial, Helvetica, sans-serif"><strong>Action</strong></font></th></tr></thead> <tbody> <tr class="Informal" align ="left" valign="top"> <td class="Informal"><a name="1007829"></a> <p class="TB"><code>ARCHIVELOG</code></p></td> <td class="Informal "><a name="1007831"></a> <p class="TB">Make a control file backup (using RMAN or using the SQL <code>ALTER</code> <code>DATABASE</co de> statement with the <code>BACKUP</code> <code>CONTROLFILE</code> option) after a structural alteration. Of course, you can back up other parts of the database as well.</p></td></tr> <tr class="Informal" align="left" valign="top"> <td class="Informal"><a name="100 7833"></a> <p class="TB"><code>NOARCHIVELOG</code></p></td> <td class="Informal"><a name="1007835"></a> <p class="TB">Make a consis tent whole database backup immediately after the modification.</p></td></tr></tbody></table> <a name="1007838"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Backing Up Frequently Used Tablespaces</font></h3> <! --/TOC=h2--> <a name="1007841"></a> <p class="BP">If you run in <code>ARCHIVELOG</code> mode, then you can back up an individual tab lespace or even a single datafile. You might want to do this for one or more tablespaces that are updated much more often than the re st of your database, as is sometimes the case for the <code>SYSTEM</code> tablespace and automatic undo tablespaces.</p> <a name="101 1036"></a> <p class="BP">More frequent backups of heavily-used datafiles can shorten recovery times in some situations. You may have a database where most updates are restricted to a small set of tablespaces. If you take a full database backup each Sunday, then rec overy from a media failure affecting the frequently updated tablespaces on Friday requires re-applying large amounts of redo. Daily b ackups of the frequently-updated tablespaces reduces the amount of redo to apply without requiring a daily full database backup.</p> <a name="1004782"></a> <div align="center"> <table class="NoteAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class=" NoteAlso"><a name="1004775"></a><font face="Arial, Helvetica, sans-serif"><strong class="NH">See Also:</strong></font> <a name="10047 81"></a> <p class="NB"><em class="Italic"><a class="xlinkSRC ADMIN013" href="../../server$101/b10739/undo.htm#ADMIN013">Oracle Datab ase Administrator's Guide</a></em> for information about managing undo tablespaces</p></td></tr></table></div> <a name="1004784"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Backing Up after NOLOGGING Operatio ns</font></h3>  <a name="1004786"></a> <p class="BP">When a direct path load is performed to populate a database, no r edo data is logged for those database changes. You cannot recover these changes after a restore from backup using conventional media recovery. Likewise, when tables and indexes are created as <code>NOLOGGING</code>, the database does not log redo data for these obje cts, which means that you cannot recover these objects from existing backups. Therefore, you should back up your datafiles after oper ations for which no redo data is logged.</p> <a name="1004791"></a> <div align="center"> <table class="Note" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="Note"> <td class="Note"> <hr> <a name="1010204"></a><font face="Arial, Helvetica, sans-serif"><strong class="NH">N ote:</strong></font> <a name="1010217"></a> <p class="NB">You can use either a full backup of your datafiles or an incremental backu p. Either one will capture all changed blocks, including blocks changed by unrecoverable operations.</p> <hr></td></tr></table></div> <a name="1004801"></a> <div align="center"> <table class="NoteAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr " summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class= "NoteAlso"><a name="1004794"></a><font face="Arial, Helvetica, sans-serif"><strong class="NH">See Also:</strong></font> <a name="1004 800"></a> <p class="NB"><em class="Italic"><a class="xlinkSRC SQLRF017" href="../../server$101/b10759/statements_10.htm#SQLRF017">Or acle Database SQL Reference</a></em> for information about the <code>UNRECOVERABLE</code> option of the <code>CREATE</code> <code>TAB LE</code> <code>...</code> <code>AS</code> <code>SELECT</code> and <code>CREATE</code> <code>INDEX</code> statements.</p></td></tr></ table></div> <a name="1006613"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099"> Exporting Data for Added Protection and Flexibility</font></h3>  <a name="1008388"></a> <p class="BP">Oracle database import and export utilities are used to export database objects (tables, stored procedures, and so forth) from databases to be stored as files, and re-import objects from those files. An export provides a logical-level snapshot of the exported objects at the time of the export, as a binary file that can be imported back into the source database or some other database. Consider exporting portions or all of a database for supplemental protection and flexibility in a database's backup strategy.</p> <a name="1004872"></a> <p clas s="BP">While useful, database exports are not a substitute for whole database backups. They cannot provide the same complete recovery advantages of physical-level backups. For example, you cannot apply archived logs to logical backups in order to update lost changes .</p> <div align="center"> <table class="NoteAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class="NoteAlso"><a name= "1013111"></a><font face="Arial, Helvetica, sans-serif"><strong class="NH">See also:</strong></font> <a name="1013117"></a> <p class ="NB"><em class="Italic"><a class="xlinkSRC SUTIL100" href="../../server$101/b10825/dp_overview.htm#SUTIL100">Oracle Database Utiliti es</a></em> for more details about exporting and importing data for logical backup</p></td></tr></table></div> <br> <br> <a name="10 04882"></a> <a name="1006640"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">P reventing the Backup of Online Redo Logs</font></h3>  <a name="1006642"></a> <p class="BP">Online redo logs, unlike ar chived logs, should never be backed up. The chief danger associated by having backups of online redo logs is that you may accidentall y restore those backups without meaning to, and corrupt your database.</p> <a name="1006658"></a> <p class="BP">Online redo log back ups are also not particularly useful, for the following reasons:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1004889">< /a>If your database is in <code>ARCHIVELOG</code> mode, then the archiver is already archiving the filled redo logs automatically.</l i> <li class="LB1" type="disc"><a name="1004890"></a>If your database is in <code>NOARCHIVELOG</code> mode, then the only type of phy sical backups that you can perform are closed, consistent, whole database backups. The files in this type of backup are all consisten t and do not need recovery, so the online logs are not useful after a restore from backup.</li></ul> <a name="1006689"></a> <p class ="BP">The best method for protecting the online logs against media failure is to multiplex them, with multiple log members in each gr oup, on different disks attached to different disk controllers.</p> <a name="1004906"></a> <div align="center"> <table class="Note" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a l ayout table to format a note"> <tr class="Note"> <td class="Note"> <hr> <a name="1004903"></a><font face="Arial, Helvetica, sans-seri f"><strong class="NH">Note:</strong></font> <a name="1004904"></a> <p class="NB">RMAN does not permit you to back up online redo log s. You must archive a redo log before backing it up.</p> <hr></td></tr></table></div> <a name="1004908"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Keeping Records of the Hardware and Software Configuration o f the Server</font></h3>  <a name="1011007"></a> <p class="BP">During the stress of a recovery situation, it is import ant that you have all necessary information at your disposal. This is especially true if for some reason you need to contact Oracle S upport because you run into a problem that you do not understand. You should have the following documentation about the hardware conf iguration:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1011008"></a>The name, make, and model of the machine that hosts the database</li> <li class="LB1" type="disc"><a name="1011009"></a>The version and patch of the operating system</li> <li class="LB 1" type="disc"><a name="1004915"></a>The number of disks and disk controllers</li> <li class="LB1" type="disc"><a name="1004916"></a> The disk capacity and free space</li> <li class="LB1" type="disc"><a name="1013000"></a>The names of all datafiles</li> <li class="LB 1" type="disc"><a name="1004917"></a>The name and version of the media management software (if you use a third-party media manager)</ li></ul> <a name="1004919"></a> <p class="BP">You should also keep the following documentation about the software configuration:</p> <ul class="LB1"> <li class="LB1" type="disc"><a name="1004920"></a>The name of the database instance (SID)</li> <li class="LB1" type ="disc"><a name="1004921"></a>The database identifier (DBID)</li> <li class="LB1" type="disc"><a name="1004922"></a>The version and p atch release of the Oracle database server</li> <li class="LB1" type="disc"><a name="1004923"></a>The version and patch release of th e networking software</li> <li class="LB1" type="disc"><a name="1004924"></a>The method (RMAN or user-managed) and frequency of datab ase backups</li> <li class="LB1" type="disc"><a name="1004925"></a>The method of restore and recovery (RMAN or user-managed)</li></ul > <a name="1004927"></a> <p class="BP">You should keep this information both in electronic and hardcopy form. For example, if you sa ve this information in a text file on the network or in an email message, then if the entire system goes down, you may not have acces s to this data.</p> <a name="1012287"></a> <p class="BP">It is especially important to keep a record of the DBID. If you have to res tore and recover your database including the loss of the SPFILE and control file, you will need the DBID during the recovery process. See <a href="recov.htm#1040845">"Basic Database Restore and Recovery Scenarios"</a><a href="recov.htm#1040845"></a> for details on h ow the DBID is used during recovery.</p> <a name="1008276"></a>  <h2 class="H1"><a name="BRBSC512"><font face= "Arial, Helvetica, sans-serif" color="#330099">Validating Your Data Recovery Strategy</font></a></h2>  <a name="1008277 "></a> <p class="BP">Practice backup and recovery techniques in a test environment before and after you move to a production system. In this way, you can measure the thoroughness of your strategies and minimize problems before they occur in a real situation. Perfor ming test recoveries regularly ensures that your archiving, backup, and recovery procedures work. It also helps you stay familiar wit h recovery procedures, so that you are less likely to make a mistake in a crisis.</p> <a name="1008279"></a> <p class="BP">If you us e RMAN, then run the <code>DUPLICATE</code> command to create a test database using backups of your production database. If you perfo rm user-managed backup and recovery, then you can either create a new database, a standby database, or a copy of an existing database by using a combination of operating system and SQL*Plus commands.</p> <a name="1013044"></a> <div align="center"> <table class="Not eAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class="NoteAlso"><a name="1013037"></a><font face="Arial, Helvetica, sans-serif"><strong class="NH">See Also:</strong></font> <a name="1013041"></a> <p class="NB"><em class="Italic"><a class="olinkSRC BRADV" href="../../server$101/b10734/toc.htm">Oracle Database Backup and Recovery Advanced User's Guide</a></em> to learn about RMAN testing methods, troubleshooting SQL*Plus recovery, block media recovery, and RMAN disaster recovery</p></td></tr></table></div> <a n ame="1013046"></a>  <h3 class="H2"><font face="Arial, Helvetica, sans-serif" color="#330099">Validating RMAN B ackups: BACKUP VALIDATE and RESTORE VALIDATE</font></h3>  <a name="1013060"></a> <p class="BP">The RMAN <code>BACKUP V ALIDATE</code> and <code>RESTORE VALIDATE</code> commands can be a useful part of your recovery plan testing. <code>BACKUP VALIDATE</ code> reads all of the specified files but does not produce any output files. All of the data blocks in the input files are validated , exactly as they are when a real backup takes place. <code>RESTORE VALIDATE</code> reads all of the backup files that would be neede d to restore the specified objects, but the objects are not actually restored to disk. All of the data blocks in the backup files are validated, exactly as they are when a real restore takes place. Just as in a real restore, <code>RESTORE VALIDATE</code> automatical ly chooses which backup files to restore from. For example, the command <code>RESTORE VALIDATE DATABASE</code> ensures that, for ever y file in the database, a valid backup exists, can be read, and contains valid data.</p> <a name="1013474"></a> <div align="center"> <table class="NoteAlso" border="0" width="80%" cellpadding="0" cellspacing="0" dir="ltr" summary="This is a layout table to format a note" title="This is a layout table to format a note"> <tr class="NoteAlso"> <td class="NoteAlso"><a name="1013477"></a><font face=" Arial, Helvetica, sans-serif"><strong class="NH"><strong class="Bold">See Also</strong>:</strong></font> <a name="1013478"></a> <p c lass="NB"><a href="bkup.htm#1010506">"Validating RMAN Backups"</a><a href="bkup.htm#1010506"></a> for more details on using <code>BAC KUP VALIDATE</code> and <code>RESTORE VALIDATE</code></p></td></tr></table></div></div> <div class="footer"> <hr> <table summary="" c ellspacing="0" cellpadding="0" width="100%"> <tr> <td style="width: 33%;" align="left"> <table summary="layout table" cellspacing="0" cellpadding="0" align="left" width="90"> <tr> <td align="center" valign="top"><a href="intro.htm"><img src="../../dcommon/gifs/larro w.gif" alt="Go to previous page" border="0"><br> <font size="-2">Previous</font></a></td> <td align="center" valign="top"><a href="se tup.htm"><img src="../../dcommon/gifs/rarrow.gif" alt="Go to next page" border="0"><br> <font size="-2">Next</font></a></td></tr></ta ble></td> <td style="width: 34%;" align="center"><img src="../../dcommon/gifs/oracle.gif" alt="Oracle"><br> <a href="../../dcommon/ht ml/cpyr.htm"><font size="-2">Copyright © 2003 Oracle Corporation</font></a><br> <font size="-2">All Rights Reserved.</font></td> <td style="width: 33%;" align="right"> <table summary="" cellspacing="0" cellpadding="0" width="270"> <tr> <td align="center" valign ="top"><a href="../../index.htm"><img src="../../dcommon/gifs/prodicon.gif" alt="Go to Documentation Home" border="0"><br> <font size ="-2">Home</font></a></td> <td align="center" valign="top"><a href="../../nav/portal_3.htm"><img src="../../dcommon/gifs/bookicon.gif " alt="Go to Book List" border="0"><br> <font size="-2">Book List</font></a></td> <td align="center" valign="top"><a href="toc.htm">< img src="../../dcommon/gifs/conticon.gif" alt="Go to Table of Contents" border="0"><br> <font size="-2">Contents</font></a></td> <td align="center" valign="top"><a href="index.htm"><img src="../../dcommon/gifs/indxicon.gif" alt="Go to Index" border="0"><br> <font si ze="-2">Index</font></a></td> <td align="center" valign="top"><a href="../../mix$101/b12039/toc.htm"><img src="../../dcommon/gifs/mix .gif" alt="Go to Master Index" border="0"><br> <font size="-2">Master Index</font></a></td> <td align="center" valign="top"><a h ref="../../dcommon/html/feedback.htm"><img src="../../dcommon/gifs/feedback.gif" alt="Go to Feedback page" border="0"><br> <font size ="-2">Feedback</font></a></td></tr></table></td></tr></table></div> </body> </html>