0535-0537

Previous Table of Contents Next

Page 535

Control File

Whenever a database loses a control file, there is generally little impact on the database itself as long as the DBA has mirrored the control files. To recover the control file, follow these steps (which assume that the control file has been mirrored):

1. From Oracle Server*Manager, do connect internal and perform a shutdown (or shutdown immediate) on the database.
2. Copy one of the existing control files over the corrupted file. If it is not possible to do this, copy it to another location and reflect the change in the CONTROL_FILES parameter of the INIT.ORA parameter file or remove it completely.
3. From Oracle Server*Manager, do connect internal and perform a startup on the database.

The database will bring the control file in sync with the database, and the users will experience no loss of service or downtime.

If a control file has been lost and there is no backup, Oracle continues to run until it attempts to access the control file. At that point, the Oracle instance aborts. Two options available to the DBA are

• Create a new control file
• Restore the control file from backup

To create a control file, you must first create a SQL script that will adequately re-create the existing control file. If a backup to trace is part of regular backups , the script already exists in the USER_DUMP_DEST directory. Use ls -lt in UNIX to find the most recent one. Use view to make sure that it creates a control file and is not simply SQL*Trace output). Perform the following steps:

1. Locate or create a SQL script.
2. From Oracle Server*Manager, do connect internal.
3. If a new create script was created, issue the startup nomount command. Execute the SQL script. Then execute the following commands:

    recover database; alter system archive log all; alter database open; 

4. If the create control file script is from a backup to trace, execute the script from a shutdown database. It will execute all the intermediate steps and open the database.

If you choose to use a backup control file, issue the following recover command in place of the standard recover command:

 recover database using backup controlfile; 

Page 536

Redo Logs

As with control files, there are two possible scenarios: loss of mirrored redo logs and loss of nonmirrored redo logs. If at least one member in each redo log group is usable and not corrupted, the database continues to function normally. You should determine what caused the failure or corruption of the redo log member. Then you should rectify the problem by dropping and re-creating the log member.

If all the members of a redo log group became corrupted or were lost, the scenario is entirely different. Dealing with the loss of an entire redo log group is the same as dealing with a nonmirrored redo log. The two possibilities are

• The redo logs were not the active group.
• The redo logs were the active group.

If the redo log group was not the active group, the corrupt group and its members eventually cause the database to shut down. The trick is to recognize that damage has been done and to react before the database shuts down. Restore the online redo log from tape or copy it from an existing redo log group if they are the same size . If the disk itself is corrupt and unavailable, rename the redo log group. If you are lucky enough to catch the database at this time, this is the best alternative. Otherwise, if the database attempts to access the corrupted redo log, the redo log must be recovered as if the active redo log were lost.

The most likely scenario is that the database aborted because it lost an inactive online redo log. The recovery steps are basically the same, but they are done in an offline fashion. Recover the offending redo log group or make a copy of an existing group if they are the same physical size. From Oracle Server*Manager, do connect internal and start up the database. The downtime involved should be minimal.

A loss of the current online redo log requires a limited recovery scenario. Although a full database recovery is not actually applied, you must make the database think that one has occurred. Only then can processing continue. The steps are

1. From Oracle Server*Manager, do connect internal. Use shutdown, shutdown immediate, or shutdown abort to shut down the database.
2. Execute startup mount on the database instance.
3. After the database has been mounted, issue the recover database command. At the next prompt, enter cancel.
4. Issue an alter database command with the rename option to move the corrupted redo logs to a new location. The new files are created automatically.
5. Execute the alter database open resetlogs; command from Oracle Server*Manager. The database is brought back online for continued operations.

Operations that require restarting an aborted Oracle database instance can be quite complex. The complications that can arise during an operation as sensitive as a recovery are numerous .

Page 537

If the recovery process does not seem to work properly, stop and contact Oracle technical support immediately.

Archive Logs

You have been forced to tinker with startups , shutdowns, and renaming and recovering physical database files. At least losing archive logs does not affect the continued operations of the database.

Well, almost.

Unlike losing a database file, a control file, or a redo log ”which ultimately causes an Oracle database instance to abort ”losing an archive log has no visible effect on the database. After all, the logs are retained offline and are accessed only when they are created as archives of the online redo logs and when they are used for database recovery.

CAUTION

Even though the loss of an archive log does not affect the continued operations of the database ”which is why NOARCHIVELOG mode is available ”if anything occurs that requires database recovery before the next backup, it will be impossible to recover the database.

Because archive logs facilitate recovery, their loss is often realized only when it is too late. It is a difficult position for a DBA, and there is no clear right or wrong solution. It depends on the backup schedule. It is easier to wait a few hours until the next hot backup than to wait several days for the next cold backup. Make sure to include archive logs as part of your daily backup routine.

We recommend that you immediately initiate a hot backup of the database. It will slow down things and cause the system to choke a little on processing, especially during peak usage time. It is far better, though, than waiting and hoping that nothing will happen.

Recovery Methods

There are several methods for performing database recovery. Each method offers a trade-off between speed and simplicity. The following sections describe the major types of recovery available through the Oracle RDBMS.

Cold Restore

In a cold restore, all the database files, control files, and redo logs are restored from tape or disk, and the database is restarted. It is the simplest, most complete recovery operation to perform. The primary drawback is that anything done to the database since the last backup is lost.

Previous Table of Contents Next