RMAN Recipes for Oracle Database 11g : A - Approach by Darl Kuhn, Sam Alapati and Arup Nanda Apress. (c) 2007. Copying Prohibited. Reprinted for MICHAEL DOAN, SAIC MICHAEL.DOAN@saic.com Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited.
Chapter 11: Performing Complete Recovery Overview Be thankful for problems. If they were less difficult, someone else with less ability might have your job. James A. Lovell When an airplane is flying on autopilot through clear skies, you don't worry too much about the experience level of the pilot. It's when an engine catches on fire that you want somebody who is prepared and trained to handle the disaster. Or if the pilot isn't trained, let's hope they have a comprehensive How to Handle Disasters recipe book handy. That also holds true in the database arena. When the database is up and running smoothly, nobody pays too much attention to the database and the DBA. It's when disaster strikes that companies are thankful they've invested in a DBA who has implemented a solid backup and recovery strategy. It's critical that you have a plan and understand what to do when you see messages like the following: ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/ora02/brdstn/system01.dbf' No DBA likes to see that message. However, accidents happen. People do incorrect things. Disks fail. These are all things that can cause failures. A media failure occurs when Oracle can't read or write to a required database file. Media recovery is the process of restoring files and reapplying transactions to recover the datafiles that have experienced media failure. The next several paragraphs will explain the internals of the Oracle restore and recovery process and many terms and definitions that are used by DBAs. Background Most recovery scenarios have two separate phases: restore and recovery. Restore is the process of retrieving files from backups. Appropriately named, the RMAN restore command is used to retrieve datafiles, control files, archived redo log files, and server parameter files (spfiles) from backup sets. When RMAN restores a datafile, it will reconstruct an exact copy of the datafile as it was when it was backed up. RMAN is the only utility that can restore files from RMAN backup pieces. Recovery is the process of applying transactions from redo files to the datafiles. Complete recovery means you can recover all transactions that were committed in your database before the failure occurred. You can use either RMAN or SQL*Plus to issue a recover command. Aside from a few minor differences, it doesn't matter whether you use RMAN or SQL*Plus to initiate a recovery. Both result in redo being applied to datafiles to recover transactions. This book focuses on RMAN-initiated restore and recovery examples. For complete recovery, you do not have to restore and recover all the datafiles in your database. You have to restore and recover only those datafiles that are damaged. Depending on the type of failure, that could be all the datafiles in your database or just one datafile. Oracle detects which datafiles need media recovery by comparing the system change number (SCN) information in the control file and the corresponding SCN information in the datafile headers. Incomplete recovery means that you cannot restore all committed transactions. Incomplete recovery is required when you don't have all the redo required to apply all transactions to the datafiles. You can also initiate incomplete recovery intentionally to restore the database to a previous state to recover data that was accidentally deleted. Incomplete recovery is initiated with the recover database until command. Chapter 12 discusses incomplete recovery. Chapter 13 discusses performing incomplete recovery via the flashback database feature. To understand what type of recovery is required, it's helpful to first understand the mechanics of how Oracle handles transactions. Here's a typical transaction: SQL> insert into table my_table values(1); SQL> commit; Commit complete. When you see Commit complete, Oracle guarantees that a record of that transaction has been safely written to the current online redo log file on disk. That does not mean the modified block has yet been written to the appropriate datafile. The transaction information in the online redo log buffer is written very frequently to disk by the log writer background process, whereas changes to the modified blocks in the database buffer are only periodically written to disk by the database writer background process. Page 2 / 32
Periodically, all changed (dirty) block buffers in memory are written (by database writer) to the datafiles on disk. This is known as a checkpoint. When a checkpoint occurs, the check- point process records the current checkpoint SCN in the control files and the corresponding SCN in the datafile headers. A checkpoint guarantees that the datafiles are in a consistent state at a point in time. The algorithm used by the log writer to write transaction information from the log buffer to the online redo log files is entirely different from the algorithm used by the database writer to write changed blocks from the database buffer to the datafiles. This is because the log buffer and the database buffer have entirely different goals. The purpose of the log buffer is to temporarily buffer transaction changes and get them quickly written to a safe location on disk (online redo log files), whereas the database buffer tries to keep blocks in memory as long as possible to increase the performance of processes using frequently accessed blocks. Because the log writer's activities are not synchronized with the database writer's activities, at any point in time you could have committed transactions that exist in the online redo log file but not yet have the corresponding changed blocks written to the datafiles. Also, at any given time there might be blocks with uncommitted changes written to the datafiles. This is the expected behavior. Oracle keeps track of what has been committed (or not) and ensures that you're always presented with a read consistent and committed version of the database. In the event of an unexpected failure, Oracle is able to sort out what was committed or not via information in the redo stream and rollback segments. Figure 11-1 shows how the redo information flows from background processes to memory buffers and eventually to the redo files. Figure 11-1: Oracle redo stream If You're Still Awake An instance (crash) failure occurs when your database isn't able to shut down normally. When this happens, your datafiles could be in an inconsistent state meaning they may not contain all committed changes and may contain uncommitted changes. Instance failures occur when the instance terminates abnormally. A sudden power failure or a shutdown abort are two common causes of instance failure. Oracle uses crash recovery to return the database to a consistent committed state after an instance failure. Crash recovery guarantees that when your database is opened, it will contain only transactions that were committed before the instance failure occurred. Oracle's system monitor will automatically detect whether crash recovery is required. Crash recovery has two phases: rollforward and rollback. The system monitor will first roll forward and apply to the datafiles any transactions in the online redo log files that occurred after the most recent checkpoint. Crash recovery uses Page 3 / 32
redo information found in the online redo log files only. After rolling forward, Oracle will roll back any of those transactions that were never committed. Oracle uses information stored in the undo segments to roll back (undo) any uncommitted transactions. Note DBAs often use the terms crash recovery and instance recovery interchangeably. However, Oracle defines crash recovery as either the recovery of a single instance configuration or the crash recovery of all failed instances in an Oracle Real Application Cluster (RAC) configuration, whereas instance recovery is defined to be the recovery of one failed instance by an existing live instance in a RAC configuration. When you start your database, Oracle uses the SCN information in the control files and datafile headers to determine which one of the following will occur: Starting up normally Performing crash recovery Determining that media recovery is required On start-up, Oracle checks the instance thread status to determine whether crash recovery is required. When the database is open for normal operations, the thread status is OPEN. When Oracle is shut down normally (normal, immediate, or transactional), a checkpoint takes place, and the instance thread status is set to CLOSED. When your instance abnormally terminates (such as from a shutdown abort command), the thread status remains OPEN because Oracle didn't get a chance to update the status to CLOSED. On start-up, when Oracle detects that an instance thread was abnormally left open, the system monitor process will automatically perform crash recovery. This query demonstrates how a single instance of Oracle would determine whether crash recovery is required: SELECT a.thread#, b.open_mode, a.status, CASE WHEN ((b.open_mode='mounted') AND (a.status='open')) THEN 'Crash Recovery req.' WHEN ((b.open_mode='mounted') AND (a.status='closed')) THEN 'No Crash Rec. req.' WHEN ((b.open_mode='read WRITE') AND (a.status='open')) THEN 'Inst. already open' ELSE 'huh?' END STATUS FROM v$thread a, v$database b, v$instance c WHERE a.thread# = c.thread#; Oracle will start up normally if the SCN information in the control files matches the SCNs in the corresponding datafiles. If the checkpoint SCN in the datafile is less than the corresponding SCN in the control file, Oracle will throw a media recovery error. For example, if you restored a datafile from a backup, Oracle would detect that the SCN in the datafile is less than the corresponding SCN in the control file. Therefore, a recovery is required to apply changes to the datafile to catch it up to the SCN in the control file. Table 11-1 summarizes the checks that Oracle performs to determine whether crash or media recovery is required. Table 11-1: SCN Oracle Start-up Checks Condition on Start-Up Oracle Behavior DBA Action CF checkpoint SCN < Datafile checkpoint SCN CF checkpoint SCN > Datafile checkpoint SCN The following SQL query demonstrates the internal checks that Oracle performs to determine whether media recovery is required: SELECT a.name, a.checkpoint_change#, "Control file too old" error Media recovery required (CF checkpoint SCN = Datafile SCN) Start up normally None. Database in mount mode, instance thread status = OPEN Crash recovery required Restore a newer control file. Most likely a datafile has been restored from a backup. Recovery is now required. None. Page 4 / 32
b.checkpoint_change#, CASE WHEN ((a.checkpoint_change# - b.checkpoint_change#) = 0) THEN 'Startup Normal' WHEN ((a.checkpoint_change# - b.checkpoint_change#) > 0) THEN 'Media Recovery' WHEN ((a.checkpoint_change# - b.checkpoint_change#) < 0) THEN 'Old Control File' ELSE 'what the?' END STATUS FROM v$datafile a, control file SCN for datafile v$datafile_header b datafile header SCN WHERE a.file# = b.file#; Tip The V$DATAFILE_HEADER view uses the physical datafile on disk as its source. The V$DATAFILE view uses the control file as its source. Media recovery requires that you perform manual tasks to get your database back in one piece. This usually involves a combination of restore and recover commands. You will have to issue an RMAN restore command if your datafiles have experienced media failure. This could be because of somebody accidentally deleting files or a disk failure. When you issue the restore command, RMAN will automatically determine how to extract the datafiles from any of the following available backups: Full database backup Incremental level 0 backup Image copy backup generated by the backup as copy command After the files are restored from a backup, you are required to apply redo to them via the recover command. When you issue the recover command, Oracle will examine the SCNs in the affected datafiles and determine whether any of them need to be recovered. If the SCN in the datafile is less than the corresponding SCN in the control file, then media recovery will be required. Oracle will retrieve the datafile SCN and then look for the corresponding SCN in the redo stream to determine where to start the recovery process. If the starting recovery SCN is in the online redo log files, then the archived redo log files are not required for recovery. During a recovery, RMAN will automatically determine how to apply redo. First, RMAN will apply any incremental backups available that are greater than zero, such as the incremental level 1. Next, any archived redo log files on disk will be applied. If the archived redo log files do not exist on disk, then RMAN will attempt to retrieve them from a backup set. Note An RMAN incremental backup contains copies of only those database blocks that have changed from the previous incremental backup. RMAN can more efficiently recover a datafile using an incremental backup over applying redo from an archived redo log file. This chapter guides you through several different common (and not so common) restore and recovery scenarios. Now that you understand the mechanics, you are much better prepared to determine which steps you should take to restore and recover your database. Recipe 11-1. Determining How to Restore and Recover You just experienced a media failure, and you're not sure what commands you'll need to restore and recover your database. To be able to perform a complete recovery, all of the following conditions need to be true: Your database is in archivelog mode. You have a good baseline backup of your database. Page 5 / 32
You have any required redo that has been generated since the backup (archived redo log files, online redo log files, or incremental backups that RMAN can use for recovery instead of applying redo). There are a wide variety of restore and recovery scenarios. How you restore and recover depends directly on your backup strategy and what files have been damaged. Listed next are the general steps to follow when facing a media failure: 1. Determine what files need to be restored. 2. Depending on the damage, set your database mode to nomount, mount, or open. 3. Use the restore command to retrieve files from RMAN backups. 4. Use the recover command for datafiles requiring recovery. 5. Open your database. Your particular restore and recovery scenario may not require that all of the previous steps be performed. For example, you may just want to restore your spfile, which doesn't require a recovery step. The first step in a restore and recovery process is to determine what files have experienced media failure. You can usually determine what files need to be restored from three sources: Error messages displayed on your screen, either from RMAN or SQL*Plus Alert.log file and corresponding trace files Data dictionary views Note See Chapter 20 for details on using the Data Recovery Advisor to determine how to restore and recover your database. The Data Recovery Advisor feature is new with Oracle Database 11g. Once you identify which files are damaged or missing, then you need to determine what steps to take to restore and recover. Table 11-2 contains general guidelines on what to do when presented with a media failure. You'll have to tailor these guidelines to your type of failure and then find the applicable recipe for specific instructions. Table 11-2: Where to Look for Restore and Recovery Instructions Files Needing Media Recovery Action Chapter/Recipe Datafiles with all required redo available. Datafiles without all required redo available. Complete recovery. Chapter 11 Incomplete recovery. Chapter 12 or Chapter 13 Control files. Restore control file. Chapter 10 Online redo log files. Combination of clearing and/or re-creating online redo log files and possibly performing incomplete recovery. Chapter 14 Spfile. Restore spfile. Recipe 11-15 Archived redo log files. Control file has no information about RMAN backup piece. Restore archived redo log files from another location or from RMAN backup. Use the catalog command or the DBMS_BACKUP_RESTORE package. Recipe 11-16 Recipes 11-19 and 11-20 When faced with a media failure, you need to have a good understanding of your backup strategy and how that will enable you to restore and recover your database. You should periodically test your backups so that you can confidently recover your database when faced with a media failure. When you architect your backup strategy, you should also architect a corresponding restore and recovery strategy. A sound backup strategy should minimize the risk of you losing data and minimize the downtime of your database. If you are missing any required redo or incremental backups required for recovery, then you need to see Chapter 12 for details on how to perform an incomplete recovery. You can also perform an incomplete recovery using the flashback database feature (described in Chapter 13). Page 6 / 32
If your database has experienced media failure, you'll see a fairly descriptive message when you attempt to start the database. Usually, it's obvious from the error message as to what files are experiencing problems. For example, this next error message shows that users01.dbf needs media recovery: RMAN> startup; ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01110: data file 4: 'C:\ORACLE\BRDSTN\USERS01.DBF' Tip When Oracle displays errors indicating there has been a media failure, we always recommend you look in the alert.log file for more details. There may be more than one datafile that needs to be restored and recovered, and you won't get all of that information from error messages displayed on your screen. Oracle will often just display on your screen the first file that it detects is missing or damaged. Often there will be a corresponding trace file that contains information that Oracle Support will request when helping diagnose problems. Here's an example of what type of information you'll find in the alert.log file and related trace file when you have a media failure: Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl_dbw0_5416.trc: ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01110: data file 4: 'C:\ORACLE\BRDSTN\USERS01.DBF' ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. Tip Before you restore the datafile from the RMAN backup, verify whether the missing datafile physically exists at the OS level, as well confirm that the Oracle software owner has the appropriate read and write privileges on the missing datafile and directory. We also recommend querying the data dictionary for more information. The V$DATAFILE_ HEADER view derives its information from the datafile headers and reports in the ERROR and RECOVER columns any potential problems. For example, a YES or null value in the RECOVER column indicates that you have a problem: SQL> select file#, status, error,recover from v$datafile_header; FILE# STATUS ERROR REC - - - 1 ONLINE NO 2 ONLINE NO 3 ONLINE NO 4 ONLINE FILE NOT FOUND 5 ONLINE NO The V$RECOVER_FILE reads from the control file and displays information about files needing media recovery: SQL> select file#, error from v$recover_file; FILE# ERROR - 4 FILE NOT FOUND Note If you restore a control file from a backup, the V$RECOVER_FILE view will not contain accurate information. Recipe 11-2. Previewing Backups Needed for Restore Before you perform a restore and recovery, you would like to view which backups will be required for the restore operation. Use the restore... preview command to query the RMAN repository for the most recent backup sets and corresponding files that will be used for a restore operation. Three restore... preview modes are available: Normal Page 7 / 32
Summarized Recall (MML only) Normal Mode In normal mode, you'll get a full listing of the information contained in the repository. The following example shows how to preview the restore of the system tablespace: RMAN> restore tablespace system preview; As you can see, the output from this command displays information from the repository about backup sets that RMAN will use when performing the restore operation. Note The output of the preview command is similar in format to the RMAN list command output. Starting restore at 12-OCT-06 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=145 devtype=disk List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time - - - 187 Full 843.50M DISK 00:03:10 11-OCT-06 BP Key: 187 Status: AVAILABLE Compressed: NO Tag: TAG20061011T12380 Piece Name: C:\DK61HVIRPC_1_1.BUS List of Datafiles in backup set 187 File LV Type Ckp SCN Ckp Time Name - 1 Full 4813354 11-OCT-06 C:\ORACLE\ORCL\SYSTEM01.DBF using channel ORA_DISK_1 archive logs generated after SCN 4813354 not found in repository Media recovery start SCN is 4813354 Recovery must be done beyond SCN 4813354 to clear data files fuzziness Finished restore at 12-OCT-06 The following examples show how to use the preview command with a variety of restore operations: RMAN> restore database preview; RMAN> restore database from tag TAG20060927T183743 preview; RMAN> restore datafile 1, 2, 3, 4 preview; RMAN> restore archivelog all preview; RMAN> restore archivelog from time 'sysdate - 1' preview; RMAN> restore archivelog from scn 3243256 preview; RMAN> restore archivelog from sequence 29 preview; Summarized Mode You can use the preview summary command to summarize the lengthy output. This next example shows summarized information about the backup set(s) RMAN will use to restore your entire database: RMAN> restore database preview summary; Starting restore at 12-OCT-06 using channel ORA_DISK_1 List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag - - - - - - 187 B F A DISK 11-OCT-06 1 1 NO TAG200610 archive logs generated after SCN 4813354 not found in repository Media recovery start SCN is 4813354 Recovery must be done beyond SCN 4813354 to clear data files fuzziness Finished restore at 12-OCT-06 Recall Mode If you use a media manager that supports vaulted backups, then you can use preview recall to recall media from remote storage. This next example will request that any media needed to restore the database be recalled from remote Page 8 / 32
storage. RMAN> restore database preview recall; You can use preview with any type of restore command. When you use the preview command, no datafiles are actually restored. The restore... preview command queries the repository only to report on the most recent information about what backup files will be needed for the specified restore operation. It does not check to see whether the RMAN backup files physically exist or that they are accessible. Tip If you want to verify that backup files are physically available, use the restore validate command as described in recipe 11-3. You can preview output in the normal verbose mode, or you can have it summarized. Also, if you use a media management layer (MML) that supports recalling vaulted backups, you can use the preview recall command to request media to be recalled from remote storage. Recipe 11-3. Verifying Integrity of Backups You need to perform a restore and recovery, but first you want to validate only that the backup pieces are available and structurally sound before you actually restore any datafiles. You can use either the restore... validate or validate command to verify the availability and integrity of backup pieces required by RMAN to perform the restore operation. These commands do not restore datafiles. You can additionally specify the check logical clause to instruct RMAN to check for logical corruption. Using Restore Validate The validate clause works with any restore command. Here are several examples of using restore... validate: RMAN> restore database validate; RMAN> restore database from tag MON_BCK validate; RMAN> restore datafile 1 validate; RMAN> restore archivelog all validate; RMAN> restore controlfile validate; RMAN> restore tablespace users validate; If successful, you'll see text similar to the following near the bottom of the output: channel ORA_DISK_1: validation complete, elapsed time: 00:00:45 Finished restore at 10-AUG-06 By default, RMAN checks only for physical corruption when validating. You can also instruct RMAN to check for logical corruption with the check logical clause: RMAN> restore database validate check logical; If a backup piece is missing or corrupt, the restore... validate command will automatically check for the availability of previously taken backups. Using Validate When using the validate command, you need to know the primary key of the backup set that you want to validate. First, use the list backup command to find the appropriate primary key. RMAN> list backup; Here are the relevant lines from the output: BS Key Type LV Size Device Type Elapsed Time Completion Time - - - 193 Full 129.48M DISK 00:01:05 16-AUG-06 Page 9 / 32
BP Key: 193 Status: AVAILABLE Compressed: YES Tag: TAG20061014T13291 After determining the backup set key, validate as follows: RMAN> validate backupset 193; If the validate command works, you should see a message similar to this one at the bottom of the message stack: channel ORA_DISK_1: validation complete, elapsed time: 00:00:45 If the validation process discovers a problem, it will display an error message and stop processing. By default the validate command checks only for physical corruption. Use the check logical parameter if you want the validation process to also check for logical corruption: RMAN> validate backupset 193 check logical; New in Oracle Database 11g, you can use the validate command to validate all backup pieces in the flash recovery area with the following command: RMAN> validate recovery area; We recommend that you use restore... validate on a regular basis as part of testing the viability of your backups. This command works with any type of restore operation. You can also use the validate command to verify a specific backup set. Both the restore... validate and validate commands will check to see whether the required backup piece is available and additionally whether it is free from physical corruption. The restore... validate command will also check to verify whether any required archived redo log file backup sets are available and intact. These commands do not actually restore any files. Note Physical corruption is when the block contents don't match the physical format that Oracle expects. By default, RMAN checks for physical corruption when backing up, restoring, or validating datafiles. Logical corruption is when the block is in the correct format but the contents aren't consistent with what Oracle expects. Logical corruption would be issues such as corruption in a row piece or an index entry. You can instruct RMAN to check for logical corruption with the check logical clause of the restore command. When RMAN detects logical corruption, it will write relevant error messages to your target database's alert.log file and also reflect this information in the V$DATABASE_BLOCK_CORRUPTION view. You can see whether a corrupt block is either physically or logically corrupt by querying the CORRUPTION_TYPE column of the V$DATABASE_BLOCK_CORRUPTION view. RMAN can perform block media recovery only on physically corrupt blocks. Blocks tagged with type LOGICAL corruption cannot be recovered by RMAN (through block-level recovery). To recover logically corrupt blocks, restore the datafile from a backup and perform media recovery. When you issue restore... validate, RMAN will look in the repository, get the latest backup information, and look for the relevant backup pieces. When RMAN can't find a backup piece or when RMAN detects corruption, it will then issue a "failover to previous backup" message and automatically search for a previously taken backup. RMAN will stop looking when it finds a good backup or until it has searched through all known backups without finding one. Note RMAN's behavior of searching sequentially back through backups until a good backup is found is called restore failover. Recipe 11-4. Testing Media Recovery You need to perform a database recovery, but you suspect one of your archived redo log files is bad. You want to perform a test to see whether all of the redo is available and can be applied. The recover... test command instructs Oracle to apply the redo necessary to perform recovery but does not make the changes permanent in the datafiles. When you recover in test mode, Oracle applies the required redo but rolls back the Page 10 / 32
changes at the end of the process. This example starts up the database in mount mode, restores the entire database, and then does a test recovery: RMAN> startup mount; RMAN> restore database; RMAN> recover database test; Here is a partial snippet of the output showing that the test recovery was successful: ORA-10574: Test recovery did not corrupt any data block ORA-10573: Test recover tested redo from change 847960 to 848243 ORA-10570: Test recovery complete You can test a recovery with most recover commands. Here are some examples: RMAN> recover tablespace users, tools test; RMAN> recover datafile 1 test; Note Before performing a test recovery, ensure that the datafiles being recovered are offline. Oracle will throw an ORA- 01124 error for any one line datafiles being recovered in test mode. The test command allows you to test drive the redo application process without making any permanent changes to the datafiles. Running this command is particularly useful for diagnosing problems that you're having with the application of redo during the recovery process. For example, you can use the test command with the until clause to test up to a specific trouble point: RMAN> recover database until time 'sysdate - 1/48' test; RMAN> recover database until scn 2328888 test; RMAN> recover database until sequence 343 test; Caution If you attempt to issue a recover tablespace until... test, RMAN will attempt to perform a tablespace point-in-time recovery (TSPITR). If you're missing archived redo log files or online redo log files that are needed for recovery, you'll receive a message similar to this: ORA-06053: unable to perform media recovery because of missing log If you can't locate the missing redo, then you'll most likely have to perform incomplete recovery. See Chapter 12 for details on how to perform an incomplete recovery. Allowing Corruption In Oracle Database 10g and lower, the syntax recover... test allow n corruption does not work from within RMAN. If you want to run the test command with the allow n corruption clause, then you must issue that command from inside SQL*Plus, as shown here: SQL> connect sys/muft as sysdba SQL> recover tablespace system test allow 5 corruption; When using the recover... test allow n corruption command, you can specify integers greater than 1 for n. If you are using recover... allow n corruption (and not using the test command), then n can be 1 only. Recipe 11-5. Performing Database-Level Recovery You've lost all of your datafiles but still have your online redo log files. You want to perform complete recovery. Page 11 / 32
You can perform a complete database-level recovery in this situation with either the current control file or a backup control file. Use Current Control File You must first put your database in mount mode to perform a database-wide restore and recovery. This is because the system tablespace datafile(s) must be offline when being restored and recovered. Oracle won't allow you to operate your database in open mode with the system datafile offline. In this situation, we simply start up the database in mount mode, issue the restore and recover commands, and then open the database: RMAN> startup mount; RMAN> restore database; RMAN> recover database; RMAN> alter database open; If everything went as expected, the last message you should see is this: database opened Use Backup Control File This solution uses an autobackup of the control file retrieved from the flash recovery area. If you're using a different strategy to back up your control file, then see Chapter 10 for details on restoring your control file. In this example, we first restore the control file before issuing the restore and recover database commands: RMAN> startup nomount; RMAN> restore controlfile from autobackup; RMAN> alter database mount; RMAN> restore database; RMAN> recover database; RMAN> alter database open resetlogs; If everything went as expected, the last message you should see is this: database opened Note You are required to open your database with the open resetlogs command anytime you use a backup control file during a recovery operation. The restore database command will restore every datafile in your database. The exception to this is when RMAN detects that datafiles have already been restored, then it will not restore them again. If you want to override that behavior, then use the force command as explained in recipe 11-12. When you issue the recover database command, RMAN will automatically apply redo to any datafiles that need recovery. The recovery process includes applying changes found in the following: Incremental backup pieces (applicable only if using incremental backups) Archived redo log files (generated since the last backup or last incremental backup that is applied) Online redo log files (current and unarchived) You can open your database after the restore and recovery process is complete. If you restore from a backup control file, you are required to open your database with the open resetlogs command. Complete database recovery works only if you have good backups of your database and have access to all redo generated after the backup was taken. You need all the redo required to recover the database datafiles. If you don't have all the required redo, then you'll most likely have to perform an incomplete recovery. See Chapter 12 for details on performing an incomplete recovery. Page 12 / 32
Note Your database has to be at least mounted to restore datafiles using RMAN. This is because RMAN reads information from the control file during the restore and recovery process. Recipe 11-6. Performing Tablespace-Level Recovery You're seeing a media error associated with several datafiles contained in one tablespace. You want to perform complete recovery on all datafiles associated with that problem tablespace. Use the restore tablespace and recover tablespace commands to restore and recover all the datafiles associated with a tablespace. You can either place the database in mount mode or have the database open. In the first scenario, we'll place the database in mount mode for the restore and recovery. Recover While Database Not Open This solution works for any tablespace in your database. In this example, we restore the user_data and user_index tablespaces: RMAN> startup mount; RMAN> restore tablespace user_data, user_index; RMAN> recover tablespace user_data, user_index; RMAN> alter database open; If everything was successful, the last message you should see is this: database opened Recover While Database Is Open You can take a tablespace offline, restore, and recover it while your database is open. This works for any tablespace except the system and undo tablespaces. This example takes data_ts offline and then restores and recovers before bringing it back online: RMAN> sql 'alter tablespace data_ts offline immediate'; RMAN> restore tablespace data_ts; RMAN> recover tablespace data_ts; RMAN> sql 'alter tablespace data_ts online'; After the tablespace is brought online, you should see a message similar to this: sql statement: alter tablespace data_ts online The RMAN restore tablespace and recover tablespace commands will restore and recover all datafiles associated with the specified tablespace(s). It's appropriate to perform this type of complete recovery when you only have datafiles from a tablespace or set of tablespaces missing. If your database is open, then all datafiles in the tablespace(s) being recovered must be offline. Recipe 11-7. Performing Datafile-Level Recovery You have one datafile that has experienced media failure. You don't want to restore and recover the entire database or all datafiles associated with the tablespace. You just want to restore and recover the datafile that experienced media failure. Use the restore datafile and recover datafile commands to restore and recover one or more datafiles. The database can be mounted or open to restore datafiles. Page 13 / 32
Recover While Database Not Open In this scenario we mount the database and then restore and recover the missing datafile. You can restore and recover any datafile in your database while the database is not open. This example shows restoring the datafile 1, which is associated to the system tablespace: RMAN> startup mount; RMAN> restore datafile 1; RMAN> recover datafile 1; RMAN> alter database open; You can also specify the filename when performing a datafile recovery: RMAN> startup mount; RMAN> restore datafile '/ora01/brdstn/system_01.dbf'; RMAN> recover datafile '/ora01/brdstn/system_01.dbf'; RMAN> alter database open; Recover While Database Open For nonsystem and non-undo datafiles, you have the option of keeping the database open while performing the recovery. When your database is open, you're required to take offline any datafiles you're attempting to restore and recover. RMAN> sql 'alter database datafile 3, 4 offline'; RMAN> restore datafile 3, 4; RMAN> recover datafile 3, 4; RMAN> sql 'alter database datafile 3, 4 online'; Tip Use the RMAN report schema command to list datafile names and file numbers. You can also query the NAME and FILE# columns of V$DATAFILE to take names and numbers. You can also specify the name of the datafile that you want to restore and recover: RMAN> sql "alter database datafile ''/ora01/brdstn/data_ts01.dbf'' offline"; RMAN> restore datafile '/ora01/brdstn/data_ts01.dbf'; RMAN> recover datafile '/ora01/brdstn/data_ts01.dbf'; RMAN> sql "alter datafile ''/ora01/brdstn/data_ts01.dbf'' online"; Note When using the RMAN sql command, if there are single quote marks within the SQL statement, then you are required to use double quotes to enclose the entire SQL statement and then also use two single quote marks where you would ordinarily just use one quote mark. A datafile-level restore and recovery works well when you want to specify which datafiles you want recovered. With datafile-level recoveries, you can use either the datafile number or the datafile name. For nonsystem and non-undo datafiles, you have the option of restoring and recovering while the database is open. While the database is open, you have to first take offline any datafiles being restored and recovered. Recipe 11-8. Restoring Datafiles to Nondefault Locations You've just experienced a serious media failure and won't be able to restore datafiles to their original locations. In other words, you need to restore datafiles to a nondefault location. Use the set newname and switch commands to restore datafiles to nondefault locations. Both of these commands must be run from within an RMAN run{} block. This example changes the location of datafiles 4 and 5, which are in the data_ts tablespace: Page 14 / 32
RMAN> startup mount; RMAN> run{ 2> set newname for datafile 4 to '/ora01/brdstn/data_ts01.dbf'; 3> set newname for datafile 5 to '/ora01/brdstn/data_ts02.dbf'; 4> restore tablespace data_ts; 5> switch datafile all; # Updates repository with new datafile location. 6> recover tablespace data_ts; 7> alter database open; 8> } This is a partial listing of the output: Starting recover at 08-FEB-07 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:37 Finished recover at 08-FEB-07 database opened If the database is open, you can place the datafiles offline and then set their new names for restore and recovery: RMAN> run{ 2> sql 'alter database datafile 4, 5 offline'; 3> set newname for datafile 4 to '/ora01/brdstn/data_ts01.dbf'; 4> set newname for datafile 5 to '/ora01/brdstn/data_ts02.dbf'; 5> restore datafile 4, 5; 5> switch datafile all; # Updates repository with new datafile location. 6> recover datafile 4, 5; 7> sql 'alter database datafile 4, 5 online'; 8> } You should now see a message similar to the following: starting media recovery media recovery complete, elapsed time: 00:00:57 Finished recover at 08-FEB-07 sql statement: alter database datafile 4, 5 online Tip Use the RMAN report schema command to list datafile names and file numbers. You can also query the NAME and FILE# columns of V$DATAFILE to take names and numbers. You can also use datafile names instead of numbers. However, you have to be careful about which name you use and where it comes in the script. This is because the control file doesn't consider the new location to be the current location until you issue the switch command. RMAN> run{ 2> sql "alter database datafile ''/ora02/brdstn/data_ts01.dbf'' offline'; 3> set newname for datafile '/ora02/brdstn/data_ts01.dbf' 4> to '/ora01/brdstn/data_ts01.dbf'; 5> restore datafile '/ora02/brdstn/data_ts01.dbf'; 6> switch datafile all; # Updates repository with new datafile location. 7> recover datafile '/ora01/brdstn/data_ts01.dbf'; 8> sql "alter database datafile ''/ora01/brdstn/data_ts01.dbf'' online"; 9> } Tip When using the RMAN sql command, if there are single quote marks in the SQL command, then you are required to use double quotes to enclose the entire SQL statement and use two single quote marks where you would ordinarily use just one quote mark. You can use a combination of the set newname and switch commands to restore and recover a datafile to a nondefault location. You must run the set newname command and the switch command from within a run{} block. The switch command updates the target database control file with the new location of the datafile. It's OK to use switch Page 15 / 32
datafile all, which updates all datafile locations. The only datafile names that will actually change are the ones that you have specified. Alternatively, you can use switch datafile <number> to update the repository with a specific datafile number. Note If you don't run the switch command, then RMAN marks the restored datafile to be a valid datafile copy that can be used for subsequent restore operations. Recipe 11-9. Performing Block-Level Recovery When performing daily backups, you notice that RMAN is reporting in your target database alert.log file that there is a corrupt block in a large datafile. It could take a significant amount of time to perform the traditional restore and recover of a large datafile. You wonder whether there is a method for just recovering the corrupt block and not the entire datafile. If you're using Oracle Database 11g or newer, use the recover datafile... block command to recover individual blocks within a datafile. Note If you're using Oracle Database 10g or Oracle9i Database, then use the blockrecover command to perform block media recovery. The block recovery examples in this recipe use the recover command. You can substitute the blockrecover command for the recover command in the examples in this recipe if you're using Oracle Database 10g or Oracle9i Database. You can instruct RMAN to recover blocks in two ways: Use the corruption list clause. Specify individual datafiles and blocks. When RMAN detects corrupt blocks, it writes an error to the alert.log file and also populates the V$DATABASE_BLOCK_CORRUPTION view. You can instruct RMAN to recover the blocks listed as corrupt in that view as follows: RMAN> recover corruption list; The other way to recover blocks is to specify particular datafiles and blocks. Here are several examples: RMAN> recover datafile 5 block 24; RMAN> recover datafile 7 block 22 datafile 8 block 43; RMAN> recover datafile 5 block 24 from tag=tues_backup; RMAN> recover datafile 6 block 89 restore until sequence 546; RMAN> recover datafile 5 block 32 restore until 'sysdate-1'; RMAN> recover datafile 5 block 65 restore until scn 23453; If you attempt to use the recover command on a datafile that RMAN does not know about, you'll receive an error similar to this: RMAN-06023: no backup or copy of datafile 6 found to restore If you have a user-managed backup of the datafile that you've taken outside RMAN, you can use the catalog datafilecopy command to create metadata about the file in the RMAN repository, as shown here: RMAN> catalog datafilecopy '/orabackups/brdstn/index_ts01.dbf'; If all the required redo (online or archived) is available, you can now issue the recover command, as shown here: RMAN> recover datafile 6 block 25; Block-level corruption is rare and is usually caused by some sort of I/O error. However, if you do have an isolated corrupt block within a large datafile, it's nice to have the option of performing a block-level recovery. Block-level recovery is useful when a small number of blocks are corrupt within a datafile. Block recovery is not appropriate if the entire datafile needs media recovery. Page 16 / 32
RMAN will automatically detect corruption in blocks whenever a backup or backup validate command is issued. These blocks are reported as corrupt in the alert.log file and the V$DATABASE_BLOCK_CORRUPTION view. Here are the various locations that Oracle will record block-level corruption: RMAN backup populates V$DATABASE_BLOCK_CORRUPTION. Trace files. Alert.log file. Output of dbverify utility. Output of SQL analyze... validate structure command. V$BACKUP_CORRUPTION and V$COPY_CORRUPTION will list corrupt blocks in backup piece files. Your database can be either mounted or open when performing block-level recovery. You do not have to take the datafile being recovered offline. Block-level media recovery allows you to keep your database available and also reduces the mean time to recovery since only the corrupt blocks are offline during the recovery. Note RMAN cannot perform block-level recovery on block 1 (datafile header) of the datafile. Your database must be in archivelog mode for performing block-level recoveries. In Oracle Database 11g, RMAN can restore the block from the flashback logs (if available). If the flashback logs are not available, then RMAN will attempt to restore the block from a full backup, a level 0 backup, or an image copy backup generated by backup as copy command. After the block has been restored, any required archived redo logs must be available to recover the block. RMAN can't perform block media recovery using incremental level 1 (or higher) backups. Creating and Fixing Block Corruption The purpose of this sidebar is to show you how to corrupt a block so that you can test recovering at the block level. Do not perform this test exercise in a production environment. In a Unix environment, you can corrupt a specific block in a datafile using the dd command. For example, the following dd command populates the 20th block of the tools01.dbf datafile with zeros: $ dd if=/dev/zero of=tools01.dbf bs=8k conv=notrunc seek=20 count=1 Now if we attempt to back up the tools tablespace using RMAN, we receive an error indicating there is a corrupt block: RMAN> backup tablespace tools; RMAN-03009: failure of backup command on ORA_DISK_1 channel ORA-19566: exceeded limit of 0 corrupt blocks for file /ora01/brdstn/tools01.dbf We additionally use the dbverify utility to validate that the tools01.dbf datafile has a corrupt block: $ dbv file=/ora01/brdstn/tools01.dbf blocksize=8192 Here is the partial output of the dbverify command: DBVERIFY - Verification starting : FILE = tools01.dbf Page 20 is marked corrupt Corrupt block relative dba: 0x01400014 (file 5, block 20) The dbverify utility indicates that block 20 in file 5 is corrupt. We can corroborate this by viewing the contents of V$DATABASE_BLOCK_CORRUPTION, as shown here: SQL> select * from v$database_block_corruption; FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO - 5 20 1 0 ALL ZERO We can now use the RMAN recover command to restore block 20 in datafile 5, as shown here (if you're using Oracle Database 10g or Oracle9i, then use the RMAN blockrecover command): Page 17 / 32
RMAN> recover datafile 5 block 20; Recipe 11-10. Recovering Read-Only Tablespaces You issued a restore database command and notice that the datafiles associated with readonly tablespaces were not restored. Use the check readonly command to instruct RMAN to restore datafiles associated with readonly tablespaces. RMAN> startup mount; RMAN> restore database check readonly; RMAN> recover database; RMAN> alter database open; Another alternative is to explicitly restore the read-only tablespaces after you have restored the regular datafiles. In this example, two read-only tablespaces are restored after the entire database has been restored: RMAN> startup mount; RMAN> restore database; RMAN> restore tablespace MAR05DATA, JUN05DATA; RMAN> recover database; RMAN> alter database open; By default, the restore command skips datafiles associated with read-only tablespaces. If you want read-only tablespaces restored, then you must use the check readonly command or explicitly restore each read-only tablespace. Note If you are using a backup that was created after the read-only tablespace was placed into read-only mode, then no recovery is necessary for the read-only datafiles. In this situation, there is no redo that has been generated for the read-only tablespace since it was backed up. Recipe 11-11. Restoring Temporary Tablespaces RMAN doesn't back up locally managed temporary tablespace tempfiles, and you want to ensure that they're restored as part of your backup strategy. Starting with Oracle Database 10g, you don't have to restore or re-create missing locally managed temporary tablespace tempfiles. When you open your database for use, Oracle automatically detects and re-creates locally managed temporary tablespace tempfiles. When Oracle automatically re-creates a temporary tablespace, it will log a message to your target database alert.log file similar to the following: Re-creating tempfile <your temporary tablespace filename> When you open your database, Oracle will check to see whether any locally managed temporary tablespace tempfiles are missing. If Oracle detects missing temporary tempfiles, it will automatically re-create them using information from the control files. Note Oracle's feature of automatically re-creating temporary tablespace tempfiles applies only to missing locally managed temporary tablespace tempfiles. This feature does not apply to a dictionary-managed temporary Page 18 / 32
If for any reason your temporary tablespace becomes unavailable, you can also re-create it yourself. Since there are never any permanent objects in temporary tablespaces, you can simply re-create them as needed. Here is an example of how to create a locally managed temporary tablespace: SQL> CREATE TEMPORARY TABLESPACE temp TEMPFILE 2 '/ora03/oradata/brdstn/temp01.dbf' SIZE 5000M REUSE 3 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K; If your temporary tablespace exists but the temporary datafiles are missing, you can simply add the temporary datafile(s) as shown here: SQL> alter tablespace temp 2 add tempfile '/ora03/oradata/brdstn/temp01.dbf' SIZE 5000M REUSE; Recipe 11-12. Forcing RMAN to Restore a File As part of a test exercise, you attempt to restore a datafile twice and receive this RMAN message: restore not done; all files readonly, offline, or already restored In this situation, you want to force RMAN to restore the datafile again. Use the force command to restore datafiles and archived redo log files even if they already exist in a location. This command forces RMAN to restore files, even if RMAN determines that they don't need to be restored. This first example uses the force to restore the obiwan01.dbf datafile: RMAN> restore datafile '/ora01/yoda/obiwan01.dbf' force; You should see a message similar to this at the bottom of your RMAN messages stack: channel ORA_DISK_1: restore complete, elapsed time: 00:00:15 Finished restore at 09-FEB-07 Or if you know the particular datafile number, you can use the force command this way: RMAN> restore datafile 42 force; Similarly, you can use the force command on a tablespace. Here we use the force command to restore all datafiles associated with the star_wars tablespace: RMAN> restore tablespace star_wars force; To force RMAN to restore all datafiles in the database, issue this command: RMAN> restore database force; By default, RMAN won't restore archived redo log files if they already exist on disk. You can override this behavior as follows: RMAN> restore archivelog from sequence 343 force; By default, RMAN will not restore a datafile that is in the correct location and contains the expected information in the datafile header. This is known as restore optimization. To override RMAN's default behavior, use the power of the force command. The force command works with any restore command. Recipe 11-13. Restoring from an Older Backup You want to specifically instruct RMAN to restore from a backup set that is older than the last backup that was taken. tablespace. Page 19 / 32
You can restore an older backup a couple of different ways: using a tag name or using the restore... until command. Specify a Tag Name Use the list backup to find the tag name of the backup set. Every backup set has a tag name, either the default or one you specified. For example, here's the partial output of a list backup command that shows the desired tag name: BP Key: 159 Status: AVAILABLE Compressed: NO Tag: MON_BACK Once you've identified the tag, you can instruct RMAN to use that as follows: RMAN> startup mount; RMAN> restore database from tag MON_BACK; RMAN> recover database; RMAN> alter database open; You can also use a tag to restore specific tablespaces or datafiles as follows: RMAN> restore tablespace users from tag INCUPDATE; RMAN> restore datafile 2, 3 from tag AUG_FULL; Using Restore Until You can also tell RMAN to restore datafiles from a point in the past using the until clause of the restore command in one of the following ways: Until SCN Until sequence Until restore point Until time Caution This recipe uses the restore... until command with the recover command to perform complete recovery. If you need to perform an incomplete recovery, then you will need to use the recover... until command (not just the recover command by itself). See Chapter 12 for details on incomplete recoveries using recover until in conjunction with the restore... until command. If you know the SCN in a backup piece that you want to restore from, you can specify the SCN as follows: RMAN> startup mount; RMAN> restore database until SCN 1254174; RMAN> recover database; RMAN> alter database open; Or if you know the log sequence number that you want to restore up to, the syntax is as follows: RMAN> startup mount; RMAN> restore database until sequence 17; RMAN> recover database; RMAN> alter database open; If you've created restore points, then you can also use the restore point name as follows: RMAN> startup mount; RMAN> restore database until restore point FRI_RS; RMAN> recover database; RMAN> alter database open; You can also specify a point in time from which you want RMAN to restore an older backup. This example instructs RMAN to retrieve the first backup it finds that is more than 10 days old: RMAN> startup mount; RMAN> restore database until time 'sysdate - 10'; RMAN> recover database; RMAN> alter database open; Here we're specifically instructing RMAN to restore from a date and time. Since we don't instruct RMAN to recover to a Page 20 / 32
point in time, this example will perform a complete recovery: RMAN> startup mount; RMAN> restore database until time 2> "to_date('05-oct-2006 14:00:00', dd-mon-rrrr hh24:mi:ss')"; RMAN> recover database; RMAN> alter database open; You can easily instruct RMAN to restore from backups older than the most recent backup set. You can do this by specifying a tag or using the restore... until command. In versions prior to Oracle Database 10g, this was the only way you could instruct RMAN to restore from a backup older than the most recent one recorded in the repository. New with Oracle Database 10g, by default RMAN will look in older backups if it can't find a backup piece or if corruption is detected. RMAN will search through backup history until it locates a good backup or until it exhausts all possibilities. This feature is called restore failover. In this example, RMAN cannot find the expected backup piece and automatically searches for a prior backup. Here is the backup operation and its corresponding partial output indicating that RMAN is initiating a restore failover: RMAN> restore database; ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot the file specified. failover to previous backup Recipe 11-14. Recovering Through Resetlogs You recently performed an incomplete recovery that required you to open your database with the open resetlogs command. Before you could back up your database, you experienced another media failure. Prior to Oracle Database 10g, it was extremely difficult to recover using a backup of a previous incarnation of your database. You now wonder whether you can get your database back in one piece. Beginning with Oracle Database 10g, you can restore a backup from a previous incarnation and recover through a resetlogs command. You simply need to restore and recover your database as required by the type of failure. In this example, the control files and all datafiles are restored: RMAN> startup nomount; RMAN> restore controlfile from autobackup; RMAN> alter database mount; RMAN> restore database; RMAN> recover database; RMAN> alter database open resetlogs; When you issue the recover command, you should see redo being applied from the previous incarnation of the database and then the current incarnation. In this example, the previous incarnation has logs 77 through 79, and the current incarnation has logs 1 and 2: archive log filename thread=1 sequence=77 archive log filename thread=1 sequence=78 archive log filename thread=1 sequence=79 archive log filename thread=1 sequence=1 archive log filename thread=1 sequence=2 Anytime you perform an incomplete recovery or recover with a backup control file, you are required to open your database with an open resetlogs command. Prior to Oracle Database 10g, you were required to take a backup of your database immediately after you reset the online redo log files. This is because resetting the online redo log files creates a new Page 21 / 32
incarnation of your database and resets your log sequence number back to 1. Any backups taken before resetting the logs could not be easily used to restore and recover your database. Starting with Oracle Database 10g, there is a new feature known as simplified recovery through resetlogs. This feature allows you to restore from a backup from a previous incarnation of your database and issue restore and recovery commands as applicable to the type of failure that has occurred. Oracle keeps track of log files from all incarnations of your database. The V$LOG_HISTORY view is no longer cleared out during a resetlogs operation and contains information for the current incarnation as well as any previous incarnations. The default format of the archived redo log files is now arch_%r_%t_%s.arc. The format character %R is a resetlogs identifier that ensures that unique names are used for the archived redo log files across different database incarnations. You can view the incarnation of your database using the list incarnation command: RMAN> list incarnation; using target database control file instead of recovery catalog List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time - - - 1 1 ORCL 1109210542 PARENT 3605284 25-AUG-06 2 2 ORCL 1109210542 PARENT 7349364 07-FEB-07 3 3 ORCL 1109210542 CURRENT 7652413 08-FEB-07 Note The simplified recovery through resetlogs feature works both with RMAN and with user-managed recoveries. Recipe 11-15. Restoring the Spfile You might need to restore the spfile for one of several reasons: You accidentally deleted your server parameter file. You want to view an old copy of the spfile. You can't start your instance with the current spfile. First you need to have enabled the autobackup of your control file. For details on enabling the autobackup of your control file, see recipe 5-4. Once autobackup of your control file is enabled, then you can restore your spfile from an autobackup. All of the following examples assume that there is not an spfile located in the default location. The approach varies slightly depending on whether you're using a recovery catalog, using a flash recovery area, or using default locations for backups of the spfile. Note If you can't start your instance with the current spfile, first rename or move your spfile and then restore the spfile from a backup. Using a Recovery Catalog If you're using a recovery catalog, then restoring the spfile is fairly straightforward. This example connects to the recovery catalog and then restores the spfile: RMAN> connect catalog rmancat/rmancat@rcat RMAN> startup nomount; starting Oracle instance without parameter file for retrieval of spfile RMAN> restore spfile; RMAN> startup force; # startup using restored spfile Not Using a Recovery Catalog, RMAN Autobackup in Default Location If you aren't using a recovery catalog, then you need to know your database identifier before you can proceed. See recipe 10-3 for details about determining your DBID. Page 22 / 32
This recipe assumes that you have configured your autobackups of the spfile to go to the default location. The default location depends on your operating system. For Unix, the default location is ORACLE_HOME/dbs. On Windows systems, it's ORACLE_HOME\database or ORACLE_HOME\dbs. RMAN> shutdown immediate; RMAN> startup force nomount; # start instance for retrieval of spfile RMAN> set dbid 260150593; RMAN> restore spfile from autobackup; RMAN> startup force; # startup using restored spfile You should now see your instance start normally: Oracle instance started database mounted database opened When the autobackup is located in the default location, you can use the parameters maxseq and maxdays to alter the default behavior of RMAN. These parameters also apply to control file restores from the default location. See recipe 10-4 for examples on how to use maxseq and maxdays. Not Using a Recovery Catalog, RMAN Autobackup Not in Default Location If you're either using a flash recovery area (FRA) or have the autobackup of your control file configured to a nondefault location, then the spfile will not be backed up to what Oracle calls the default location. In these situations, you have to specifically tell RMAN where to retrieve the backup from. If you're using a FRA, your spfiles will be backed up in an autobackup directory in your flash recovery area. You'll have to find that directory and backup piece name before you can restore your spfile. You'll also need to know your database identifier before you can proceed. See recipe 10-3 for determining your DBID. Once you know your DBID, you can restore the spfile as follows: RMAN> shutdown immediate; RMAN> set dbid 260150593; RMAN> startup force nomount; # start instance for retrieval of spfile RMAN> restore spfile from '/ora02/fra/brdstn/autobackup/2006_10_02/o1_mf_s_62.bkp'; RMAN> startup force; # startup using restored spfile You should now see your instance start normally: Oracle instance started database mounted database opened If you're using an spfile, then you can have it automatically backed up for you by enabling the autobackup of the control file. If you're using a recovery catalog, restoring the spfile is simple. The recovery catalog maintains information about what backup piece contains the latest copy of the spfile. If the autobackups have been configured to create a backup piece in the default location, then you need to set the DBID and issue the restore from autobackup command. When the autobackup is in the default location, you can also use the values maxseq and maxdays to direct RMAN to look at specific ranges of backup files. If you're not using a recovery catalog and the autobackups are created either in the FRA or in a nondefault location, then you will specifically set your DBID and tell RMAN where the backup files are located. This is because when you start your database in nomount mode and if it doesn't have access to a parameter file, there is no way for RMAN to know where the FRA is located. If RMAN doesn't know where the FRA is located, then there is no way for it to determine where the autobackups are stored. Recipe 11-16. Restoring Archived Redo Log Files RMAN will automatically restore any archived redo log files that it needs during a recovery process. You almost never need Page 23 / 32
to manually restore archived redo log files. However, you may want to manually restore the archived redo log files if any of the following situations apply: You want to restore archived redo log files in anticipation of later performing a recovery; the idea is that if the archived redo log files are already restored, this will speed up the recovery operation. You need to restore the archived redo log files to a nondefault location, either because of media failure or because of storage space issues. You need to restore specific archived redo log files because you want to inspect them via LogMiner. This recipe is divided into two sections: restoring to the default location and restoring to a nondefault location. Restoring to Default Location The following command will restore all archived redo log files that RMAN has backed up: RMAN> restore archivelog all; If you want to restore from a specified sequence, use the from sequence clause. This example restores all archived redo log files from sequence 50: RMAN> restore archivelog from sequence 50; If you want to restore a range of archived redo log files, use the from sequence and until sequence clauses or the sequence between clause, as shown here. These commands restore archived redo log files from sequence 5170 through 5178 using thread 1. RMAN> restore archivelog from sequence 5170 until sequence 5178 thread 1; RMAN> restore archivelog sequence between 5170 and 5178 thread 1; By default, RMAN won't restore an archived redo log file if it is already on disk. You can override this behavior via the force option: RMAN> restore archivelog from sequence 1 force; Restoring to Nondefault Location Use the set archivelog destination clause if you want to restore archived redo log files to a different location than the default. The following example restores to the nondefault location of /ora01/archrest. The set command must be run from within the RMAN run{} block. RMAN> run{ 2> set archivelog destination to '/ora01/archrest'; 3> restore archivelog from sequence 5200; 4> } If you've enabled a flash recovery area, then RMAN will by default restore archived redo log files to the destination defined by the initialization parameter db_recovery_file_dest. Otherwise, RMAN uses the log_archive_dest_1 initialization parameter to determine where to restore the archived redo log files. If you restore archived redo log files to a nondefault location, RMAN knows the location they were restored to and automatically finds these files when you issue any subsequent recover commands. RMAN will not restore archived redo log files that it determines are already on disk. Even if you specify a nondefault location, RMAN will not restore an archived redo log file to disk if it already exists. In this situation, RMAN will simply return a message stating that the archived redo log file has already been restored. Use the force command to override this behavior. If you are uncertain of the sequence numbers to use during a restore of log files, you can query the V$LOG_HISTORY view or issue an RMAN list backup command for more information. Note When restoring archived redo log files, your database can be either mounted or open. Recipe 11-17. Recovering Datafiles Not Backed Up Page 24 / 32
You recently added a datafile to a tablespace and had a failure before the datafile was backed up. You wonder how you're going to restore and recover a datafile that was never backed up. For this solution to work, you need to have a good baseline backup of your database and any subsequently generated redo up to the point where the datafile was created. If you have your current control file, then you can restore and recover at the datafile, tablespace, or database level. If you're using a backup control file that has no information about the datafile, then you must restore and recover at the database level. Note In Oracle9i Database and previous releases, the DBA had to perform some manual steps to restore a datafile not backed up yet. This usually involved re-creating the missing datafile and then restarting the recovery process. Using a Current Control File In this example, we use the current control file and are recovering the user_idx01.dbf datafile in the user_idx tablespace: RMAN> startup mount; RMAN> restore tablespace user_idx; You should see a message like the following in the output as RMAN re-creates the datafile: creating datafile fno=5 name=/ora01/oradata/brdstn/user_idx01.dbf Now issue the recover command and open the database: RMAN> recover tablespace user_idx; RMAN> alter database open; Using a Backup Control File This scenario is applicable anytime you use a backup control file to restore and recover a datafile that has not yet been backed up. First, we restore a control file from an older backup: RMAN> startup nomount; RMAN> restore controlfile from '/orafra/brdstn/autobackup/2006_10_11/01_mfn_.bkp'; When the control file has no record of the datafile, RMAN will throw an error if you attempt to recover at the tablespace or datafile level. In this situation, you must use the restore database and recover database commands as follows: RMAN> startup mount; RMAN> restore database; RMAN> recover database; Next, you should see quite a bit of RMAN output. Near the end of the output you should see a line similar to this indicating that the datafile has been re-created: creating datafile fno=9 name=/ora02/brdstn/data_ts06.dbf Since you restored using a backup control file, you are required to open the database with the resetlogs command: RMAN> alter database open resetlogs; Starting with Oracle Database 10g, there is enough information in the redo stream for RMAN to automatically re-create a datafile that was never backed up. It doesn't matter whether the control file has a record of the datafile. It doesn't matter whether the datafile was added as part of a create database datafile command or a create tablespace command. Prior to Oracle Database10g, manual intervention from the DBA was required to recover a datafile that had not been backed up yet. If Oracle identified that a datafile was missing that had not been backed up, the recovery process would halt, and you would have to identify the missing datafile and re-create it. After re-creating the missing datafile, you had to manually restart the recovery session. Page 25 / 32
In Oracle Database 10g and newer, this is no longer the case. RMAN automatically detects that there isn't a backup of a datafile being restored and re-creates the datafile from information retrieved from the control file and/or redo information as part of the restore and recovery operations. Recipe 11-18. Deleting Archived Redo Log Files During Recovery You know that you're going to be applying many archived redo log files during a recovery process. You want RMAN to automatically delete the archived redo logs after they're applied. Use the recover... delete archivelog command as shown here: RMAN> recover database delete archivelog; You should see a message like the following in the output after RMAN successfully applied an archived redo log: archived log file name=/usr/oracle/flash_recovery_area/db11g/archivelog /2007_04_20/o1_mf_1_740_32jmotgx_.arc thread=1 sequence=740 channel default: deleting archived log(s) archived log file name=/usr/oracle/flash_recovery_area/db11g/archivelog /2007_04_20/o1_mf_1_740_32jmotgx_.arc RECID=1724 STAMP=620357134 If you know you're going to restore and apply many archived redo log files, then you can use the delete archivelog clause of the recover command. This will cause RMAN to automatically remove any archived redo log files that have been applied and are not needed for recovery any longer. RMAN will not delete any archived redo log files that were already on disk at the time the recover command was issued. Note If your archived redo log files are restored to a flash recovery area, then RMAN will automatically enable the delete archivelog feature. You can also instruct RMAN to use a specified amount of space for keeping restored archived redo logs on disk. For example, if you want RMAN to use at most 500MB disk space for restored archived redo log files, then you would specify that maximum size, as shown here: RMAN> recover database delete archivelog maxsize 500m; If you don't specify a maximum size, then RMAN deletes archived redo log files after they are applied. If you do specify a maximum size, then be careful not to specify a size smaller than your largest archived redo log file. RMAN will throw an error if it encounters an archived redo log file smaller than the specified maximum size and halt the restore process, as shown here: RMAN-06557: unable to restore archived log thread 1, sequence 361 RMAN-06558: archived log size of 7546 kb is bigger than available space of 5120 kb Recipe 11-19. Restoring from Uncataloged Backup Pieces in Oracle Database 10g and Newer You had to re-create your control file and you are not using a recovery catalog. Afterward, you attempted to restore datafiles using RMAN but received the following errors: RMAN-06026: some targets not found - aborting restore RMAN-06023: no backup or copy of datafile 10 found to restore RMAN-06023: no backup or copy of datafile 5 found to restore RMAN-06023: no backup or copy of datafile 3 found to restore RMAN-06023: no backup or copy of datafile 2 found to restore RMAN-06023: no backup or copy of datafile 1 found to restore You want to restore control files, datafiles, and archived redo logs from RMAN backup pieces, but your control file now contains no information whatsoever about previously taken backups. Page 26 / 32
Use the catalog command to add RMAN metadata directly to your control file about backup pieces. Using a Flash Recovery Area You can have RMAN repopulate the control file with all file information in the flash recovery. The following command will catalog all backup sets, datafile copies, and archived redo log files located in the flash recovery area: RMAN> catalog recovery area; Using a Directory You can also instruct RMAN to catalog all the backup pieces and image copies located under a starting directory path. This example instructs RMAN to record metadata in the repository for any backup pieces and image copies located under the /oradump01/fra directory: RMAN> catalog start with '/oradump01/fra'; Using a Backup Piece For a backup set to be usable, you must catalog all backup pieces in the backup set. In this example, there is only one backup piece in the backup set: RMAN> catalog backuppiece 2> 'C:\FRA\ORCL\BACKUPSET\2007_01_03\O1_MF_NNNDF_TAG20070103T160632_2SRFQSG2_.BKP'; This writes metadata information about that backup piece into the control file. If successful, you should see output similar to this: cataloged backuppiece backup piece handle=c:\fra\orcl\backupset\ 2007_01_03\O1_MF_NNNDF_TAG20070103T160632_2SRFQSG2_.BKP recid=2 stamp=610911396 New with Oracle Database 10g, you can now add metadata about backup pieces directly to your control file via the catalog command. If you're not using a recovery catalog, this can be particularly useful if you ever have to re-create your control file. This is because when re-creating the control file, all of your RMAN information is wiped out. You can use the catalog command to add the following types of information to your control file: Backup pieces Archived redo log files Control file copies Datafile copies Files in the flash recovery area If you're using a database version prior to Oracle Database 10g, then see recipe 11-20 on how to use DBMS_BACKUP_RESTORE to extract files from backup pieces for which your control file has no information. Note You cannot use the catalog command for backup pieces on a tape device. Recipe 11-20. Restoring from Uncataloged Backup Pieces in Oracle9i Database and Older You had to re-create your control file, and you are not using a recovery catalog. You want to restore control files, datafiles, and archived redo logs from RMAN backup pieces, but your control file now contains no information whatsoever about previously taken backups. Note If you are using Oracle Database 10g or newer, we strongly recommend that you use the catalog command and Page 27 / 32
do not use DBMS_BACKUP_RESTORE. See recipe 11-19 for details on how to add metadata to your control file for uncataloged backup pieces. Use the DBMS_BACKUP_RESTORE package to restore files from backup pieces. This recipe has several examples: Restoring a control file Restoring datafiles contained in a single backup piece Restoring datafiles contained in several backup pieces Applying incremental backups to datafiles Restoring archived redo log files Note You can use the DBMS_BACKUP_RESTORE package with any version of Oracle that supports RMAN. Restoring a Control File You can use the PL/SQL package DBMS_BACKUP_RESTORE to restore a control file. You need to know the name of the backup piece that contains the backup of the control file before you begin. Modify the following anonymous block of PL/SQL to use your backup piece name and control file name: DECLARE finished BOOLEAN; v_dev_name VARCHAR2(75); BEGIN Allocate a channel, when disk then type = null, if tape then type = sbt_tape. v_dev_name := dbms_backup_restore.deviceallocate(type=>null, ident=>'d1'); dbms_backup_restore.restoresetdatafile; dbms_backup_restore.restorecontrolfileto( cfname=>'c:\oracle\product\10.2.0\oradata\orcl\control01.ctl'); dbms_backup_restore.restorebackuppiece( 'C:\oracle\product\10.2.0\flash_recovery_area\ORCL\AUTOBACKUP\ 2006_12_06\O1_MF_N_608466281_2QFZ6TNJ_.BKP', finished); if finished then dbms_output.put_line('control file restored.'); else dbms_output.put_line(''); end if; dbms_backup_restore.devicedeallocate('d1'); END; / If the previous code was stored in a file named rc.sql, then you would execute it as follows: SQL> connect / as sysdba SQL> startup nomount; SQL> @rc.sql Restoring Datafiles in a Single Backup Piece If you have output logs from your backups, then you can visually inspect those and determine the names of the datafiles within a backup piece. If you don't have any output logs, then you'll have to figure out through trial and error which datafiles are in which backup piece. In this example, we know from our RMAN backup output logs that there are four datafiles contained within this backup piece. You'll need to modify this anonymous block of PL/SQL code to specify the files in your environment: SET SERVEROUTPUT ON DECLARE finished BOOLEAN; Page 28 / 32
v_dev_name VARCHAR2(75); BEGIN Allocate channels, when disk then type = null, if tape then type = sbt_tape. v_dev_name := dbms_backup_restore.deviceallocate(type=>null, ident=> 'd1'); Set beginning of restore operation (does not restore anything yet). dbms_backup_restore.restoresetdatafile; Define datafiles and their locations for datafiles in first backup piece. dbms_backup_restore.restoredatafileto(dfnumber=>1,toname=>'c:\orcl\system01.dbf'); dbms_backup_restore.restoredatafileto(dfnumber=>3,toname=>'c:\orcl\sysaux01.dbf'); dbms_backup_restore.restoredatafileto(dfnumber=>4,toname=>'c:\orcl\users08.dbf'); dbms_backup_restore.restoredatafileto(dfnumber=>9,toname=>'c:\orcl\ora02.dbf'); Restore the datafiles in this backup piece. dbms_backup_restore.restorebackuppiece(done => finished, handle=>'c:\fra\orcl\backupset\2006_12_26\ O1_MF_NNNDF_TAG20061226T174632_2S3JM9NJ_.BKP', params=>null); IF finished THEN dbms_output.put_line('datafiles restored'); ELSE dbms_output.put_line(''); END IF; dbms_backup_restore.devicedeallocate('d1'); END; / If you put the prior code into a file named dbr.sql, then you would run it as follows: SQL> connect / as sysdba SQL> startup mount; SQL> @dbr.sql Restoring Datafiles in Multiple Backup Pieces If you have output logs from your backups, then you can visually inspect those and determine the names of the datafiles within a backup piece. If you don't have any output logs, then you'll have to figure out through trial and error which datafiles are in which backup piece. In this example, we know from our RMAN backup output logs that there are two datafiles contained within three separate backup pieces. You'll need to modify this anonymous block of PL/SQL code to specify the files in your environment. SET SERVEROUTPUT ON DECLARE finished BOOLEAN; v_dev_name VARCHAR2(75); TYPE v_filestable IS TABLE OF varchar2(500) INDEX BY BINARY_INTEGER; v_filename V_FILESTABLE; v_num_pieces NUMBER; BEGIN Allocate channels, when disk then type = null, if tape then type = sbt_tape. v_dev_name := dbms_backup_restore.deviceallocate(type=>null, ident=> 'd1'); Set beginning of restore operation (does not restore anything yet). dbms_backup_restore.restoresetdatafile; Define backup pieces in backup set. v_filename(1) := 'C:\FRA\ORCL\BACKUPSET\2006_12_29\O1_MF_NNNDF_TAG20061229T175720_2SCGCR59_.BKP'; v_filename(2) := 'C:\FRA\ORCL\BACKUPSET\2006_12_29\O1_MF_NNNDF_TAG20061229T175720_2SCGG2J0_.BKP'; v_filename(3) := 'C:\FRA\ORCL\BACKUPSET\2006_12_29\O1_MF_NNNDF_TAG20061229T175720_2SCGHSC4_.BKP'; There are 3 backup pieces in this backup set. v_num_pieces := 3; Page 29 / 32
Define datafiles and locations. dbms_backup_restore.restoredatafileto(dfnumber=>1,toname=>'c:\orcl\system01.dbf'); dbms_backup_restore.restoredatafileto(dfnumber=>10,toname=>'c:\orcl\ds_ts01.dbf'); Restore the datafiles in this backup set. FOR i IN 1..v_num_pieces LOOP dbms_backup_restore.restorebackuppiece(done => finished, handle=> v_filename(i), params=>null); END LOOP; IF finished THEN dbms_output.put_line('datafiles restored'); ELSE dbms_output.put_line(''); END IF; dbms_backup_restore.devicedeallocate('d1'); END; / If you put the prior code into a file named dbr.sql, then you would run it as follows: SQL> connect / as sysdba SQL> startup mount; SQL> @dbr.sql Applying Incremental Backups Here's an example that shows how to apply an incremental backup. This example assumes that the datafile has already been restored and is now ready to have an incremental backup applied to it. You'll need to modify this anonymous block of PL/SQL to specify the filenames in your environment. SET SERVEROUTPUT ON DECLARE finished BOOLEAN; v_dev_name VARCHAR2(75); BEGIN Allocate channels, when disk then type = null, if tape then type = sbt_tape. v_dev_name := dbms_backup_restore.deviceallocate(type=>null, ident=> 'd1'); Set beginning of apply operation (does not restore anything yet). dbms_backup_restore.applysetdatafile; Define file to apply incremental to. dbms_backup_restore.applydatafileto(dfnumber=>10,toname=>'c:\orcl\data_ts.dbf'); Apply incremental backup to datafile. dbms_backup_restore.applybackuppiece(done=>finished, handle=>'c:\fra\orcl\backupset\2006_12_31\o1_mf_nnnd1_tag20061231t130613_2sj61t4s_.b KP'); IF finished THEN dbms_output.put_line('incremental applied.'); ELSE dbms_output.put_line(''); END IF; dbms_backup_restore.devicedeallocate('d1'); END; / If you put the prior code into a file named dbr.sql, then you would run it as follows: SQL> connect / as sysdba SQL> startup mount; SQL> @dbr.sql Restoring Archived Redo Log Files Page 30 / 32
Here is an anonymous block of PL/SQL that shows how to restore archived redo log files using DBMS_BACKUP_RESTORE. Before using this, you'll have to change this code to match your environment. This example restores two archived redo log files that are stored in one backup piece. SET SERVEROUTPUT ON DECLARE finished BOOLEAN; v_dev_name VARCHAR2(75); BEGIN Allocate channels, when disk then type = null, if tape then type = sbt_tape. v_dev_name := dbms_backup_restore.deviceallocate(type=>null, ident=> 'd1'); Set beginning of restore operation (does not restore anything yet). dbms_backup_restore.restoresetarchivedlog; Define archived redo log files to be restored. dbms_backup_restore.restorearchivedlog(thread=>1, sequence=> 354); dbms_backup_restore.restorearchivedlog(thread=>1, sequence=> 355); dbms_backup_restore.restorebackuppiece(done=>finished, handle=> 'C:\FRA\ORCL\BACKUPSET\2006_12_30\O1_MF_ANNNN_TAG20061230T100354_2SF7055R_.BKP', params=>null); IF finished THEN dbms_output.put_line('archived redo log files restored'); ELSE dbms_output.put_line(''); END IF; dbms_backup_restore.devicedeallocate('d1'); END; / If you put the prior code into a file named dbr.sql, then you would run it as follows: SQL> connect / as sysdba SQL> @dbr.sql Normally you will never need to know about or use DBMS_BACKUP_RESTORE. You would use it only if you couldn't accomplish a backup and recovery task through the regular RMAN interface. The PL/SQL package does come in handy once in a while if you're exclusively using a control file for your repository and find yourself in the circumstance where the control file doesn't contain any information about your RMAN backups. Before you can use the DBMS_BACKUP_RESTORE package, you need to know the following: Location and names of files in a backup set Location and names of backup pieces in the backup set We recommend that when you create your RMAN backups that you always spool out a log file (see recipe 17-7 for details). That will ensure that you can determine which datafiles, control files, and archived redo log files are in which backup pieces. If you don't know what datafiles are in which backup pieces, then you'll have to do some trial-and-error restore operations (guess which datafile is in which backup piece). The basic approach to restore a datafile using DBMS_BACKUP_RESTORE is to use an anonymous block of PL/SQL as follows: 1. Allocate a channel with deviceallocate. 2. Inform Oracle that you're going to restore datafiles using restoresetdatafile. 3. Use restoredatafile to specify datafiles to be restored. 4. Use restorebackuppiece to specify the backup piece(s) and perform the actual restore operation. Page 31 / 32
5. Deallocate the channel with devicedeallocate. Interestingly, most of the work that RMAN performs is accomplished through calls to DBMS_BACKUP_RESTORE. Oracle does not readily provide documentation for this package. We suggest that you contact Oracle Support if you need more details on how to use this undocumented package for your particular situation. Tip If you want to view what calls RMAN makes to DBMS_BACKUP_RESTORE, enable PL/SQL debugging as described in recipe 17-9. From within SQL*Plus, if you describe DBMS_BACKUP_RESTORE, you'll see that it contains more than 150 procedures and functions. You'll need to use only a small subset of those. Table 11-3 contains a brief description of the functions and procedures in DBMS_BACKUP_ RESTORE that you are most likely to use. The most common uses of this package are to restore control files, datafiles, and archived redo log files. Table 11-3: Useful Procedures and Functions in DBMS_BACKUP_RESTORE Procedure/Function deviceallocate restoresetdatafile restorecontrolfileto restoredatafileto restorebackuppiece devicedeallocate restorearchivedlog applysetdatafile applydatafileto ApplyBackupPiece Description Allocates a device to be used Tells Oracle that you're going to be restoring from an RMAN backup set Instructs Oracle where the control file is to be restored Defines a datafile and where it should be restored Defines a backup piece and initiates the actual restore operation Deallocates device that was allocated by the deviceallocate function Defines an archived redo log file thread and sequence to be restored Tells Oracle that you're going to be applying an incremental to a datafile Tells Oracle to which datafile that the incremental will be applied Defines which backup piece has the incremental backup and applies the incremental Page 32 / 32