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