Oracle makes a distinction between restoring and recovering a database. Restore means the replacement of individual database files from backup media, whereas recover means applying redo logs to roll forward the redo log transactions to make the database consistent. By contrast, NetWorker uses recover for all retrieval activities, as distinguished from the UNIX restore command. This chapter follows the Oracle terminology.

Use obackup to restore missing database files. Then apply the redo logs to recover your target database through the standard Oracle recovery process.

---

Note: Database restores are always executed through obackup. The restore is executed by running the obackup command with a restore script. Restores driven through the NetWorker interface are not supported.

---

The first sign of a disk crash will usually be an I/O error. Oracle usually documents the I/O error in the trace file and might issue an alert. Look near the end of the trace file and try to determine which database files are affected. Here are some error messages that indicate the need for recovery:

ORA-01113    file name needs media recovery
ORA-01122    data file name - failed verification check
ORA-01162    block size num in file header does not match

If only one database file is affected, your database may have encountered a bad spot on the disk. This can be circumvented by reformatting the disk to make a new list of bad blocks. However, this can be time-consuming, so keep an extra disk on hand as a hot spare, in case a disk failure occurs. Format the spare disk and verify that it works. If a disk failure does occur, it is much faster to swap in a spare disk than it is to rename database files and update the control file accordingly.

If several database files (all on the same disk) are affected, you could have a disk controller problem or a disk head crash. A bad controller can be replaced, and data on the disk often remains in perfect shape. But after a head crash, you need to use that spare disk as a replacement disk.

If you do not provide a setting for the required Networker BusinesSuite Module for Oracle variable, Enterprise Backup Utility restores may fail.

Setting the Value for NSR_CLIENT

Verify that the NSR_CLIENT environment variable is set during restores to the name of the client whose data was backed up. In most cases, this will be the name of the local machine, unless you are restoring data to a different host machine. By default, the BusinesSuite Module for Oracle will use the name of the local machine. To set the NSR_CLIENT environment variable, run the following command:

% setenv NSR_CLIENT networker_clientname

---

Note: For an example of a restore scenario in which you need to set the NSR_CLIENT variable, see the section “Using obackup to Restore to a Different Host”.

---

Setting the Value for NSR_SERVER

The NSR_SERVER environment variable indicates which NetWorker server to use for restores. Set this variable to the name of the server that backed up the data to be restored. To properly set NSR_SERVER, replace the value networker_servername in the following example with the actual name of the server assigned for NetWorker restores of your Oracle7 Server:

% setenv NSR_SERVER networker_servername

---

Tip: If you do not explicitly specify a value for the variable NSR_SERVER before issuing a restore command, NetWorker searches the network for a server to use. Setting the NSR_SERVER variable explicitly helps avoid a potential delay in the restore process.

---

% setenv OBK_HOME ebu_install_dir 

After setting the required environment variables, you may use obackup to restore data.

Here is an example of a restore script, in case you lose all copies of the control file:

restore
db_name = "TARGET01"
oracle_sid = "TARGET01"
control_file
log = "/oracle/obackup/logs/restore.log"

You can use the restore database script to restore the entire database, It is likely that only a few database files are damaged and that you can restore them with a partial restore script. (Notice that restore means partial restore.)

---

Note: To ensure optimal restore performance, set the parallel parameter in the restore command script to be equal to the parallel parameter used during backup.

---

This is an example of a restore database command script:

restore database
db_name = "TARGET01"
oracle_sid = "TARGET01"
log = "/oracle/obackup/logs/restore_db.log"
parallel=4

You can perform a restore database regardless of the kind of backups you performed. The Oracle Enterprise Backup Utility restores the most recent copies of all files involved. Note that after a restore database, the state of the database is inconsistent and you have to perform a standard Oracle recover. For more information, see the Oracle7 Server for UNIX Administrator's Reference Guide.

You may restore either tablespaces or datafiles as a unit. You may want to create various restore scripts, but be prepared to modify them in an actual disaster recovery situation.

As another example, assume you have a damaged disk named /disk2 and that all you have on this disk is the tablespace TOOLS, composed of many datafiles. Perform the following steps to properly restore the tablespace:

To restore individual datafiles instead of an entire tablespace, use the keyword dbfile instead of tablespace:

dbfile = "/disk2/oradata/target01/tools01.dbf",
         "/disk2/oradata/target01/tools02.dbf"

If a replacement disk for /disk2 is not available, you can restore datafiles to a different location with the remap option. For example, if /disk3 is available and has enough free space, you can restore a datafile to /disk3 instead of /disk2 by using the following type of command script:

restore
db_name = "TARGET01"
oracle_sid = "TARGET01"
dbfile = "/disk2/oradata/target01/tools01.dbf"
remap = "/disk2/oradata/target01/tools01.dbf" to
        "/disk3/oradata/target01/tools01.dbf"

In some circumstances, you might need to restore your database onto a machine other than the one from which it was backed up.

In order to execute this recovery plan, the BusinesSuite Module for Oracle and the Enterprise Backup Utility must be installed and configured on the secondary machine where you will be restoring your data.

To restore data onto a different host, set the NSR_CLIENT environment variable to the name of the machine where the database was originally backed up. NSR_CLIENT allows the secondary host to recover savesets backed up by the original client.

You must also set the backup_host parameter in the obackup command script to the name of the original backup host, in the same way that NSR_CLIENT is set. This specifier identifies the backup set in the Backup Catalog. Here is a summary of steps to perform:

---

Note: If you believe you might need to restore databases to a secondary client, Silicon Graphics strongly recommends installing and configuring both the BusinesSuite Module for Oracle and Enterprise Backup Utility on the secondary machine well in advance.

---

After restoring corrupted database files, you must apply the redo logs to bring your database up to date. To do this, refer to the sections on database recovery in the Oracle7 Server for UNIX Administrator's Reference Guide.

Should the Backup Catalog database become lost, the Backup Catalog becomes unavailable until you restore the database. The information contained in the Backup Catalog is vital to the Enterprise Backup Utility. If you have backed up the Catalog after every backup series (full or partial), then you can restore the Backup Catalog from a backup using the NetWorker client-side GUI.

If you did not back up the Backup Catalog, your only alternative is to recreate the Backup Catalog database and apply its redo logs.

If the Backup Catalog becomes corrupted, you must start by restoring the Backup Catalog database using the nwrecover program. Then run the Oracle import command. If the Backup Catalog is intact, this step is not necessary. The obkimp.sh shell script is provided to import the catalog database from an export done with the obkexp.sh script.

Enterprise Backup Utility version 2.1 automates the backup and restore of the Backup Catalog. As the last step of any backup, EBU 2.1 automatically saves the Backup Catalog information to the backup media, unless you disable this feature.

If the Backup Catalog becomes corrupted or deleted, as when the disk drive containing the catalog experiences a hardware failure, you can recover with the following steps. Before beginning, ensure that the Backup Catalog was successfully backed up with the combination of EBU 2.1 and BusinesSuite Module for Oracle. In this example, the Backup Catalog ORACLE_SID is obk.

Follow these steps to perform a closed database recovery:

Follow these steps to perform an open database recovery:

Follow these steps to perform an incomplete media recovery, for example after a user drops (deletes) a table by mistake. It is called “incomplete” because not all available media are used.