Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 1 (10.1)
Part Number B10734-01

Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Feedback
Go to previous page
Previous< /font>		 Go to next page
Next
 View PDF

17
P erforming User-Managed Database Flashback and Recovery

This c hapter describes how to restore and recover a database. It includes the following topics:

User-Managed Backup and Flas hback Features of Oracle

Oracle's flashback features, which let you undo damage to your database after logical data corruption, include the following:

All of these operations are available within SQL*Plus, and none of them require the use of Recovery Manager. More details about usi ng the flashback features of Oracle in data recovery situations are provided in  "Oracle Flashbac k Technology: Overview".

Performing Flashback Database with SQL*Plus

The SQL*Plus FLASHBACK DATABASE command performs the same function as the RMAN FLAS HBACK DATABASE command: it returns the database to a prior state.

Note that using Fl ashback Database requires that you create a flash recovery area for your database and enable the collection of flashback logs. See "Oracle Flashback Database: Alternative to Point-In-Time Recovery" for more details about how the Flashback Database feature works, requirements for using Flashback Database , and how to enable coll ection of flashback logs required for Flashback Database. The requirements and preparations are the same whether you use RMAN or user -managed backup and recovery.

To perform the FLASHBACK DATABASE operation:

  1. Query the target database to determine the range of possible flashback SCNs. The f ollowing SQL*Plus queries show you the the latest and earliest SCN in the flashback window: 
    S
QL> SELECT CURRENT_SCN FROM V$DATABASE;

SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_F
LASHBACK_TIME 
     FROM V$FLASHBACK_DATABASE_LOG;
  2. Use other flashback features if necessary, to identify the SCN or time of the unwanted changes to yo ur database.
  3. Start SQL*Plus with administrator privileges, and run the FLASHBACK DATABASE statement to return the database to a prior TIMESTAMP or SCN. For example: 
    FLASHBACK DATABASE TO SCN 46963;
FLASHBACK DATABASE TO TIMESTAMP (SYSDA
TE-1/24);
FLASHBACK DATABASE TO TIMESTAMP timestamp'2002-11-05 14:00:00';
FLASHBACK DATAB
ASE 
  TO TIMESTAMP to_timestamp('2002-11-11 16:00:00', 'YYYY-MM-DD HH24:MI:SS');

    Open the database read-only to examine the results of the Flashback Database operation. When the operation completes, you can open the database read-only and perform some queries to make sure you have recovered the data you ne ed. If you find that you need to perform Flashback Database again to a different target time, then use RECOVER DATABASE to return the database back to the present time, and then try another FLASHBACK DATABASE statement.

    If you are satisfied with the results of Flashback Database, then you can re-open your database with the RESET LOGS option. If appropriate, you can also use an Oracle export utililty like Data Pump Export to save lost data, use RECOVER DA TABASE to return the database to the present, and re-import the lost object.

About User-Managed Restore Op erations

To restore a file is to replace it with a backup file. Typically, you restore a file when a media failure or user error has damaged or deleted the original file. The following files are ca ndidates for restore operations:

  • Datafiles and control files
  • Archived redo logs
  • Serve r parameter file

In each case, the loss of a primary file and the restore of a backup has the following implications for media recovery.

If you lose . . .< /strong> Then . . .

One or more datafiles

You must restore them from a backup and perform media recovery. Recovery is required whenever the checkpoint SCN in t he datafile header does not match the checkpoint SCN for the datafile that is recorded in the control file.

All copies of the current control fil e

You must restore a backup control file and then open the databa se with the RESETLOGS option.

If you do not have a backup, then you can attempt to re-create the control file. If possible, use the script included in the ALTER DATABASE BACKUP CONTROLFILE TO TRACE output. Additional work may be required to match the control file str ucture with the current database structure.

One copy of a multiplexed control file

Copy one of the intact multiplexed control files into the location of the damaged or missing control file and open the database . If you cannot copy the control file to its original location, then edit the initialization parameter file to reflect a new location or remove the damaged control file. Then, open the database.

One or more archived logs required for media recovery

You must restore backups of these archived logs for recovery to proceed. You can restore eithe r to the default or nondefault location. If you do not have backups, then you must performing incomplete recovery up to an SCN before the first missing redo log and open RESETLOGS.

The server parameter file

If you have a backup of the server parameter file, then restore it. Alternatively, if you have a backup of the client-side initialization parameter file, then you can restore a backup of this file, start the instance, and then re-create the server paramete r file.

Note:

Restore and recovery of Oracle-managed files is no different from restore and rec overy of user-named files.

Determining Which Datafiles Require Recovery

You can use the dynamic performance view V$RECOVER_FILE to determine whic h files to restore in preparation for media recovery. This view lists all files that need to be recovered and explains why they need to be recovered.

The following query displays the file ID numbers of datafiles that require media recovery as well as the reason for recovery (if known) and the SCN and time when recovery needs to begin:

SELECT * FROM V$RECOVER_FILE;

FILE#      ONLINE  ERROR
  CHANGE#    TIME     
---------- ------- ------------------ ---------- ---------

 14 ONLINE                              0          
        15 ONLINE  FILE NOT FOUND              0          
        21 OFFLINE OFFLINE NORMAL              0
Note:

The view is not useful if the c ontrol file currently in use is a restored backup or a new control file created after the media failure occurred. A restored or re-cr eated control file does not contain the information the database needs to populate V$RECOVER_FILE accurately.

Query V$DATAFILE and V$TABLESPACE to obtain fi lenames and tablespace names for datafiles requiring recovery. For example, enter:

SELECT d
.NAME, t.NAME AS tablespace_name
FROM V$DATAFILE d, V$TABLESPACE t 
WHERE t.TS# = d.TS# 
AND d.FILE# IN (14,15,21);  # use values obtained from V$RECOVER_FILE query

You can combine these queries in the following SQL*Plus script (sample output show in the following example):

COL df# FORMAT 999
COL df_name FORMAT a20
COL tbsp_name FORMAT a10
COL status FORMAT a7
COL error FORMAT a10
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, 
       d.STATUS, r.ERROR, r.CHANGE#, r.TI
ME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#
/

Restoring Datafiles and Archived Redo Logs

This section contains the following topics:

Resto ring Datafiles with Operating System Utilities

If a media failure pe rmanently damages one or more datafiles of a database, then you must restore backups of these datafiles before you can recover the da maged files. If you cannot restore a damaged datafile to its original location (for example, you must replace a disk, so you restore the files to an alternate disk), then you must indicate the new locations of these files to the control file.

< /a>

If you are restoring a database file on a raw disk or partition, then the procedure is basically the same as when restoring to a file on a file system. However, be aware of the naming conventions for files on raw devices (which differ depending on the operating system), and use an operating system utility that supports raw devices.
See Also:

"Making User-Managed Backups to Raw Devices" for an overview of considerations wh en backing up and restoring files on raw devices

To restore backup datafiles to their default location:

  1. < a name="1006334">Determine which datafiles to recover by using the techniques described in "Determi ning Which Datafiles Require Recovery".
  2. If the database is open, then take the tablespaces containing the inaccessible datafiles offline. For example, enter: 
    ALTER TABLESPACE users OFFLINE IMMEDIATE;
  3. Copy backups of the damaged datafiles to their default location using operating system commands. Fo r example, to restore users01.dbf you might issue: 
    % cp /disk2/backup/users01.db
f $ORACLE_HOME/oradata/trgt/users01.dbf
  4. Recover the affected tablespace. For example, enter: 
    RECOVER TABLESPACE users
  5. Bring the recovered tablespace online. For example, ent er: 
    ALTER TABLESPACE users ONLINE;

Restoring Archived Redo Logs with Operating System Uti lities

All archived redo logs generated between the time a restored backup was created and the target recovery time are required for the pending recovery. The archived logs will eventually need to be o n disk so that they are available to the database.

To restore necessar y archived redo logs:

  1. To determine wh ich archived redo log files are needed, query V$ARCHIVED_LOG and V$RECOVERY_LOG. If a datafile requires rec overy, but no backup of the datafile exists, then you need all redo generated starting from the time when the datafile was added to t he database.

    < tbody>
    View Description

    V$ARCHIVED_LO G

    Lists filenames for all the archived logs.

    V$RECOVERY_LOG

    Lists only the archived redo logs that the database needs to p erform media recovery. It also includes the probable names of the files, using LOG_ARCHIVE_FORMAT.

    Note: This view is only populated when recovery is required for a datafile. Hence, this view is not useful in the case of a planned recovery such as a user error.

  2. If space is available, then restore the required archived redo log files to the location speci fied by LOG_ARCHIVE_DEST_1. The database locates the correct log automatically when required during media recovery. For example, enter: 
    % cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch
  3. If sufficient space is not available at the location indicated by t he archiving destination initialization parameter, restore some or all of the required archived redo log files to an alternate locati on. Specify the location before or during media recovery using the LOGSOURCE parameter of the SET statement in SQL*Plus or the RECOVER ... FROM parameter of the ALTER DATABASE statement in SQL. For example, enter: 
    SET LOGSOURCE /tmp   # set location using SET statemen
t
  DATABASE RECOVER FROM '/tmp';  # set location in RECOVER statement
  4. After an archived log is applied, and after making sure that a copy of each arch ived log group still exists in offline storage, delete the restored copy of the archived redo log file to free disk space. For exampl e: 
    % rm /tmp/*.dbf
    See Also:

    Oracle Database Reference for more information about the dat a dictionary views, and "About User-Managed Media Recovery" for a n overview of log application during media recovery

Restoring Control Files

This section contains the following topics:

Lo sing a Member of a Multiplexed Control File

Use the following proced ures to recover a database if a permanent media failure has damaged one or more control files of a database and at least one control file has not been damaged by the media failure.

Copying a Multiplexed Control File to a Default L ocation

If the disk and file system containing the lost con trol file are intact, then you can simply copy one of the intact control files to the location of the missing control file. In this c ase, you do not have to alter the CONTROL_FILES initialization parameter setting.

To replace a damaged control file by copying a multiplexed control file:

  1. If the instance is still running, then shut it down: 
    <
a name="1006414">SHUTDOWN ABORT
  2. Corr ect the hardware problem that caused the media failure. If you cannot repair the hardware problem quickly, then proceed with database recovery by restoring damaged control files to an alternative storage device, as described in "Copying a Multiplexed Control File to a Nondefault Location".
  3. Use an intact multiplexed copy of the database's current control file to copy over the damaged control files. F or example, to replace bad_cf.f with good_cf.f, you might enter: 
    %
cp /oracle/good_cf.f /oracle/dbs/bad_cf.f
  4. Start a new instance and mount and open the database. For example, enter: 
    STARTUP

Copying a Multiplexed Control File to a Nondefault Location

Assuming that the disk and file system containing the lost control file are not intact, then you cannot copy one of the good control files to the location of the missing control file. In this case, you must alter the CONTROL_FILES initi alization parameter to indicate a new location for the missing control file.

To restore a control file to a nondefault location:

  1. If the instance is still running, then shut it down: 
    SHUTDOWN ABORT
  2. If you cannot correct the hardware problem that caused the media failure, then copy the intact control file to alternative locations. For example, to copy a good version of control01.dbf to a new disk location you might issue: 
    % cp $ORACLE_HOME/oradata/trg
t/control01.dbf /new_disk/control01.dbf
  3. Edit the parameter file of the database so that the CONTROL_FILES parameter reflects the current locations of all contro l files and excludes all control files that were not restored. Assume the initialization parameter file contains: 
    <
a name="1006442">CONTROL_FILES='/oracle/oradata/trgt/control01.dbf','/bad_disk/control02.dbf'

    Then, you can edit it as follows:

    CONTROL_FILES='/oracle
/oradata/trgt/control01.dbf','/new_disk/control02.dbf'
  4. Start a new instance and mount and open the database. For example: 
    STARTUP

Losing All Current Control Files When a Backup Is Available

Use the following procedures to restore a backup control file if a permanent media failure has damaged all control files of a database and y ou have a backup of the control file. When a control file is inaccessible, you can start the instance, but not mount the database. If you attempt to mount the database when the control file is unavailable, then you receive this error message:

ORA-00205: error in identifying controlfile, check alert log for more info

You cannot mount and open the database until the control file is accessible again. If you restore a bac kup control file, then you must open RESETLOGS.

As indicated in Table 17-1, the procedure for restoring the control file depends on whether the online redo logs are availab le.

Table 17-1 Scenarios When Control Files Are Lost
Status of Online Logs Status of Datafiles Response

Available

Current

If the online logs contain redo necessary for re covery, then restore a backup control file and apply the logs during recovery. You must specify the filename of the online logs conta ining the changes in order to open the database. After recovery, open RESETLOGS.

Unavailable

Current

If the online logs contain redo nece ssary for recovery, then re-create the control file. Because the online redo logs are inaccessible, open RESETLOGS (when the online logs are accessible it is not necessary to OPEN RESETLOGS after recovery with a created control file).

Availabl e

Backup

Restore a backup control file, perform complete recovery, and then open RESETLOGS.

Unavailable

Backup

Restore a backup control fi le, perform incomplete recovery, and then open RESETLOGS.

Restoring a Backup Control File to the Defaul t Location

If possible, restore the control file to its original loc ation. In this way, you avoid having to specify new control file locations in the initialization parameter file.

To restore a backup control file to its default location:

  1. If the instance is still running, shut it down: 
    SHUTDOWN AB
ORT
  2. Correct the hardware problem that ca used the media failure.
  3. Restore the backup control file to all location s specified in the CONTROL_FILES parameter. For example, if ORACLE_HOME/oradata/trgt/control 01.dbf and ORACLE_HOME/oradata/trgt/control02.dbf are the control file locations listed in the server parameter file, then use an operating system utility to restore the backup control file to these locations: 
    % cp /backup/control01.dbf ORACLE_HOME/oradata/trgt/control01.dbf
% cp /backup/control02.dbf ORACLE_HOME/oradata/trgt/control02.dbf
    4. Start a new instance and mount the database. For example, enter: 
    STARTUP MOUNT
  4. Begin recovery by executing the RECOVER command with the USING BACKUP CONTROLFILE clause. Specify UNTIL CANCEL if you are performing incomplete recovery. For example, enter: 
    RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
  5. Apply the prompted archived logs. If you then receive another message saying that the requ ired archived log is missing, it probably means that a necessary redo record is located in the online redo logs. This situation can o ccur when unarchived changes were located in the online logs when the instance crashed.

    For example, assume that you see the following:

    ORA-00279: change 55636 generated at 11/0
8/2002 16:59:47 needed for thread 1
ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arc
ORA-00280: change 55636 for thread 1 is in sequence #111
Specify log: {<RET>=suggested | filename
 | AUTO | CANCEL}

    You can specify the name of an online redo log and press Enter (you may have to try this a few times until you find the correct log):

    ORACLE_HOME/oradata/redo01.dbf
Log applied.
Media recovery complete
.

    If the online logs are inaccessible, then you can cancel recov ery without applying them. If all datafiles are current, and if redo in the online logs is required for recovery, then you cannot ope n the database without applying the online logs. If the online logs are inaccessible, then you must re-create the control file (refer to "Losing All Current and Backup Control Files").

  6. Open the database with the RESETLOGS option after finishing recover y: 
    ALTER DATABASE OPEN RESETLOGS;

Restoring a Backup Control File to a Nondefault Locatio n

If you cannot restore the control file to its original place becau se the media damage is too severe, then you must specify new control file locations in the server parameter file. A valid control fil e must be available in all locations specified by the CONTROL_FILES initialization parameter. If not, then the database prevents you from the mounting the database.

To restore a control file to a nondefault location:

Follow the steps in "Rest oring a Backup Control File to the Default Location", except after step 2 add the following ste p:

Edit all locations specified in the CONTROL_FILES initialization parameter to reflect the new control file locations. For example, if the control file locations listed in the server parameter file are as foll ows, and both locations are inaccessible:

CONTROL_FILES='/oracle/oradata/trgt/control01.dbf
',
              '/oracle/oradata/trgt/control01.dbf'

Then, you can edit the initialization parameter file as follows:

CONTROL_FILES=
'/good_disk/control01.dbf','/good_disk/control02.dbf'

Losing All Current and Backup Control Files

If all control files have been lost in a permanent media failure, but all online redo log members remain inta ct, then you can recover the database after creating a new control file. The advantage of this tactic is that you are not required to open the database with the RESETLOGS option.

Dependin g on the existence and currency of a control file backup, you have the options listed in Table 17- 2 for generating the text of the CREATE CONTROLFILE statement. Note that changes to the database are re corded in the alert_SID.log, so check this log when deciding which option to choose .

Table 17-2 Options for Creating the Control File (Page 1 of 2)
If you . . . Then . . .

Executed ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS after you made the last structural change to the database, and if you have save d the SQL command trace output

Use the CREATE CO NTROLFILE statement from the trace output as-is.

Performed your most recent execution of ALTER DATABASE BACKUP CONTROLFILE TO TRACE before you made a structural change to the database

Edit the output of ALTER DATABASE BACKUP CONTROLFILE TO TRACE to reflect the change. For example, if you recently added a datafile to t he database, then add this datafile to the DATAFILE clause of the CREATE CONTROLFILE statement .

Backed up the control file with the ALTER DATABASE BACKUP CONTROLFILE TO filename statement (not the TO TRACE option)

Use the control file copy to obtain SQL output. Create a temporary database instance, mount the backup control file, and then run ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS. If the control file copy predated a recent structural change, then edit the trace to reflect the change.< /p>

Do not have a co ntrol file backup in either TO TRACE format or TO filename format

Execute the CREATE CONTROLFILE statement manual ly (refer to Oracle Database SQL Reference).

Note:

If your character set is not the default US7ASCII, then you mus t specify the character set as an argument to the CREATE CONTROLFILE statement. The database character set is written to the alert log at startup. The character set information is also recorded in the BACKUP CONTROLFILE TO TRACE output.

To create a new control file:

  1. Start the database in NOMOUNT mode. For example, enter: 
    STARTUP NOMOUNT
  2. Create the control file with the CREATE CONTROLFILE statement, specifying the NORESETLOGS option (refer to Tabl e 17-2 for options). The following example assumes that the character set is the default US7ASCII: 
    CREATE CONTROLFILE REUSE DATABASE SALES NORESETLOGS ARCHIVELOG
     MAXLOGFILES 32
     MAXLOGMEMBERS 2
     MAXDATAFILES 32
     MAXINSTANCES 16
     MAXLOGHISTORY 1600
LOGFILE
     GROUP 1 (
       '/diska/
prod/sales/db/log1t1.dbf',
       '/diskb/prod/sales/db/log1t2.dbf'
     )  SIZE 100K
     GROUP 2 (
       '/diska/prod/sales/db/log2t1.dbf',
       '/disk
b/prod/sales/db/log2t2.dbf'
     )  SIZE 100K,
DATAFILE
     '/disk
a/prod/sales/db/database1.dbf',
     '/diskb/prod/sales/db/filea.dbf';

After creating the control file, the instance mounts the database.

Checking the Alert Log After a RESETLOGS O peration

After opening the database with the RESETLOGS option, check the alert_SID.log to see whether the database detected inconsistencies between the data dictionary and the control file, for example, a datafile that the data dictionary includes but which is not listed i n the new control file. The following table describes two possible scenarios.

Control File< /strong> Data Dictionary Result

Datafile is listed

Datafile is not listed

Ref erences to the unlisted datafile are removed from the control file. A message in the alert log indicates what was found.

Datafile is not listed

Datafile is listed

The database creates a placeholder entry in the control file under MISSINGnnnnn< /em> (where nnnnn is the file number in decimal). MISSINGnnnnn is flagge d in the control file as offline and requiring media recovery. You can make the datafile corresponding to MISSINGnnnnn accessible by using ALTER DATABASE RENAME FILE for M ISSINGnnnnn so that it points to the datafile. If you do not have a backup of this datafile, then drop the tablespace.

Recovering a Database in NOARCHIVELOG Mode

If a media failure damages datafiles in a NOARCHIVELOG database, then the only option fo r recovery is usually to restore a consistent whole database backup. If you are using logical backups created by an Oracle export uti lity to supplement regular physical backups, then you can also attempt to restore the database by importing an exported backup of the database into a re-created database or a database restored from an old backup.

Restoring a NOARCHIVELOG Database to its Default Location

In this scenario, the media failure is repaired so that you are able to restore all database files to their original location.

To restore the most recent whole database backup to the default location:

  1. If the database is open, then shut down the database. For example, enter: 
    <
/a>SHUTDOWN IMMEDIATE
  2. If possible, corre ct the media problem so that the backup database files can be restored to their original locations.
  3. Restore the most recent whole database backup with operating system commands as described in "Restoring Datafiles and Archived Redo Logs". Restore all of the datafiles a nd control files of the whole database backup, not just the damaged files. The following example restores a whole database backup to its default location: 
    % cp /backup/*.dbf $ORACLE_HOME/oradata/trgt/ 

<
/pre>
  4. Because online redo logs are not backed up, you cannot restore t hem with the datafiles and control files. In order to allow the database to reset the online redo logs, you must first mimic incomple te recovery: 
    RECOVER DATABASE UNTIL CANCEL
CANCEL
  5. Open the database in RESETLOGS mode: 
    ALTER DATABASE OPEN RESETLOGS;

Restoring a NOARCHIVELOG Database to a New Location

In this scenario, you restore the database files to an alternative location because t he original location is damaged by a media failure.

To restore the mos t recent whole database backup to a new location:

  1. If the database is open, then shut it down. For example, enter: 
    SHUTDOWN IMMEDIA
TE
  2. Restore all of the datafiles and cont rol files of the whole database backup, not just the damaged files. If the hardware problem has not been corrected and some or all of the database files must be restored to alternative locations, then restore the whole database backup to a new location. For example, enter: 
    % cp /backup/*.dbf /new_disk/oradata/trgt/
  3. If necessary, edit the restored parameter file to indicate the new location of the control files. For example: 
    CONTROL_FILES = "/new_disk/oradata/trgt/control01.dbf"
  4. Start an instance using the restored and edited p arameter file and mount, but do not open, the database. For example: 
    STARTUP MOUNT
  5. If the restored datafile filenames will be differe nt (as will be the case when you restore to a different file system or directory, on the same node or a different node), then update the control file to reflect the new datafile locations. For example, to rename datafile 1 you might enter: 
    ALTER DATABASE RENAME FILE '?/oradata/trgt/system01.dbf' TO

   '/new_disk/oradata/system01.dbf';
  6. If the online redo logs were located on a damaged disk, and the hardware problem is not corrected, then specify a new location for each affected online log. For example, enter: 
    ALTER DATABASE RENAME FILE '?/oradata/trgt/redo01.lo
g' TO
                           '/new_disk/oradata/redo_01.log';
ALTER DATABASE RENAME F
ILE '?/oradata/trgt/redo02.log' TO
                           '/new_disk/oradata/redo_02.log';
  7. Because online redo logs are not backed up, you cannot r estore them with the datafiles and control files. In order to allow the database to reset the online redo logs, you must first mimic incomplete recovery: 
    RECOVER DATABASE UNTIL CANCEL;
CANCEL;
  8. Open the database in RESETLOGS mode. T his command clears the online redo logs and resets the log sequence to 1: 
    ALTER DATABASE OPEN
 RESETLOGS;

    Note that restoring a NOARCHIVELOG data base backup and then resetting the log discards all changes to the database made from the time the backup was taken to the time of th e failure.

    See Also:

    Oracle Database Administrator's Guide for more information about renaming and relocating datafiles, and Oracle Database SQL Reference to l earn about ALTER DATABASE RENAME FILE

Performing Media Recovery in Parallel

Use parallel media recovery to tune the roll forward phase of media recovery. In parallel media recovery, the database u ses a "division of labor" approach to allocate different processes to different data blocks while rolling forward, thereby making the procedure more efficient. For example, if parallel recovery is performed with PARALLEL 4, and only one dat afile is recovered, then four spawned processes read blocks from the datafile and apply records instead of only one process.

Typically, recovery is I/O-bound on reads to data blocks. Parallelism at the block level may only h elp recovery performance if it increases total I/Os, for example, by bypassing operating system restrictions on asynchronous I/Os. Sy stems with efficient asynchronous I/O see little benefit from parallel media recovery.

The SQL*Plus RECOVER PARALLEL command specifies parallel media recovery (the default is NOPARALLEL ). This command selects a degree of parallelism equal to the number of CPUs available on all participating instances times the value of the PARALLEL_THREADS_PER_CPU initialization parameter.

The format for the < code>RECOVER PARALLEL command is the following:

RECOVER PARALLEL in
teger;

The integer variable sets the n umber of recovery processes used for media recovery. If you use a Real Application Clusters configuration, then the database decides how to distribute these recovery processes among the instances. If integer is not specified, then the database picks a default number of recovery processes.

Note:

The RECOVERY_PARALLELISM initialization parameter specifies the number of concurrent recovery processes for instance or crash recovery only. Media recovery is not affected.

See Also:
Go to previous page
Previous		 Go to next page
Next
Oracle
Copyright © 2003 Oracle Corporation
All Rights Reserved.
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Content s		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Feedback