Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
A variety of problems can cause TSPITR to fail before the process is complete.
There can be name conflicts between files already in the target database, filenames assigned by the SET NEWNAME
or CONFIGURE AUXNAME
commands, and filenames generated by the effect of the DB_FILE_NAME_CONVERT
parameter.
When RMAN exports the metadata about recovered objects from the auxiliary instance, it uses space in the temporary tablespace for sorting. If there is insufficient space in the temporary tablespace for the sorting operation, you need to increase the amount of sort space available.
If your uses of SET NEWNAME
, CONFIGURE AUXNAME
and DB_FILE_NAME_CONVERT
cause multiple files in the auxiliary or recovery sets to have the same name, RMAN will report an error during TSPITR. To correct the problem, use different values for these parameters to eliminate the duplicate name.
In this case, you need to edit the recover.bsq
file, wherever it resides on your host platform. For instance, on UNIX, it is located in $ORACLE_HOME/rdbms/admin
. This file contains the following:
# # tspitr_7: do the incomplete recovery and resetlogs. This member is used once. # define tspitr_7 <<< # make the control file point at the restored datafiles, then recover them RECOVER CLONE DATABASE TABLESPACE &1&; ALTER CLONE DATABASE OPEN RESETLOGS; # PLUG HERE the creation of a temporary tablespace if export fails due to lack # of temporary space. # For example in Unix these two lines would do that: # sql clone "create tablespace aux_tspitr_tmp # datafile ''/tmp/aux_tspitr_tmp.dbf'' size 500K"; } >>>
Remove the '#' symbols from the last two lines of comments and modify the statement to create a temporary tablespace. Retry the TSPITR operation, increasing the size of the tablespace until the export operation succeeds.
During TSPITR, RMAN needs information about which tablespaces had undo segments at the TSPITR target time. This information is usually available in the recovery catalog, if one is used.
If there is no recovery catalog, or if the information is not found in the recovery catalog, RMAN proceeds assuming that the set of tablespaces with undo segments at the target time is the same as the set of tablespaces with undo segments at the present time. If this assumption is not correct, TSPITR will fail with an error. In such a case, use the UNDO
TABLESPACE
clause to provide a list of tablespaces with undo segments at the target time.
If you are managing your own auxiliary instance and there is a failure in TSPITR, then before you can try TSPITR again, you must shut down the auxiliary instance, correct the problem which interfered with TSPITR, and then bring the auxiliary instance back to NOMOUNT before trying TSPITR again.