Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
If you have a read-only tablespace on read-only or slow media, then you may encounter errors or poor performance when recovering with the USING
BACKUP
CONTROLFILE
option. This situation occurs when the backup control file indicates that a tablespace was read/write when the control file was backed up. In this case, media recovery may attempt to write to the files. For read-only media, the database issues an error saying that it cannot write to the files. For slow media, such as a hierarchical storage system backed up by tapes, performance may suffer.
To avoid these recovery problems, use current control files rather than backups to recover the database. If you need to use a backup control file, then you can also avoid this problem if the read-only tablespace has not suffered a media failure.
You have these alternatives for recovering read-only and slow media when using a backup control file:
Take datafiles from read-only tablespaces offline before doing recovery with a backup control file, and then bring the files online at the end of media recovery.
Use the correct version of the control file for the recovery. If the tablespace will be read-only when recovery completes, then the control file backup must be from a time when the tablespace was read-only. Similarly, if the tablespace will be read/write at the end of recovery, then the control file must be from a time when the tablespace was read/write.
If a current or backup control file is unavailable for recovery, then you can execute a CREATE
CONTROLFILE
statement as described in "Create New Control File After Losing All Current and Backup Control Files". Read-only files should not be listed in the CREATE
CONTROLFILE
statement so that recovery can skip these files. No recovery is required for read-only datafiles unless you restored backups of these files from a time when the datafiles were read/write.
After you create a new control file and attempt to mount and open the database, the database performs a data dictionary check against the files listed in the control file. For each file that is not listed in the CREATE
CONTROLFILE
statement but is present in the data dictionary, an entry is created for them in the control file. These files are named as MISSING
nnnnn
, where nnnnn
is a five digit number starting with 0
.
After the database is open, rename the read-only files to their correct filenames by executing the ALTER
DATABASE
RENAME
FILE
statement for all the files whose name is prefixed with MISSING
.
To prepare for a scenario in which you might have to re-create the control file, run the following statement when the database is mounted or open to obtain the CREATE
CONTROLFILE
syntax:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
This SQL statement produces a trace file that you can edit and use as a script to re-create the control file. You can specify either the RESETLOGS
or NORESETLOGS
(default) keywords to generate CREATE
CONTROLFILE
...
RESETLOGS
or CREATE
CONTROLFILE
...
NORESETLOGS
versions of the script.
All the restrictions related to read-only files in CREATE
CONTROLFILE
statements also apply to offline normal tablespaces, except that you need to bring the tablespace online after the database is open. You should leave out tempfiles from the CREATE
CONTROLFILE
statement and add them after database open.
See Also:
Oracle Database Backup and Recovery Basics to learn how to make trace backups of the control file