10
RMAN Tabl espace Point-in-Time Recovery (TSPITR)

All of these terms will be referenced throughout the remainder of this chapter.

How TSPITR Works With an RMAN-Managed Auxiliary Instance

To perform TSPITR of the recovery set using RMAN and an automated a uxiliary instance, you carry out the preparations for TSPITR described in "Planning and Preparing for TSPITR", and then issue the RECOVER TABLESPACE command, specifying, at a minimum, the tablespaces of the recovery set and the target time for the point-in-time recovery, and, if desired, an auxiliary destination as well.

RMAN then carries out the following steps:

1. If there is no connection to an auxiliary instance, RMAN creates the auxiliary instance , starts it up and connects to it.
2. Takes the tablespaces to be recovere d offline in the target database
3. Restores a backup controlfile from a p oint in time before the target time to the auxiliary instance
4. Restores the datafiles from the recovery set and the auxiliary set to the auxiliary instance. Files are restored either in locations you speci fy for each file, or the original location of the file (for recovery set files) or in the auxiliary destination (for auxiliary set fi les, if you used the AUXILIARY DESTINATION argument of RECOVER TABLESPACE)
5. Recovers the restored datafiles in the auxiliary instance to the specified time
6. Opens the auxiliary database with the RESETLOGS option
7. Exports the dictionary metadata about objects in the recovered tablespaces to the target database
8. Shuts down the auxiliary instance
9. Issues SWITCH commands on the target instance, so that the target database control file now po ints to the datafiles in the recovery set that were just recovered at the auxiliary instance.
10. Imports the dictionary metadata from the auxiliary instance to the target instance, allowing the recovered ob jects to be accessed.
11. Deletes all auxiliary set files.

At that point the TSPITR process is complete. The recovery set datafiles are returned to their conte nts at the specified point in time, and belong to the target database.

Deciding When to Use TSPITR

Like a table import, RMAN TSPITR enables you to recover a consistent data set; however, the data set recovered includes an entire tablespace rather than one object.

RMAN TSPITR is most useful for situat ions such as these:

• Recovering data lost after an erroneous TRUNCATE TABLE statement;
• Recovering from logical corr uption of a table;
• Undoing the effects of an incorrect batch job or other DML statement that has affected only a subset of the database;
• Recovering a logica l schema to a point different from the rest of the physical database, when multiple schemas exist in separate tablespaces of one phys ical database.

Note that, as with database point-in-time recovery (DBPITR), you canno t perform TSPITR if you do not have your archived redo logs. For databases running in NOARCHIVELOG mode, you cannot perform TSPITR.

Limitation s of TSPITR

There are a number of situations which you cannot resolv e by using TSPITR.

• You cannot recover dropped tablespaces.
• You cannot recover a renamed tablespace to a point in time before it was renamed. If you try to perform a TSPITR to an SCN earlier than the rename operation, RMAN cannot find the new tablespace name in the reposito ry as of that earlier SCN (because the tablespace did not have that name at that SCN).

  In this situation, you must recover the entire database to a point in time before the tablespace was renamed. The tablespace will be found under the name it had at that earlier time.

• You cannot recover table s without their associated constraints, or constraints without the associated tables.
• You cannot use TSPITR to recover any of the following:
  • Replicated master tables
  • Partial tables (for example, if you perform RMAN TS PITR on partitioned tables and spread partitions across multiple tablespaces, then you must recover all tablespaces which include par titions of the table.)
  • Tables with VARRAY columns, nested table s, or external files
  • Snapshot logs and snapshot tables
  • Tablespaces containing undo or rollback segments
  • Tablespaces that contain objects owned by SYS, including rollback segments

TSPITR has some other limitations:

• If a datafile was added after the point to which RMAN is recovering, an empty datafile by the same name will be included in the tablespace after RMAN TSPITR.
• TSPITR will not recover query optimizer statistics for rec overed objects. You must gather new statistics after the TSPITR.
• Assume that y ou run TSPITR on a tablespace, and then bring the tablespace online at time t. Backups of the tablespace crea ted before time t are no longer usable for recovery with a current control file. You cannot run TSPITR again on this tablespace to recover it to any time less than or equal to time t, nor can you use the current contro l file to recover the database to any time less than or equal to t. Therefore, you must back up the tablespac e as soon as TSPITR is complete.

Limitations of TSPITR Without a Recovery Catalog

If you do not use a recovery catalog when performing TSPITR, then note the following special restrictions:

• The undo segments at the time of the TSPITR must be part of the auxiliary set . Because RMAN has no historical record of the undo in the control file, RMAN assumes that the current rollback or undo segments were the same segments present at the time to which recovery is performed. If the undo segments have changed since that time, then TSPITR will fail.
• TSPITR to a time that is too old may not succeed if Oracle has reu sed the control file records for needed backups. (In planning your database, set the CONTROL_FILE_RECORD_KEEP_TIME initi alization parameter to a value large enough to ensure that control file records needed for TSPITR are kept.)
• When not using a recovery catalog, the current control file has no record of the older incarnation of the recovered tablespace. Thus, recovery with a current control file that involves this tablespace can no longer use a backup taken p rior to time t. You can, however, perform incomplete recovery of the whole database to any time less than or equal to t, if you can restore a backup control file from before time t.

Planning and Preparing for TSPITR

There are several steps to be carried out in preparing for TSPITR:

• Choosing the Right Target Time for TSPITR
• Determining the Recovery Set: Analyzing Data Relationships
• Identifying and Preserving Objects That Will Be Lost After TSPITR

Choosing the Right Target Time for TSPITR

It is extreme ly important that you choose the right target time or SCN for your TSPITR. As noted already, once you bring a tablespace online after TSPITR, you cannot use any backup from a time earlier than the moment you brought the tablespace online. In practice, this means tha t you cannot make a second attempt at TSPITR if you choose the wrong target time the first time, unless you are using a recovery cata log. (If you have a recovery catalog, however, you can perform repeated TSPITRs to different target times.)

For example, assume that you run TSPITR on a tablespace, and then bring the tablespace online at 5PM on Friday. Back ups of the tablespace created before 5PM Friday are no longer usable for recovery with a current control file. You cannot run TSPITR again on this tablespace with a target time earlier than 5PM Friday, nor can you use the current control file to recover the database to any time earlier than 5PM Friday. Your only option will be point-in-time recovery of your entire database using a restored contro l file.

To investigate past states of your data to identify the target time for TSPITR, you can use features of Oracle such as Oracle Flashback Query, Oracle Transaction Query and Oracle Flashback Version Query to find the p oint in time when unwanted database changes occurred. See "Oracle Flashback Query: Recovering at the R ow Level" for more details on Flashback Query, and Oracle Database Application Developer's Guide - Fundamentals for more information on Flashback Transaction Query and Flashback Version Query.

Determining the Recovery Set: Analyzing Data Relationships

Your recovery set starts out including the datafiles for the tablespaces you wish to recover. If, however, objects in the tablespaces you need have relationships (such as constraints) to objects in other ta blespaces, you will have to account for this relationship before you can perform TSPITR. You have three choices when faced with such a relationship:

• Add the tablespace including the related objec ts to your recovery set
• Remove the relationship
• Suspend the relationship for the duration of TSPITR

Identifying and Resolving Dependencies on the Primary Datab ase

The TS_PITR_CHECK view lets you identify relationsh ips between objects that span the recovery set boundaries. If this view returns rows when queried, then investigate and correct the p roblem. Proceed with TSPITR only when TS_PITR_CHECK view returns no rows for the tablespaces not in the recovery set. Record all actions performed during this step so that you can re-create any suspended or removed relationships after completing TSPITR.

The following query illustrates how to use the TS_PITR_CHECK view. For an example with an initial recovery set consisting of tools and users, the < code>SELECT statement against TS_PITR_CHECK would be as follows:

SELECT
 * 
FROM SYS.TS_PITR_CHECK 
WHERE (
        TS1_NAME IN ('USERS','T
OOLS') 
        AND TS2_NAME NOT IN ('USERS','TOOLS')
      )
OR
 (
        TS1_NAME NOT IN ('USERS','TOOLS') 
        AND TS2_NAME IN ('USERS','TOOLS')
<
a name="1009509">      );

To run a complete TSPITR check on a ll the tablespaces in the database (not just the tablespaces in the recovery set), you can run the following query:

SELECT *
FROM SYS.TS_PITR_CHECK
WHERE (

       'SYSTEM' IN (TS1_NAME, TS2_NAME)
         AND TS1_NAME <> TS2_NAME

AND TS2_NAME <> '-1'
      )
OR    (
         TS1_NAME <&g
t; 'SYSTEM' 
         AND TS2_NAME = '-1'
      );

Because of the number and width of the columns in the TS_PITR_CHECK view, you may want to format the columns as follows when running the query:

SET LINESIZE 120
COLUMN OBJ1_OWNER HEADING "own1"
COLUMN OBJ1_OWNER FORMAT a6
COLUMN OBJ1_NAME HEADING "
name1"
COLUMN OBJ1_NAME FORMAT a5
COLUMN OBJ1_SUBNAME HEADING "subname1"
COLUMN OBJ1_SUBNAME FORMAT a8
COLUMN OBJ1_TYPE HEADING "obj1type"
COLUMN OBJ1_TYPE
FORMAT a8 word_wrapped
COLUMN TS1_NAME HEADING "ts1_name"
COLUMN TS1_NAME FORMAT a6
COLUMN OBJ2_NAME HEADING "name2"
COLUMN OBJ2_NAME FORMAT a5
COLUMN OBJ2_
SUBNAME HEADING "subname2"
COLUMN OBJ2_SUBNAME FORMAT a8
COLUMN OBJ2_TYPE HEADING "obj2ty
pe"
COLUMN OBJ2_TYPE FORMAT a8 word_wrapped
COLUMN OBJ2_OWNER HEADING "own2"
COLUMN OBJ2_OWNER FORMAT a6
COLUMN TS2_NAME HEADING "ts2_name"
COLUMN TS2_NAME
FORMAT a6
COLUMN CONSTRAINT_NAME HEADING "cname"
COLUMN CONSTRAINT_NAME FORMAT a5
COLUMN REASON HEADING "reason"
COLUMN REASON FORMAT a25 word_wrapped




Assume a case in which the partitioned table tp has two partitions, p1 and p2, that exist in tablespaces users and tools respectively. Also assume that a partit
ioned index called tpind is defined on tp, and that the index has two partitions id1 and id2 (that exist in tablespaces id1 and id2 respectively). In this case, you would get the following
 output when TS_PITR_CHECK is queried against tablespaces users and tools (assuming appropriat
e formatting):

own1   name1 subname1 obj1type ts1_name name2 subname2 obj2type own2
ts2_name   cname reason
---    ----  -----    ------   -------  ----  ------   -------- ---       --------   --
-   ------ 
SYSTEM  TP   P1       TABLE    USER     TPIND IP1      INDEX    PARTITION PARTITION  SYS   ID1 Part
itioned 
Objects not fully contained in the recovery set
SYSTEM  TP   P2       TABLE    TOOLS    TPIND IP2
 INDEX    PARTITION PARTITION  SYS   ID2 Partitioned 
Objects not fully contained in the recovery set 




The table SYSTEM.tp has a partitioned index tpind that consists of tw
o partitions, ip1 in tablespace id1 and ip2 in tablespace id2. To perform TSPITR,
 you must either drop tpind or include id1 and id2 in the recovery set.

 



See Also:  
Oracle Database Reference for more
 information about the TS_PITR_CHECK view
 
Identifying and Preserving Objects That Will Be Lost After TSPI
TR

 
When RMAN TSPITR is performed on a tablespace, any objects create
d after the target recovery time are lost. You can preserve such objects, once they are identified, by exporting them before TSPITR u
sing an Oracle export utility (Data Pump Export or Original Export) and re-importing them afterwards using the corresponding import u
tility.
 
To see which objects will be lost in TSPITR, query the TS_PITR_OBJECTS_TO_BE_
DROPPED view on the primary database. The contents of the view are described in Table 10-1
.
 
 Table 10-1 TS_PITR_OBJECTS_TO_BE_DROPPED View  



 Column Name
 Meaning


 
OWNER
 
Owner of the object to be
dropped.

 
N
AME
 
The name of the object that will be lost as a result of
undergoing TSPITR

 
CREATION_TIME
 
Creation timestamp for the object.


 
TABLESPACE_NA
ME
 
Name of the tablespace containing the object.
 
Filter the view for objects whose CREATION_TIME is after the ta
rget time for TSPITR. For example, with a recovery set consisting of users and tools, and a recovery point
in time of November 2, 2002, 7:03:11 AM, issue the following statement:
SELECT OWNER, NAME,
 TABLESPACE_NAME, 
       TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS') 
       FROM TS
_PITR_OBJECTS_TO_BE_DROPPED 
WHERE TABLESPACE_NAME IN ('USERS','TOOLS') 
AND CREATION_TIM
E > TO_DATE('02-NOV-02:07:03:11','YY-MON-DD:HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;



(The TO_CHAR and TO_DATE functions are used to avo
id issues with different national date formats. You can, of course, use local date formats in your own work.)
<
/a> 



See Also:  
Oracle Database Reference for more
information about the TS_PITR_OBJECTS_TO_BE_DROPPED view
 
Performing Basic RMAN TSPITR

 
Having selected your tablespaces to recover and your target time, you are now ready to
perform RMAN TSPITR. You have a few different options available to you:

Fully automated TSPITR--in which you specify an auxiliary destination and let RMAN manage all
 aspects of the TSPITR. This is the simplest way to perform TSPITR, and is recommended unless you specifically need more control over
 the location of recovery set files after TSPITR or auxiliary set files during TSPITR, or control over the channel configurations or
some other aspect of your auxiliary instance.
Customized
TSPITR with an automatic auxiliary instance--in which you base your TSPITR on the behavior of fully automated TSPITR, possib
ly still using an auxiliary destination, but customize one or more aspects of the behavior, such as the location of auxiliary set or
recovery set files, or specifying initialization parameters or channel configurations for the auxiliary instance created and managed
by RMAN.
TSPITR with your own auxiliary instance
--in which you take responsibility for setting up, starting, stopping and cleaning up the auxiliary instance used in TSPITR, and poss
ibly also manage the TSPITR process using some of the methods available in customized TSPITR with an automatic auxiliary instance.
 
Fully
 Automated RMAN TSPITR

 
When performing fully automated TSPITR, letti
ng RMAN manage the entire process, there are only two requirements beyond the preparations in "Plannin
g and Preparing for TSPITR":

You must specify the auxiliary destination for RMAN to use for the auxiliary set datafiles and other files for the auxiliary in
stance.
You must configure any channels required for the TSPITR on the target
instance. (The auxiliary instance will use the same channel configuration as the target instance when performing the TSPITR.)
 
RMAN bases as much of the configuration for TSPITR as possible on your target database. Duri
ng TSPITR, the recovery set datafiles are written in their current locations on the target database. The same channel configurations
in effect on the target database are used on the auxiliary instance when restoring files from backup. Auxiliary set datafiles and oth
er auxiliary instance files, however, are stored in the auxiliary destination.
 
Using an Auxiliary Destination

 
Oracle Corporation recommends that you use an auxiliary destination with your auxiliary instance. Ev
en if you use other methods to rename some or all of the auxiliary set datafiles, specifying an AUXILIARY DESTINATION pa
rameter provides a default location for auxiliary set datafiles for which names are not specified. This way, TSPITR will not fail if
you inadvertently do not provide names for all auxiliary set datafiles.
 
To specify an auxil
iary destination, find a location on disk where there is enough space to hold your auxiliary set datafiles. Then, use the AUXIL
IARY DESTINATION parameter in your RECOVER TABLESPACE command to specify the auxiliary destination l
ocation, as shown in the next section.
 
Performing Fully Automated RMAN TSPITR

 
To actually peform automated RMAN TSPITR, start the RMAN client, connecting to the target database and, if applicable, a recovery ca
talog. This example shows connecting in NOCATALOG mode, using operating system authentication:

% rman TARGET /






Note:



Do not connect to an auxiliary instance when starting the RMAN client for automa
ted TSPITR. If there is no connected auxiliary instance, RMAN constructs the automatic auxiliary instance for you when carrying out t
he RECOVER TABLESPACE command. (If there is a connected auxiliary instance, RMAN will assume that you are trying to manage your own a
uxiliary instance, and try to use the connected auxiliary for TSPITR.)










If you have configured channels that RMAN can use to restore from backup on the primary instance, then you are ready to p
erform TSPITR now, by running the RECOVER TABLESPACE... UNTIL... command.
 
This
 example returns the users and tools tablespaces to the end of log sequence number 1300, and stores the auxiliary instance files (inc
luding auxiliary set datafiles) in the destination /disk1/auxdest:
RMAN> RE
COVER TABLESPACE users, tools 
     UNTIL LOGSEQ 1300 THREAD 1
      AUXILIARY DESTINATIO
N '/disk1/auxdest';




Assuming the TSPITR process completes without
 error, the tablespaces are taken offline by RMAN, restored from backup and recovered to the desired point in time on the auxiliary i
nstance, and then re-imported to the target database. The tablespaces are left offline at the end of the process. All auxiliary set d
atafiles and other auxiliary instance files are cleaned up from the auxiliary destination.
 
Tasks to Perform After Successful TSPITR

 
If TSPITR completes successfully, you must back up the recovered tablespaces,
and then you can bring them online.
 
Backing Up Recovered Tablespaces After TSPITR

 
It is very important that you backup recovered tablespaces immediately after TSPITR is completed.
 
After you perform TSPITR on a tablespace, you cannot use backups of that tablespace from before the TSPITR was completed
and the tablespace put back on line. If you start using the recovered tablespaces without taking a backup, you are running your datab
ase without a usable backup of those tablespaces. For this example, the users and tools tablespaces must be backed up, as follows:
RMAN> BACKUP TABLESPACE users, tools;




You can then safely bring the tablespaces online, as follows:
RMAN> SQL
"ALTER TABLESPACE users, tools ONLINE";




Your recovered tablespace
s are now ready for use.
 
Handling Errors in Automated TSPITR

 
In the event of
an error during automated TSPITR, you should refer to "Troubleshooting RMAN TSPITR". The auxiliary set datafiles and other auxiliary instance files will be left in place in the auxililary destinat
ion as an aid to troubleshooting. The state of the recovery set files is determined by the type of failure. Once you resolve the prob
lem, you can try your TSPITR operation again.
 
Performing Customized RMAN TSPITR with an RMAN-Managed Auxiliary Instance

 
There are several aspects of RMAN TSPITR which you can customize while still mostly follow
ing the basic procedure described in "Fully Automated RMAN TSPITR"<
/a>:


Renaming or relocating your recovery set datafiles, so th
at the datafiles making up the recovered tablespaces are not stored in the original locations after TSPITR
Specifying a location other than the auxiliary destination for some or all auxiliary set datafiles (or n
ot using an auxiliary destination at all)
Setting up image copy backups of you
r datafiles in advance, to speed up TSPITR by avoiding restores from backup
Us
ing a different channel configuration for the auxiliary instance
Specifying di
fferent initialization parameters for your RMAN-managed auxiliary instance
 
<
h3 class="H2">Renaming TSPITR Recovery Set Datafiles with SET NEWNAME

 
You may not want the recovery set datafiles restored and recovered in the
ir original locations. The SET NEWNAME command, used in a RUN block, lets you specify a new destination for the restore
from backup and recovery of a datafile.






Note<
/strong>:  
CONFIGURE AUXNAME can be used to rename recovery set dat
afiles as well, but the effects of doing so are quite different and the two commands cannot be used interchangeably. (They do interac
t, in that if you use SET NEWNAME to rename a file, this takes precedence over any renaming performed with CONFIGU
RE AUXNAME.) Refer to the discussion of "Using Image Copies for Faster TSPITR Perf
ormance" for details.





  
Create a RUN block and use SET NEWNAME commands within it to specify new recovery set filenames, as shown here
:
RUN {
...
   SET NEWNAME FOR DATAFILE 'ORACLE_HOME/oradata/trgt/users01.dbf'
      TO '/newfs/users01.dbf';
<
em class="Italic">...other setup commands...
   RECOVER TABLESPACE users, tools UNTIL SEQUENCE 1300 THREAD
 1;
}




RMAN restores the specified datafile
from backup to the new location during TSPITR and recovers it in the new location, and updates the control file so that the newly rec
overed datafile replaces the old one in the control file. Any existing image copy backup of a datafile found at the new specified loc
ation is overwritten.
 
If the name specified with SET NEWNAME conflicts with th
e name of a valid datafile in the target database, then RMAN reports an error while executing the RECOVER command. The v
alid datafile is not overwritten.
 
Note that RMAN does not detect conflicts between names se
t with SET NEWNAME and current datafile names on the target database until the actual RECOVER TABLESPACE... UNTIL<
/code> operation. At that point, the conflict is detected, TSPITR fails and RMAN reports an error. If you rename your recovery set da
tafiles, be sure to assign them names that do not conflict with each other, or with the names of your current datafiles.

 
Renaming TSPITR Auxil
iary Set Datafiles

 
Unlike the recovery set datafiles, which can be a
nd usually are stored in their original locations, the auxiliary set datafiles must not overwrite the corresponding original files in
 the target database. If you do not specify a location for an auxiliary set file that is different from its original location, then T
SPITR will fail when RMAN attempts to overwrite the corresponding file in the original database and discover that the file is in use.

 
The simplest way to provide locations for your auxiliary set datafiles is to specify an au
xiliary destination for TSPITR. However, RMAN supports two other methods of controlling the location of your auxiliary set datafiles:
 specifying new names for individual files with SET NEWNAME, and using DB_FILE_NAME_CONVERT to provide rule
s for converting datafile names in the target database to datafile names for the auxiliary database.
 
Even if you intend to use either of these methods to provide locations for specific files, it is still suggested that you p
rovide an AUXILIARY DESTINATION argument to RECOVER TABLESPACE. This will ensure that, if you overlook rena
ming some auxiliary set datafiles, your TSPITR will still succeed. Any files not otherwise renamed will be placed in the auxiliary de
stination.
 
Renaming TSPITR Auxiliary Set Datafiles with SET NEWNAME

 
To use th
e SET NEWNAME command to specify a new name for an auxiliary set datafile, enclose your RECOVER TABLESPACE command in a
RUN block, and use a SET NEWNAME command within the RUN block to rename the file. For example:
RMAN> RUN
{
  SET NEWNAME FOR DATAFILE '?/oradata/prod/system01.f'
    TO '/disk1/auxdest/system01.f'
  RECOVER TABLESPACE users, tools 
     UNTIL LOGSEQ 1300 THREAD 1
     AUXILIARY DESTINATION '/disk1/auxdest';
}




The resulting behavior depends upon whether there is a file at /disk
1/auxdest/system01.f when the RECOVER TABLESPACE command is executed. If there is an image copy backup of the fil
e ?/oradata/system01.f at the specified location, created at an SCN prior to the target time for TSPITR, then the behavi
or is as described in "SET NEWNAME and CONFIGURE AUXNAME With Auxiliary Set Image Copies". Otherwise, the auxiliary set datafile will be restored to the NEWNAME specified instead of the default lo
cation. If your intention is only to control where the auxiliary set datafiles are stored, you should make sure that there is no file
 stored at the location specified by SET NEWNAME before performing your TSPITR.
 
Using DB_FILE_NAME_CONVERT to Name Auxiliary Set
Datafiles

 
If you do not want to use an auxiliary destination for all
 of your auxiliary set datafiles, but you also do not want to name every file individually, you can include a DB_FILE_NAME_CONV
ERT initialization parameter in the initialization parameter file used by your auxiliary instance. You can only use this metho
d in two circumstances:

If you are creating your own initializ
ation parameter file for RMAN's automatically managed auxiliary instance, as described in "Customizing
 Initialization Parameters for the Automatic Auxiliary Instance";
If you are creating your own auxiliary instance, as described in "Performin
g RMAN TSPITR Using Your Own Auxiliary Instance".
 
Refer to the appropriate discussion for your circumstance, to see how to add a parameter to your initialization parameter file.
 
The DB_FILE_NAME_CONVERT parameter in the auxiliary instance specifies how to d
erive names for files in the auxiliary instance from the original names of the corresponding files in the target instance.
 
For example, assume that the target instance contains the following files:

?/oradata/trgt/system01.dbf of the SYSTEM tablespace
?/oradata/trgt/undotbs01.dbf of the undotbs tablespace

 
and you need to locate the corresponding files in the auxiliary instance in '/bigtmp<
/code>', then you would add the following line to the auxiliary instance parameter file:

DB
_FILE_NAME_CONVERT=('?/oradata/trgt', '/bigtmp')




The most importa
nt thing to remember is that DB_FILE_NAME_CONVERT needs to be present in the auxiliary instance parameter file.
 
If the auxiliary instance was manually created, add DB_FILE_NAME_CONVERT to the auxili
ary instance parameter file (wherever it resides).
 
Note that you can still rename individua
l auxiliary set datafiles using SET NEWNAME or CONFIGURE AUXNAME. Also, files that do not match the pattern
s provided in DB_FILE_NAME_CONVERT will not be renamed. You may wish to use the AUXILIARY DESTINATION param
eter of RECOVER TABLESPACE to ensure that all auxiliary set datafiles are sent to some destination. If a file is not ren
amed at all, TSPITR will fail.
 
Order of Precedence Among File Renaming Methods

 
The different methods of renaming files follow an order of precedence, as follows:

SET NEWNAME
CONFIGURE AUXNAME

DB_FILE_NAME_CONVERT
AUXILIARY DESTINATION argument to RECOVER TABLESPACE
 
Settings higher on the list override settings lower on the list, in situations where both have been applied (by, for example, r
unning RECOVER TABLESPACE... AUXILIARY DESTINATION on a target database where some auxiliary set datafiles also have aux
names configured with CONFIGURE AUXNAME).
 
Specifying Auxiliary Instance Control File Location

 
You can specify your own location for the control file of your auxiliary instance, if you use a client-
side initialization parameter file. Set the CONTROL_FILES initialization parameter to specify any location you wish for
the control files.
 
If you do not explicitly specify a location for the control file, RMAN w
ill locate it in the auxiliary destination if you use the AUXILIARY DESTINATION parameter when performing TSPITR. If you
 do not use an AUXILIARY DESTINATION parameter, the auxiliary instance control files are stored in an operating system-s
pecific location. (on Unix, ORACLE_HOME/rdbms/admin/params_auxinit.ora).
 
No matter where you store your auxiliary instance control file, it is removed at the end of a successful TSPITR oper
ation. Because control files are relatively small, it is rare that RMAN will encounter a problem creating an auxiliary control file,
but if there is not enough space to create the control file, TSPITR will fail.
 
Specifying Auxiliary Instance Online Log Location
<
!--/TOC=h3-->
 
If you specify the LOG_FILE_NAME_CONVERT initialization parameter in
 your auxiliary instance parameter file, this parameter will determine the online redo log location. Otherwise, if RMAN is using an a
uxiliary destination and managing the auxiliary instance for you, it creates the online redo log in the auxiliary destination.






Note:  
If you do no
t specify a location for the online redo logs using LOG_FILE_NAME_CONVERT or AUXILIARY DESTINATION, your TS
PITR will fail trying to create the online redo logs. Even if DB_FILE_CREATE_DEST or LOG_FILE_CREATE_DEST a
re specified in the initialization parameter file, in TSPITR they do not control the creation of the online redo logs of the auxiliar
y instance.