Previous | Table of Contents | Next

Page 609

Using Physical Recovery

Many DBAs would agree that physical recovery can be the most stressful and difficult part of their jobs. Like physical backups, a good portion of recovery is OS-centric. Windows desktop DBAs will find that Oracle Recovery Manager replaces much of the OS portion of the recovery process. No matter which platform you use, most of the same issues and sequences apply. Physical recovery can encompass far more than this book can cover. There are generally four situations in which performing physical recovery is required:

The first two situations are really the same procedure—you need to restore missing files (maybe all of them) from a cold backup. In effect, you're physically re-creating the database. This topic is covered in the "Physically Re-creating a Database" section.

Recovering from lost data files is an issue you face when a disk drive fails, data files are accidentally deleted, or you can't access data for whatever reason. Because you don't want to lose any data, you will use a complete recovery.

Restoring to some point in the past is also a form of complete recovery, except that you must take a "one step forward and two steps back" approach. This is known as an incomplete recovery.

If you are working on your production system and need to perform any type of recovery, you should always, if possible, shut down the database and make a cold backup of everything before you even think about recovering the database. This is just in case something goes wrong and you end up with a completely ruined database. Furthermore, a good rule of thumb is to try a recovery once. If it fails, call Oracle. DBAs can quickly get themselves way in over their heads by experimenting with recovery techniques.

Physically Re-creating a Database

DBAs often need to create an exact duplicate of a database on another machine. As part of general maintenance, it is not unusual to upgrade database disk drives or to rebuild the file-systems containing database files. In either case, you need to "take a picture" of the system (in other words, do a cold backup). You then either copy all of the files to another machine or restore them to the same machine once the system administrators finish their maintenance work. All you need to do is restore the cold backup to either the original machine (when the maintenance is finished) or a new machine, and then start the database. Remember that all of your data, redo logs, archived logs, and control files should go into exactly the same directory location where they were originally. Because of the cold backup/restore, Oracle will wake up in

Page 610

its new environment unaware that anything has happened since it was shut down. Therefore, it will expect to find all of the components where they were before.

If you need to change the location of a few files, refer to the section "Renaming and Moving Database Files." If you need to change the location of many database files, it is usually best to use a logical backup and recovery. This is because it is very tedious and error prone to change the location of many database files.

On a command-line system, the recovery is completely OS based. You need to restore all of the following database files:

You will restore these files using whatever backup/restore utilities are available on your machine.

If you lost only a few files during maintenance, you can restore just the lost files provided that you have not restarted the database since your cold backup. Once you have all of the files in place, start the database through Server Manager.

In the Windows environment, Oracle provides Recovery Manager to restore the data files. Before running Recovery Manager, make sure the appropriate init<instance>.ora file exists. Remember to put it on the same drive letter and directory path where it was originally.

When you start Recovery Manager, you see a dialog box similar to Figure 24.4.

FIG. 24.4
Oracle Recovery
Manager provides a
convenient GUI interface
for recovering data—
bases.

To restore the database, complete the following steps:

  1. Select the Restore from Full Database Backup option.

  2. Click the Recover button.

Page 611

  1. Recovery Manager now needs to know where to find the backup files (generated by Oracle Backup Manager). Enter the name of the directory where the backup files are located or select the tape device where the backup tape has been mounted.

  2. If you are recovering from disk, make sure that <latest backup> is indicated in the Backup: field.

  3. Click OK. The restore will now commence.
  4. Start the database.

Complete Recovery

Complete recovery will bring your databases back to life without losing any transactions if a data file is lost. Complete recoveries use the redo and archived log files to prevent the loss of data if a data file is lost or damaged. It is imperative that control files, redo logs, and archived logs do not reside on the same physical disk as data files. Losing archived logs or redo logs as well as data files will prevent you from recovering without data loss (this is known as an incomplete recovery).

The idea of a complete recovery is to restore an older copy of a lost data file from a warm or cold backup and then reapply all of the changes that have occurred since the backup. Rolling forward, a technique used by many RDBMSs (including Oracle) to provide complete recovery, means "replaying" the actions contained in the redo and archived logs. Oracle keeps a master odometer, known as a sequence number, recorded in both data files and control files. By looking at the control files, Oracle knows what sequence number all of the data files should have recorded. If a particular data file does not contain the current sequence number, Oracle knows that it is not current and is in need of recovery before the database can open.

By looking at the sequence number in a data file in need of recovery, Oracle knows where it needs to begin replaying transactions. Oracle will expect to find at least one set of redo logs, as well as all of the archived log files it will need in the archived log directory (set in the init.ora file). Therefore, you should delete only files from the archived log directory that were recorded before the beginning of the last backup. If you're missing any archived logs or you've lost all copies of your redo logs, you will have to perform an incomplete recovery—you won't be able to recover to the last commit.

Once you have experienced the loss of a data file, you need to shut down the database (if it hasn't shut itself down). If necessary, use SHUTDOWN ABORT. If you have experienced a hardware failure, you'll need to fix the problem before continuing.

Command-Line EnvironmentsNow that the operating system is back up and running, inspect the damage. Once you know which data files were lost, you (or the system administrator) should restore them to the same location where they were originally. Do not recover any redo logs or control files, even if some were lost. Oracle will use the copies that still exist on the system. You'll recover these lost files after the data files are fixed.

Previous | Table of Contents | Next