Oracle8i Parallel Server Administration, Deployment, and Performance
Release 2 (8.1.6)

Part Number A76970-01





Go to previous page Go to next page

Recovering the Database

This chapter describes Oracle recovery features on Oracle Parallel Server. It covers the following topics:

Three Types of Recovery

This chapter discusses three types of recovery:

Recovery from Instance Failure

Instance failure occurs when a software or hardware problem prevents an instance from continuing work. The following sections describe the recovery performed after failure of instances accessing the database in shared mode.

After instance failure, Oracle uses the online redo log files to perform automatic recovery of the database. For a single instance running in exclusive mode, instance recovery occurs as soon as the instance starts up after it has failed or shut down abnormally.

When instances accessing the database in shared mode fail, online instance recovery is performed automatically. Instances that continue running on other nodes are not affected as long as they are reading from the buffer cache. If instances attempt to write, the transaction stops. All operations to the database are suspended until cache recovery of the failed instance is complete.

See Also:

Oracle8i Backup and Recovery Guide. 

Single-Node Failure

Oracle Parallel Server performs instance recovery by coordinating recovery operations through the SMON processes of the other running instances. If one instance fails, the SMON process of another instance notices the failure and automatically performs instance recovery for the failed instance.

Instance recovery does not include restarting the failed instance or any applications that were running on that instance. Applications that were running may continue by failover, as described in "Recovery from Instance Failure".

When one instance performs recovery for another failed instance, the surviving instance reads redo log entries generated by the failed instance and uses that information to ensure all committed transactions are reflected in the database. Data from committed transactions is not lost. The instance performing recovery rolls back any transactions that were active at the time of the failure and releases resources being used by those transactions.

See Also:

Oracle8i Parallel Server Concepts for more information about application failover.  

Multiple-Node Failure

As long as one instance continues running, its SMON process performs instance recovery for any other instances that fail.

If all instances of an Oracle Parallel Server fail, instance recovery is performed automatically the next time an instance opens the database. The instance does not have to be one of the instances that failed, and it can mount the database in either shared or exclusive mode from any node of the Oracle Parallel Server. This recovery procedure is the same for Oracle running in shared mode as it is for Oracle in exclusive mode, except that one instance performs instance recovery for all failed instances.

Fast-Start Checkpointing

Fast-start checkpointing is the basis for Fast-start fault recovery in Oracle. Fast-start checkpointing occurs continuously, advancing the checkpoint as Oracle writes blocks to disk. Fast-start checkpointing always writes the oldest modified block first, ensuring that every write allows the checkpoint time to be advanced. This eliminates bulk writes and the resulting I/O spikes that occur with conventional checkpointing, yielding smooth and efficient on-going performance.

You can specify a limit on the duration of the roll forward phase of Fast-start checkpointing. Oracle automatically adjusts the checkpoint write rate to meet the specified roll-forward limit while issuing the minimum number of writes.

See Also:

Oracle8i Designing and Tuning for Performance for details on how to do this.  

Fast-Start Rollback

The rollback phase of system fault recovery in Oracle uses "non-blocking" rollback technology. This means new transactions can begin immediately after roll forward completes. When a new transaction accesses a row locked by a dead transaction, the new transaction rolls back only the changes that prevent the transaction's progress. New transactions do not have to wait for Oracle to roll back the entire dead transaction, so long-running transactions no longer affect recovery time. The Fast-start technology maximizes data availability and ensures predictable recovery time.

In addition, the database server can roll back dead transactions in parallel. This technique is used against rows not blocking new transactions, and only when the cost of performing dead transaction roll back in parallel is less than performing it serially.

See Also:

Oracle8i Parallel Server Concepts for more information on Fast-start rollback.  

Access to Data Files for Instance Recovery

An instance performing recovery for another instance must have access to all online data files that the failed instance was accessing. When instance recovery fails because a data file fails verification, the instance that attempted to perform recovery does not fail but a message is written to the alert log file.

After you correct the problem that prevented access to the database files, use the SQL statement ALTER SYSTEM CHECK DATAFILES to make the files available to the instance.

See Also:


Steps of Oracle Instance Recovery

Figure 14-1 illustrates the degree of database availability during each step of Oracle instance recovery.

Figure 14-1 Steps of Oracle Instance Recovery

The steps involved in recovery are:

  1. Oracle Parallel Server is running on multiple nodes.

  2. Node failure is detected.

  3. The LM is reconfigured; resource and lock management is redistributed onto the set of surviving nodes. One call gets persistent resources. Lock value block is marked as dubious for locks held in exclusive or protected write mode. Lock requests are queued.

  4. LCKn processes build a list of all invalid lock elements.

  5. Roll forward. Redo logs of the dead threads are applied to the database.

  6. LCKn processes make all invalid lock elements valid.

  7. Roll back. Rollback segments are applied to the database for all uncommitted transactions.

  8. Instance recovery is complete and all data is accessible.

During step 5, forward application of the redo log, database access is limited by the transitional state of the buffer cache. The following data access restrictions exist for all user data in all data files, regardless of whether you are using high or low granularity locking or any particular features:

Oracle can read buffers already in the cache with the correct global lock because this does not involve any I/O or lock operations.

The transitional state of the buffer cache begins at the conclusion of the initial lock scan step when instance recovery is first started by scanning for dead redo threads. Subsequent lock scans are made if new "dead" threads are discovered. This state lasts while the redo log is applied (cache recovery) and ends when the redo logs have been applied and the file headers have been updated. Cache recovery operations conclude with validation of the invalid locks, which occurs after the buffer cache state is normalized.

Recovery from Media Failure

Media failure occurs when the storage medium for Oracle files is damaged. This usually prevents Oracle from reading or writing data after a media failure resulting in the loss of one or more database files, use backups of the data files to recover the database. If you are using Recovery Manager (RMAN), you may also need to apply incremental backups, archived redo log files, and a backup of the control file. If you are using operating system utilities, you might need to apply archived redo log files to the database and use a backup of the control file.

This section describes:

Complete Media Recovery

You can perform complete media recovery in either exclusive or shared mode. Table 14-1 shows the status of the database that is required to recover particular database objects.

Table 14-1 Database Status for Media Recovery
To Recover  Database Status 

An entire database or the SYSTEM tablespace. 

The database must be mounted but not opened by any instance.  

A tablespace other than the SYSTEM tablespace. 

The database must be opened by the instance performing the recovery and the tablespace must be offline. 

A data file. 

The database can be open with the data file offline, or the database can be mounted but not opened by any instance. (For a data file in the SYSTEM tablespace, the database must be mounted but not open.)  

You can recover multiple data files or tablespaces on multiple instances simultaneously.

Complete Media Recovery Using Operating System Utilities

With operating system utilities you can perform open database recovery of tablespaces or data files in shared mode. Do this using the RECOVER TABLESPACE or RECOVER DATAFILE statements.

You can use the RECOVER DATABASE statement to recover a database that is mounted in shared mode, but not open. Only one instance can issue this statement in Oracle Parallel Server.


The recommended method of recovering a database is to use RMAN. Oracle does not recommend use of the SQL statement ALTER DATABASE RECOVER.  

Incomplete Media Recovery

You can perform incomplete media recovery while the database is mounted in shared or exclusive mode providing it is not opened by an instance. Do this using the following database recovery options:

With RMAN use one of the following clauses with the SET statement before restoring and recovering:

With operating system utilities, restore your backups and then use one of the following clauses with the RECOVER DATABASE statement:

Restoring and Recovering Redo Log Files

Media recovery of a database accessed by Oracle Parallel Server may require the simultaneous opening of multiple archived log files. Because each instance writes redo log data to a separate redo thread, recovery may require as many as one archived log file per thread. However, if a thread's online redo log contains enough recovery information, restoring archived log files for that thread is unnecessary.

Recovery Using RMAN

RMAN automatically restores and applies the archive logs required. By default, RMAN restores archive logs to the LOG_ARCHIVE_DEST directory of the instances to which it connects. If you are using multiple nodes to restore and recover, this means that the archive logs may be restored to any of the nodes performing the restore/recover.

The node that reads the restored logs and performs the roll forward is the target node to which the connection was initially made. You must ensure that the logs are readable from that node using the following platform-specific methods.

Making Archive Logs Readable by All Nodes

For detailed procedures on how to configure this, refer to the Oracle8i Parallel Server Setup and Configuration Guide.

Recovery Using Operating System Utilities

During recovery, Oracle prompts you for the archived log files as they are needed. Messages supply information about the required files and Oracle prompts you for the filenames.

For example, if the log history is enabled and the filename format is LOG_T%t_SEQ%s, where %t is the thread and %s is the log sequence number, then you might receive these messages to begin recovery with SCN 9523 in thread 8:

ORA-00279: Change 9523 generated at 27/09/91 11:42:54 needed for thread 8 
ORA-00289: Suggestion : LOG_T8_SEQ438 
ORA-00280: Change 9523 for thread 8 is in sequence 438 
Specify log: {<RET> = suggested | filename | AUTO | FROM | CANCEL} 

If you use the ALTER DATABASE statement with the RECOVER clause, you receive these messages but not the prompt. Redo log files may be required for each enabled thread in Oracle Parallel Server. Oracle issues a message when a log file is no longer needed. The next log file for that thread is then requested, unless the thread was disabled or recovery is finished.

If recovery reaches a time when an additional thread was enabled, Oracle simply requests the archived log file for that thread. Whenever an instance enables a thread, it writes a redo entry that records the change; therefore, all necessary information about threads is available from the redo log files during recovery.

If recovery reaches a time when a thread was disabled, Oracle informs you that the log file for that thread is no longer needed and does not request further log files for the thread.


If Oracle reconstructs the names of archived redo log files, the format that LOG_ARCHIVE_FORMAT specifies for the instance doing recovery must be the same as the format specified for the instances that archived the files. All instances should use the same value of LOG_ARCHIVE_FORMAT in Oracle Parallel Server, and the instance performing recovery should also use that value. You can specify a different value of LOG_ARCHIVE_DEST during recovery if the archived redo log files are not at their original archive destinations. 

Disaster Recovery

This section describes disaster recovery using RMAN and operating system utilities. Disaster recovery is used when a failure makes an entire site unavailable. In this case, you can recover at an alternate site using open or closed database backups.


To recover up to the latest point in time, all logs must be available at a remote site; otherwise some committed transactions may be lost. 

Disaster Recovery Using RMAN

The following scenario assumes:

The SET UNTIL statement is used in case the database structure has changed in the most recent backups and you wish to recover to that point in time. In this way, RMAN restores the database to the same structure the database had at the specified time.

Before You Begin: Before beginning the database restore, you must:

What the Sample Script Does: The following script restores and recovers the database to the most recently available archived log, which is log 124 thread 1. It does the following:

Restore/Recover Sample Script:

Start SQL*Plus as follows:

   CONNECT scott/tiger AS SYSDBA 

Oracle responds with:


Enter the following STARTUP syntax:


Start RMAN and run the script.


The user specified in the target parameter must have SYSDBA privilege.  

   RUN { 
     ALLOCATE CHANNEL t1 TYPE 'SBT_TAPE' CONNECT 'internal/knl@node1'; 
     ALLOCATE CHANNEL t2 TYPE 'SBT_TAPE' CONNECT 'internal/knl@node1'; 
     ALLOCATE CHANNEL t3 TYPE 'SBT_TAPE' CONNECT 'internal/knl@node2'; 
     ALLOCATE CHANNEL t4 TYPE 'SBT_TAPE' CONNECT 'internal/knl@node2'; 
     CATALOG ARCHIVELOG '/oracle/db_files/node1/arch/arch_1_123.rdo'; 
     CATALOG ARCHIVELOG '/oracle/db_files/node1/arch/arch_1_124.rdo'; 

Disaster Recovery Using Operating System Utilities

To do this, use the following procedure:

  1. Restore the last full backup at the alternate site as described in the Oracle8i Backup and Recovery Guide.

  2. Start SQL*PLus.

  3. Connect as SYSDBA.

  4. Start and mount the database with the STARTUP MOUNT statement.

  5. Initiate an incomplete recovery using the RECOVER statement with the appropriate UNTIL clause.

    The following statement is an example:

  6. When prompted with a suggested redo log file name for a specific thread, use that filename.

    If the suggested archive log is not in the archive directory, specify where the file can be found. If redo information is needed for a thread and a file name is not suggested, try using archive log files for the thread in question.

  7. Repeat step 6 until all archive log files have been applied.

  8. Stop the recovery operation using the CANCEL statement.

  9. Issue the ALTER DATABASE OPEN RESETLOGS statement.


    If any distributed database actions are used, check to see whether your recovery procedures require coordinated distributed database recovery. Otherwise, you may cause logical corruption to the distributed data. 

Parallel Recovery

The goal of the parallel recovery feature is to use computed and I/O parallelism to reduce the elapsed time required to perform crash recovery, single-instance recovery, or media recovery. Parallel recovery is most effective at reducing recovery time when several data files on several disks are being recovered concurrently.

For RMAN, the restore and application of incremental backups are parallelized using channel allocation. The RECOVERY_PARALLELISM parameter determines the number of concurrent processes that participate in recovery. Setting RECOVERY_PARALLELISM to 0 or 1 invokes serial recovery.

Parallel Recovery Using RMAN

With RMAN's RESTORE and RECOVER statements, Oracle can automatically parallelize all three stages of recovery.

Restoring Data Files: When restoring data files, the number of channels you allocate in the RMAN recover script effectively sets the parallelism RMAN uses. For example, if you allocate 5 channels, you can have up to 5 parallel streams restoring data files.

Applying Incremental Backups: Similarly, when you are applying incremental backups, the number of channels you allocate determines the potential parallelism.

Applying Redo Logs: Oracle applies redo logs using a specific number of parallel processes as determined by your setting for the RECOVERY_PARALLELISM parameter.

The RECOVERY_PARALLELISM initialization parameter specifies the number of redo application server processes participating in instance or media recovery. During parallel recovery, one process reads the log files sequentially and dispatches redo information to several recovery processes that apply the changes from the log files to the data files. A value of 0 or 1 indicates that Oracle performs recovery serially. The value of this parameter cannot exceed the value of the PARALLEL_MAX_SERVERS parameter.

Parallel Instance Recovery

Parallel execution can also improve recovery processing. To use parallel execution for recovery, the parallel execution processes must be running when the instance starts up.

Set the PARALLEL_MIN_SERVERS parameter to establish the number of parallel execution servers available for parallel recovery. You can do this even if you do not intend to use parallel execution for the rest of your Oracle processing. Use the PARALLEL_MAX_SERVERS parameter to set a limit on the number of parallel execution processes available for recovery.

Media Recovery

The PARALLEL clause of the RECOVER DATABASE statement determines the degree of parallelism in media recovery. Media recovery uses the value for RECOVERY_PARALLELISM as a default degree of parallelism if the value for this parameter is non-zero and if you do not supply a value for RECOVERY_PARALLELISM in the RECOVER DATABASE statement. You can override this degree of parallelism with the PARALLEL clause of the RECOVER DATABASE statement.

For instance recovery, set the RECOVERY_PARALLELISM parameter to equal the number of parallel execution servers that you want to be available to assist SMON during recovery.

Parallel Recovery Using Operating System Utilities

You can parallelize instance and media recovery two ways by:

The Oracle Parallel Server can use one process to read the log files sequentially and dispatch redo information to several recovery processes to apply the changes from the log files to the data files. Oracle automatically starts the recovery processes, so you do not need to use more than one session to perform recovery.

Setting the RECOVERY_ PARALLELISM Parameter

The RECOVERY_PARALLELISM initialization parameter specifies the number of redo application server processes participating in instance or media recovery. One process reads the log files sequentially and dispatches redo information to several recovery processes. The recovery processes then apply the changes from the log files to the data files. A value of 0 or 1 indicates that recovery is performed serially by one process. The value of this parameter cannot exceed the value of the PARALLEL_MAX_SERVERS parameter.

Specifying RECOVER Statement Options

When you use the RECOVER statement to parallelize instance and media recovery, the allocation of recovery processes to instances is operating system specific. The DEGREE keyword of the PARALLEL clause can either signify the number of processes on each instance of a parallel server or the number of processes to spread across all instances.

See Also:

  • Oracle8i Concepts for more information on Fast-start parallel rollback

  • Oracle system-specific documentation for more information on the allocation of recovery processes to instances


Fast-Start Parallel Rollback in Oracle Parallel Server

Setting the initialization file parameter FAST_START_PARALLEL_ROLLBACK to LOW or HIGH enables Fast-start parallel rollback. This parameter helps determine the maximum number of server processes that participate in Fast-start parallel rollback. If the value is set to FALSE, Fast-start parallel rollback is disabled.

If the value for FAST_START_PARALLEL_ROLLBACK is set to LOW, the number of processes used for Fast-start rollback is twice the value of CPU_COUNT. If the value is HIGH, at most 4 times the value of CPU_COUNT is the number of rollback servers used for Fast-start parallel rollback.

In Oracle Parallel Server, multiple parallel recovery processes are owned by and operated only within the instance that generated them. To determine an accurate setting for FAST_START_PARALLEL_ROLLBACK, examine the contents of V$FAST_START_SERVERS and V$FAST_START_TRANSACTIONS.

Fast-start parallel rollback does not perform cross-instance rollback. However, it can improve the processing of rollback segments for a single database with multiple instances since each instance can spawn its own group of recovery processes.

Disaster Protection Strategies

You can protect Oracle Parallel Server systems against disasters by using standby databases, the Primary/Secondary Instance feature, and by following high availability practices for Oracle Parallel Server.

To simplify the administration of standby databases, consider using a managed standby database.

See Also:


Go to previous page Go to next page
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.