256  Chapter 6  n  Recovering Databases with RMAN

One time that you might need to perform point-in-time recovery is during a database recovery after a complete loss of the online redo logs of the database. This might include cases where just the online redo logs were lost or cases when the entire database was lost, including the online redo logs. While it is possible to save your database data in the event of such a loss (see Chapter 3 for more information on such a case), it is likely that you will have to perform a point-in-time recovery to get your database operational again. This will, of course, result in some data loss.

You can also restore databases using tags. A tag allows you to choose a specific backup image that you want to use for the restore. You can also use a tag during a recovery to indicate specific incremental backups that you want to use for a restore. When you use tags, Oracle will still do a complete recovery unless you use the until time parameter to indicate that you want to recover to a specific point in time.

Here is an example where we are restoring the database using the tag gold_copy:

shutdown immediate startup mount

restore database from tag ’gold_copy’; recover database from tag ’gold_copy’; alter database open;

We discussed database incarnations in Chapter 3. Sometimes for specific types of RMAN recoveries you will need to reset the database incarnation. We will cover this in more detail in Chapter 8.

Using Image Copies to Recover Your Database

Recall that an image copy is an exact copy of a given database datafile. You can use image copies to restore your database. This can provide for quick database recovery, though the image copies will require much more storage than a compressed backup set piece.

Oracle provides the switch command to use in place of the restore command. This will essentially change the control file so it will point to the datafile copy(ies). You then would call the recover command to apply any incremental backups and archived redo logs to restore the datafile(s) or tablespace(s). You can switch the entire database, tablespaces, or specific datafiles depending on your needs. Here is an example where we are restoring datafile 4:

Sql ’alter database datafile 4 offline’;

Switch datafile 4 to copy ‘/oracle/backup/users_01.dbf’;

Recover datafile 4;

Sql ‘alter database datafile 4 online’;

Note that if you are making image copies and backup-set copies, RMAN will determine which to use during a normal restore operation. This includes image copies that are updated with incremental backups (discussed in Chapter 4). So, with image copies you have two options for restore and recovery really:

NNUse the restore command to have RMAN copy the image copies to the original location of the database datafiles. This will not result in any changes to datafile locations in the database control file.

NNUse the switch command to cause RMAN to instantly start using the image copy of the datafile in its current location. This will cause the database control file to be changed with locations of the new database datafiles.

Other Basic Recovery Topics

There are other recovery-related topics you will need to be aware of. In the following sections, we will cover some of those, and in Chapter 8 we will cover other, more advanced recovery topics. In this section we will discuss block media recovery and recovering from lost control files and lost spfiles with RMAN.

Block Media Recovery

Sometimes one or a few blocks will become corrupt. It’s rare, but it happens. RMAN provides the ability to do online block media recovery. With block media recovery, RMAN will recover the corrupted blocks online. The only user impact will be to those users who want to access the corrupt blocks, and they will have been impacted anyway.

In Oracle Database 11g you use the recover command with the datafile…block option to perform block media recovery. To use the recover block command the following requirements must be met:

For example, sometimes you will issue a DML or DDL statement and get an error such as the one found here:

ORA-01578: ORACLE data block corrupted (file # 6, block # 55) ORA-01110: data file 6: ‘/oracle/oradata/trgt/users01.dbf’

258  Chapter 6  n  Recovering Databases with RMAN

In this case, you could issue the recover datafile command using the block parameter as seen in this example:

Recover datafile 6 block 55;

In some cases, you may want to repair a range of blocks, as shown here:

Recover datafile 6 block 55 to 105;

You can also recover a range of blocks and several datafiles at one time:

Recover datafile 6 block 55 to 105 datafile 7 block 27 to 44;

You can also run the backup database validate command to determine if any blocks are media corrupt. Any blocks that are corrupt will be listed in the V$DATABASE_BLOCK_ CORRUPTION view. The column CORRUPTION_TYPE will indicate if they are media corrupt.

You can attempt to recover all corrupted blocks listed in the V$DATABASE_BLOCK_ CORRUPTION view by using the recover command with the corruption list parameter from RMAN, as seen in this example:

RMAN> recover corruption list; Starting recover at 28-OCT-08

using target database control file instead of recovery catalog allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=153 device type=DISK starting media recovery

media recovery complete, elapsed time: 00:00:01 Finished recover at 28-OCT-08

Recovering the Control File

One recovery that you need to be prepared for is the recovery of a lost control file. There are two different situations that come into play here. The first is recovering the control file from a control-file autobackup; the second is recovering a control file if you are not using control-file autobackups. Let’s look at each of these methods in more detail.

Recovering Control Files with Control-File Autobackups

We talked about RMAN control-file autobackups in Chapter 4. They are a way of automating the backup of database control files. Recovering the control file is quite easy if you are using control-file autobackups. There are two different situations that you will deal with when using control-file autobackups: one when you are using the flash recovery area (FRA) and the other when you are not using the FRA. Let’s look at these in a bit more detail.

Control-File Backups Using the FRA

If you are using the FRA and have enabled control-file autobackups, then restoring the current control file is easy. Simply do the following:

NNIssue the restore controlfile from autobackup command. RMAN will proceed to restore the control file from the latest automated control-file backup on disk.

RMAN> Startup nomount;

connected to target database (not started)

RMAN> Restore controlfile from autobackup; Starting restore at 28-SEP-08

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=153 device type=DISK

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20080928 channel ORA_DISK_1: AUTOBACKUP found: c:\oracle\controlfilebackup\c-437680418-20080928-00 channel ORA_DISK_1: restoring control file from AUTOBACKUP c:\oracle\controlfilebackup\c-437680418-20080928-00

channel ORA_DISK_1: control file restore from AUTOBACKUP complete output file name=C:\ORACLE\ORADATA\RCAT\CONTROL01.CTL

output file name=C:\ORACLE\ORADATA\RCAT\CONTROL02.CTL output file name=C:\ORACLE\ORADATA\RCAT\CONTROL03.CTL Finished restore at 28-SEP-08

RMAN> alter database mount; database mounted

released channel: ORA_DISK_1 RMAN> recover database; Starting recover at 28-SEP-08 allocated channel: ORA_DISK_1

260  Chapter 6  n  Recovering Databases with RMAN

channel ORA_DISK_1: SID=153 device type=DISK starting media recovery

archived log for thread 1 with sequence 13 is already on disk as file C:\ORACLE\ORADATA\RCAT\REDO01.LOG

archived log for thread 1 with sequence 14 is already on disk as file C:\ORACLE\ORADATA\RCAT\REDO02.LOG

archived log file name=C:\ORACLE\ORADATA\RCAT\REDO01.LOG thread=1 sequence=13 archived log file name=C:\ORACLE\ORADATA\RCAT\REDO02.LOG thread=1 sequence=14 media recovery complete, elapsed time: 00:00:01

Finished recover at 28-SEP-08

RMAN> alter database open resetlogs; Database opened

When you use the restore controlfile from autobackup command, Oracle will start searching for the most current control-file autobackup by default. If you have used the set until command to perform a point-in-time recovery, RMAN will start searching for the most current control file starting with that day/time and moving backwards.

The restore controlfile command also comes with the maxseq and maxdays parameters to further control how much effort is used to search for a backup control file.

The maxseq parameter  ​  ​Each control-file backup on a given day is assigned a sequence number. That number increments by one for each additional control-file autobackup, until the next day when the sequence resets itself. The maximum sequence number is 256 and the minimum number is 0. RMAN will always search for the highest sequence number (or the most current file) first. The maxseq parameter indicates to RMAN which sequence number it should start with when looking for the correct control-file autobackup. This allows you to skip certain sequence numbers if you know you do not want to use them. Here is an example of using maxseq:

Restore controlfile from autobackup maxseq 200;

The maxdays parameter  ​  By​ default RMAN will look back 7 days (from the current date or the set until date) to find the correct control-file autobackup. If you want to change this default setting, use the maxdays parameter when calling the restore controlfile from autobackup command. You can search from 0 until 366 days for the current controlfile autobackup. Here is an example of using maxdays where we will go back 30 days to find the correct control-file autobackup.

Restore controlfile from autobackup maxdays 30;

The maxdays and maxseq parameters also apply to spfile autobackup restore operations.

Control-File Backups Not Using the FRA

If you are not using the FRA but have enabled control-file autobackups, you will need to determine the database ID (DBID) of the database. Each database has a DBID, which

uniquely identifies it. You should maintain a list of DBIDs for each of your databases if you are not using the FRA but want to use control-file autobackups. You can find the DBID in the DBID column of the V$DATABASE view as seen in this query:

SQL> select dbid from v$database; DBID

----------

437680418

The database DBID is included in the filename of the control-file autobackup backup set pieces (if you’re not using the FRA). Thus, in a worstcase situation, you can determine the DBID for your database by looking at these files and determining the DBID from the filenames. If you are not using the FRA, this is one very good reason to have control-file autobackups be put in different directories for different databases!

Now that you have the DBID, you are ready to restore the database control file. To do so, follow these steps:

1.Start up the database in NOMOUNT mode. This will start the database and load the database parameter file. The FRA parameters will be set at this point.

2.Issue the set dbid command to set the database DBID that RMAN will look for.

3.Set the control-file autobackup location with the set controlfile autobackup format command.

4.Restore the control file with the restore command.

5.Mount the database for recovery.

6.Issue the recover database command.

7.Open the database using the alter database open resetlogs command.

Here is an example of recovering a control file when the FRA is not in use:

262  Chapter 6  n  Recovering Databases with RMAN

executing command: SET DBID

RMAN> set controlfile autobackup format for device type disk to ‘c:\oracle\controlfilebackup\%F’;

executing command: SET CONTROLFILE AUTOBACKUP FORMAT RMAN> Restore controlfile from autobackup;

Starting restore at 28-SEP-08 using channel ORA_DISK_1

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20080928 channel ORA_DISK_1: AUTOBACKUP found: c:\oracle\controlfilebackup\c-437680418-20080928-04 channel ORA_DISK_1: restoring control file from AUTOBACKUP c:\oracle\controlfilebackup\c-437680418-20080928-04

channel ORA_DISK_1: control file restore from AUTOBACKUP complete output file name=C:\ORACLE\ORADATA\RCAT\CONTROL01.CTL

output file name=C:\ORACLE\ORADATA\RCAT\CONTROL02.CTL output file name=C:\ORACLE\ORADATA\RCAT\CONTROL03.CTL Finished restore at 28-SEP-08

RMAN> Alter database mount; database mounted

released channel: ORA_DISK_1 RMAN> Recover database; Starting recover at 28-SEP-08 allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=153 device type=DISK starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file C:\ORACLE\ORADATA\RCAT\REDO01.LOG

archived log for thread 1 with sequence 2 is already on disk as file C:\ORACLE\ORADATA\RCAT\REDO02.LOG

archived log file name=C:\ORACLE\ORADATA\RCAT\REDO01.LOG thread=1 sequence=1 archived log file name=C:\ORACLE\ORADATA\RCAT\REDO02.LOG thread=1 sequence=2 media recovery complete, elapsed time: 00:00:02

Finished recover at 28-SEP-08

RMAN> alter database open resetlogs; database opened

You can also use the restore controlfile command to restore a control file to a different location and filename using the to keyword as seen in this example:

Restore controlfile to ’/tmp/orcl.ctl’ from autobackup;

Recovering Control Files When Not Using Control-File Autobackups

If you have not enabled control-file autobackups you need to use the recovery catalog to restore a control file (there are other ways—see the sidebar “Emergency Control-File Recoveries”). Simply follow these steps:

1.Start RMAN and connect to the recovery catalog.

2.Use the startup force nomount command to start the database instance.

3.Issue the restore controlfile command and RMAN will restore the control file.

4.Mount the database with the alter database mount command.

5.Issue a recover database command

6.Open the database with the alter database open resetlogs command.

Here is an example of the commands you would use to perform a control-file restore using the recovery catalog:

Startup force nomount restore controlfile; alter database mount; recover database;

Alter database open resetlogs;

You can also use the restore controlfile command to restore a control file to a different location and filename using the to keyword, as seen in this example:

Restore controlfile to ’/tmp/orcl.ctl’;

Emergency Control-File Recoveries

If you are not using control-file autobackups and you are not using a recovery catalog, what are you to do when you lose your control file? You can always re-create the control file with the create controlfile command (see Chapter 2 for more on this command). You can then use the catalog command to catalog the backup set pieces. One complication may be if you are backing up to tape. In this case, you may have to restore your backups from tape to local disk before you can run the catalog command.

It is not a fun exercise to have to create your own create controlfile command from scratch and we strongly recommend that you configure control-file autobackups instead.

264  Chapter 6  n  Recovering Databases with RMAN

Recovering the Spfile

If you have enabled control-file autobackups, then RMAN will back up the current spfile each time a control-file autobackup occurs. To restore your spfile, you will first need to start the database from RMAN without a parameter file of any sort. Just simply type in startup nomount and the database will start using default parameter settings. This positions the database to be able to restore the spfile from the autobackup. RMAN will display a message when it’s using default parameter settings as seen in this output:

RMAN> startup nomount

connected to target database (not started)

startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file ‘C:\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\INITORCL.ORA’

starting Oracle instance without parameter file for retrieval of spfile

The restore process for an spfile differs a bit depending on if you have been using the FRA or not using the FRA. We will look into these two different options in the next sections.

Restoring the spfile When Using the FRA

Restoring the spfile when using the FRA is a bit more complex than restoring the control file. First you will need to start the database instance, as demonstrated previously. Then you will need to configure the FRA location. Because the FRA parameter DB_RECOVERY_FILE_DEST is not dynamic, you need to create a temporary pfile based on the current memory settings and then update it with the correct FRA location.

First, you create the temporary pfile from the in-memory settings using the SQL command create pfile from memory. This command will create a database parameter file that you will edit. The parameter settings in this file will be based on the default, in-memory settings used when RMAN started the database. Here is an example of the creation of the pfile from memory:

RMAN> sql ‘create pfile from memory’;

using target database control file instead of recovery catalog sql statement: create pfile from memory

Note that you must create a pfile and not an spfile. This is because you cannot restore over an existing spfile that is in use. Using your editor of choice, edit the pfile you just created. The pfile will typically be created in ORACLE_HOME/database in Win and $ORACLE_HOME/dbs in linux.

You will want to set the DB_RECOVERY_FILE_DEST parameter to the location of the FRA and DB_RECOVERY_FILE_DEST_SIZE to the size of the FRA. When setting the DB_RECOVERY_ FILE_DEST_SIZE parameter, don’t worry about how big you need to size it because this is just a temporary parameter setting for the spfile restore. The real value of the parameter will be set after the spfile has been restored. Here is an example of what those parameters would look like in a pfile:

db_recovery_file_dest=’c:\oracle\flash_recovery_area’ db_recovery_file_dest_size=10g

Once the parameter has been set correctly, save the file and restart the database using the temporary pfile, as shown here:

C:\Documents and Settings\Robert>rman target=/

You can now restore the spfile backed up in the last control-file autobackup using the restore spfile from autobackup command, as shown here:

RMAN> restore spfile from autobackup; Starting restore at 28-SEP-08

using target database control file instead of recovery catalog allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=98 device type=DISK

recovery area destination: c:\oracle\flash_recovery_area database name (or database unique name) used for search: ORCL channel ORA_DISK_1: AUTOBACKUP C:\ORACLE\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2008_09_28 \O1_MF_S_666628278_4FZTDYVC_.BKP found in the recovery area

AUTOBACKUP search with format “%F” not attempted because DBID was not set

266  Chapter 6  n  Recovering Databases with RMAN

channel ORA_DISK_1: restoring spfile from AUTOBACKUP C:\ORACLE\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2008_09_28 \O1_MF_S_666628278_4FZTDYVC_.BKP

channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete Finished restore at 28-SEP-08

Now all you need to do is shut down and start up the database (assuming further restore and/or recovery operations are not required) or use the startup force command, as shown here:

Just to summarize the steps needed to perform this recovery, here they are:

1.startup nomount the database from RMAN.

2.Issue the create pfile from memory command from SQL*Plus or using the SQL RMAN command.

3.Edit the pfile so that it contains the correct setting for the parameter DB_RECOVERY_ FILE_DEST and the parameter DB_RECOVERY_FILE_DEST_SIZE.

4.Shut down and restart the database instance using the newly created pfile.

5.Use the restore spfile from autobackup command to restore the spfile.

6.Restart the database using the startup force command.

Restoring the Spfile When Not Using the FRA

If you are not using the FRA, the procedure to restore the spfile from an autobackup is actually slightly easier. First, you have already started the database instance. You will have to set two RMAN parameters. The first parameter identifies the DBID of the database (discussed earlier in this chapter). You use the set dbid command to do this, as shown here:

RMAN> Set dbid= 437680418 executing command: SET DBID

Now you need to use the set controlfile autobackup format parameter to indicate where the control-file autobackups can be found, as shown here:

RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 2> ‘c:\oracle\controlfilebackup\%F’;

executing command: SET CONTROLFILE AUTOBACKUP FORMAT

using target database control file instead of recovery catalog

All that remains is the restore of the spfile:

RMAN> Restore spfile from autobackup; Starting restore at 28-SEP-08 allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=98 device type=DISK

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20080928 channel ORA_DISK_1: AUTOBACKUP found: c:\oracle\controlfilebackup\c-437680418-20080928-00 channel ORA_DISK_1: restoring spfile from AUTOBACKUP c:\oracle\controlfilebackup\c-437680418-20080928-00 channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete Finished restore at 28-SEP-08

You can also include the set commands within the confines of a run block, as shown here:

RUN

{

SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘c:\oracle\controlfilebackup\%F’;

RESTORE CONTROLFILE FROM AUTOBACKUP MAXSEQ 100;

}

You can now open the database with the startup force command, as shown here: