Page 535
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):
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
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:
recover database; alter system archive log all; alter database open;
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
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
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
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.
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.
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.
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.