Release 2 (8.1.6)
Part Number A76970-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Parallel Server Administration, Deployment, and Performance Release 2 (8.1.6) Part Number A76970-01 |
|
This chapter describes Oracle recovery features on Oracle Parallel Server. It covers the following topics:
This chapter discusses three types of recovery:
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.
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.
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 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.
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.
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.
Figure 14-1 illustrates the degree of database availability during each step of Oracle instance recovery.
The steps involved in recovery are:
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.
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:
Oracle8i Backup and Recovery Guide for procedures to recover from various types of media failure.
See Also:
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.
You can recover multiple data files or tablespaces on multiple instances simultaneously.
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.
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:
Oracle8i Backup and Recovery Guide for more information on the use of the SET and RECOVER DATABASE statements.
See Also:
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.
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.
For detailed procedures on how to configure this, refer to the Oracle8i Parallel Server Setup and Configuration Guide.
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.
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.
The following scenario assumes:
|
Note: It is highly advisable to back up the database immediately after opening the database reset logs, because all previous backups are invalidated. This step is not shown in this example. |
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:
The archive logs up to the logseq number being restored must be cataloged in the recovery catalog, or RMAN will not know where to find them.
If you resynchronize the recovery catalog frequently, and have an up-to-date copy from which you have restored, there should not be many archive logs that need cataloging.
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:
If volume names have changed, you must use the statement SET NEWNAME FOR... before the restore, then perform a switch after the restore. This updates the control file with the data files' new locations.
RMAN completes the recovery when it reaches the log sequence number specified.
Restore/Recover Sample Script:
Start SQL*Plus as follows:
CONNECT scott/tiger AS SYSDBA
Oracle responds with:
Connected.
Enter the following STARTUP syntax:
STARTUP NOMOUNT RESTRICT
Start RMAN and run the script.
RMAN TARGET scott/tiger@node1 RCVCAT RMAN/RMAN@RCAT RUN { SET UNTIL LOGSEQ 124 THREAD 1; 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'; ALLOCATE CHANNEL d1 TYPE DISK; RESTORE CONTROLFILE; ALTER DATABASE MOUNT; CATALOG ARCHIVELOG '/oracle/db_files/node1/arch/arch_1_123.rdo'; CATALOG ARCHIVELOG '/oracle/db_files/node1/arch/arch_1_124.rdo'; RESTORE DATABASE; RECOVER DATABASE; SQL 'ALTER DATABASE OPEN RESETLOGS'; }
To do this, use the following procedure:
The following statement is an example:
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
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.
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.
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 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.
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.
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.
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.
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:
|
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.
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:
|
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|