Sei sulla pagina 1di 13

RMAN DUPLICATE / RESTORE including Standby in ASM with OMF / non-OMF To

/ Mixed Name for Datafile / Online Log / Controlfile (Doc ID 1910175.1) Bottom

In this Document

Goal
Solution
General Recommendations
Background Concepts
OMF in ASM
Uniqueness of an ASM file
File Name Conversion during Cloning
Valid Format for DB_FILE_NAME_CONVERT / LOG_FILE_NAME_CONVERT
Use Cases
1) Handling of Control Files in ASM OMF format
2) Handling of Control Files in ASM non-OMF format
3) Handling of Control Files in Mixed Names format (OMF
and non-OMF)
4) All Datafiles in ASM OMF
5) Datafiles in mixed format, some files in ASM OMF and
some in non-OMF format
6) All Redo Log members in ASM OMF format
7) Redo Log members in mixed format, i.e. some in ASM
OMF format and some in non-OMF format
8) All Redo Log members in ASM non-OMF format
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.1 and later


Information in this document applies to any platform.
GOAL

The objective of this Document is to illustrate RMAN DUPLICATE / RESTORE / Manual


Clone when source and destination (auxiliary) use ASM diskgroup for database files including
OMF and/or non-OMF names.

SOLUTION

General Recommendations
1) All files in ASM should be in OMF (Oracle Managed Files) format. There are several
advantages of using OMF, some of which are:

They make the administration of the database easier.


They reduce corruption caused by administrators specifying the wrong file.
They reduce wasted disk space consumed by obsolete files.
They simplify creation of test and development databases.

2) Avoid using combination of OMF files and non-OMF (i.e. User Managed File Names) in a
database as it's difficult to manage particularly for cloning. Below example shows this situation:

SQL> select file#, name from v$datafile ;

FILE# NAME
------ --------------------------------------------------
1 +DATA/prod/datafile/system.127.5329108
2 +DATA/prod/datafile/sysaux.128.5329108 <(========== OMF files
3 +DATA/prod/datafile/undotbs01.129.5329108
4 +DATA/prod/datafile/users01.130.5329108
5 +DATA/prod/datafile/sales01.dbf <(================= non-OMF file

3) To perform Database cloning (using DUPLICATE or MANUAL Restore/Recovery) of a


database having some or all non-OMF files, it is still recommended to create clone database with
all OMF Files by using appropriate steps, as we discuss in this Article with several use cases.

Background Concepts
OMF in ASM

In ASM diskgroups, all files are created as OMF to ensure uniqueness. A typical format of an
OMF file in ASM is:
+group/dbname/file_type/file_type_tag.file#.incarnation#

if a non-OMF name is provided for a file creation, Oracle ASM code internally creates an OMF
File and automatically creates an alias with user defined non-OMF name for the same, e.g. :

ASMCMD> ls -l +DATA01/prod/controlfile/control01.ctl
Type Redund Striped Time Sys Name
N control01.ctl =>
+DATA1/prod/controlfile/current.258.850633487

We can also manually create user defined non-OMF alias for a OMF file, e.g. :

The following statement adds a new alias name for a system-generated file name:

SQL> ALTER DISKGROUP DATA01 ADD ALIAS '+DATA01/mydir/myfile.dbf' FOR


'+DATA01/uat/datafile/salestbs01.342.782872493' ;

Uniqueness of an ASM file

A typical ASM file name is in the format:

+group/dbname/file_type/file_type_tag.file#.incarnation#

Where:

+group is the disk group name preceded by a plus sign.

You can think of the plus sign (+) as the root directory of the ASM file system, similar to the
slash (/) on UNIX or Linux computers.

dbname is the DB_UNIQUE_NAME of the database to which the file belongs.

file_type is the Oracle file type, e.g. datafile, controlfile, onlinelog, etc.

file_type_tag is type specific information about the file, e.g. tablespace name for datafile.

file#.incarnation# is the file/incarnation pair, used to ensure uniqueness within the


diskgroup
Example:

+DATA1/prod/controlfile/current.258.850633487

Uniqueness of above File is : +DATA1.258.850633487

Hence, all below filenames actually refer the same above file, just with different representation,
as long as the Diskgroup, file# and incarnation# remains same:

+DATA1/prod/controlfile/mycontrolfile.258.850633487
+DATA1/uat/controlfile/mycontrolfile2.258.850633487
+DATA1/uat/mydir/mycontrol01.258.850633487
+DATA1/control01.258.850633487
+DATA1/uat/controlfile/control02.258.850633487
+DATA1/control02.258.850633487

For more details, refer below Documentation:

Administering Oracle ASM Files, Directories, and Templates

File Name Conversion during Cloning

For OMF File names in ASM, the order of precedence to create file name is:

SET NEWNAME
DB_FILE_NAME_CONVERT (not applicable for manual RESTORE command)
File with same name already exists, i.e. name conversion will not take place and existing
file will get overwritten. Please note that existence is check with
uniquenessDiskgroup.File#.Incarnation# as explained above, even if the directory
structure are different for already existing file than the file we are creating.
DB_CREATE_FILE_DEST

For non-OMF File names in ASM, SET NEWNAME is the best and error-free way to create
file name in auxiliary.

Please note that restored OMF filename in auxiliary database will be different from the source
filename (i.e. different file#.incarnation#), and only the diskgroup name is honoured in the
filename conversion, as specified via SET NEWNAME, *_FILE_NAME_CONVERT, etc.

For example, if source database has file:


+DATA01/prod/datafile/system.382.8723429

At auxiliary ,the restored datafile will have different file#.incarnation#, even if diskgroup name
is same :

+DATA01/prod/datafile/system.126.5423098

Valid Format for DB_FILE_NAME_CONVERT /


LOG_FILE_NAME_CONVERT

We should always mention Diskgroup Names only without any further directory structure
specified:

Incorrect Values:

DB_FILE_NAME_CONVERT = '+DATA01/prod', '+UATDATA01/uat'


LOG_FILE_NAME_CONVERT = '+DATA01/prod', '+UATDATA01/uat',
'+FRA/prod', '+UATFRA/uat'

Correct Values:

DB_FILE_NAME_CONVERT = '+DATA01', '+UATDATA01'


LOG_FILE_NAME_CONVERT = '+DATA01', '+UATDATA01', '+FRA',
'+UATFRA'

Be careful while cloning on same server / same diskgroup where source database files
reside, as they could be overwritten due to above behaviour !!

Use Cases
In general, for RMAN DUPLICATE / manual restore/cloning, avoid using
DB_CREATE_FILE_DEST / DB_CREATE_ONLINE_LOG_DEST_n parameter to have better
control over creating files as intended.

If case the source and auxiliary database will be on same server and diskgroups, be very careful,
otherwise source files could be overwritten. Read the concepts above.

For example, if source database has :

CONTROL_FILES = '+DATA/prod/controlfile/current.116.5329108',
'+FRA/prod/controlfile/current.116.5329108'

And you set the similar parameter value for auxiliary, by just changing "prod" to "uat" in
parameter (directory "uat" may need to be created manually if not already exists):

CONTROL_FILES = '+DATA/uat/controlfile/current.116.5329108',
'+FRA/uat/controlfile/current.116.5329108'

Above will likely OVERWRITE source database control files and eventually, causing source
database to crash !

This also applies to datafiles / online redo logs, etc.

Let's review some common use cases and how to handle them:

1) Handling of Control Files in ASM OMF format


If below control files are in use at Source Database :

CONTROL_FILES = '+DATA/prod/controlfile/current.116.5329108',
'+FRA/prod/controlfile/current.116.5329108'

Then, Auxiliary should have below parameter value before restoring control file / DUPLICATE:

CONTROL_FILES = '+DATA', '+FRA'


If Diskgroup names are different at auxiliary, still the same pattern applies, e.g. :

CONTROL_FILES = '+UATDATA', '+UATFRA'

If static parameter (e.g. initSID.ora) is used to start auxiliary, then RMAN will not be able to
update parameter value with new restored control file OMF name.

Hence, it's recommended to use spfile to start auxiliary, in which case, RMAN updates the value
of new restored controlfile names of parameter CONTROL_FILES in spfile.

2) Handling of Control Files in ASM non-OMF format


Assume below control files are in use at Source Database :

CONTROL_FILES = '+DATA/prod/controlfile/control01.ctl',
'+FRA/prod/controlfile/control02.ctl'

To follow same naming convention (not recommended) in auxiliary as in source database,


assuming that auxiliary db name is UAT, and diskgroup names at auxiliary are +UATDATA and
+UATFRA, Auxiliary should have below parameter value before restoring control file /
DUPLICATE:

CONTROL_FILES = '+UATDATA/uat/controlfile/control01.ctl',
'+UATFRA/uat/controlfile/control02.ctl'

However, before restoring control file, it may be required to create the directory structure in
destination diskgroup prior to restore, if not already exists:

ASMCMD> cd +UATDATA <(=== or cd +DATA if diskgroup name is same as source

ASMCMD> mkdir uat <(==== uat is destination db_name / db_unique_name

ASMCMD> cd uat

ASMCMD> mkdir controlfile

For above settings, either of pfile (initSID.ora) or spfile can be used. This is because it's not
needed by RMAN to update the names as they are non-OMF, i.e. already known !
To follow recommendation of generating OMF names for controlfiles in auxiliary even if they
are non-OMF in source database, Auxiliary should have below parameter value before restoring
control file / DUPLICATE:

CONTROL_FILES = '+UATDATA', '+UATFRA'

If static parameter (e.g. initSID.ora) is used to start auxiliary, then RMAN will not be able to
update parameter value with new restored control file OMF name.

Hence, it's recommended to use spfile to start auxiliary, in which case, RMAN updates the value
of new restored controlfile names of parameter CONTROL_FILES in spfile.

3) Handling of Control Files in Mixed Names format


(OMF and non-OMF)
Below control files are in use at Source Database :

CONTROL_FILES = '+DATA/prod/controlfile/current.116.5329108',
'+FRA/prod/controlfile/control02.ctl'

This is not a good practice for obvious reasons explained above. While DBA is not yet able to
borrow downtime to swap non-OMF file to OMF above, let's get it fixed in auxiliary to avoid the
same situation.

Auxiliary should have below parameter value before restoring control file / DUPLICATE:

CONTROL_FILES = '+DATA', '+FRA'

If Diskgroup names are different at auxiliary, still the same pattern applies, e.g. :

CONTROL_FILES = '+UATDATA', '+UATFRA'

If static parameter (e.g. initSID.ora) is used to start auxiliary, then RMAN will not be able to
update parameter value with new restored control file OMF name.

Hence, it's recommended to use spfile to start auxiliary, in which case, RMAN updates the value
of new restored controlfile names of parameter CONTROL_FILES in spfile.
4) All Datafiles in ASM OMF
Assume all source datafiles are in diskgroup +DATA01 and +DATA02.

If auxiliary having same diskgroup +DATA01 for datafiles to reside, then set below parameters:

DB_FILE_NAME_CONVERT='+DATA01', '+DATA01', '+DATA02', '+DATA02'

If auxiliary having different diskgroup, say +UATDATA01 & +UATDATA02 for datafiles to
reside, then set below parameters:

DB_FILE_NAME_CONVERT='+DATA01', '+UATDATA01', '+DATA02',


'+UATDATA02'

5) Datafiles in mixed format, some files in ASM OMF


and some in non-OMF format
Taking below example of Source Datafiles:

SQL> select file#, name from v$datafile ;

FILE# NAME
------ --------------------------------------------------
1 +DATA01/prod/datafile/system.127.5329108
2 +DATA01/prod/datafile/sysaux.128.5329108 <(========== OMF files
3 +DATA01/prod/datafile/undotbs01.129.5329108
4 +DATA02/prod/datafile/users01.130.5329108
5 +DATA02/prod/datafile/sales01.dbf <(================= non-OMF file

Auxiliary should have below parameter value:

DB_FILE_NAME_CONVERT='+DATA01', '+UATDATA01', '+DATA02',


'+UATDATA02'

AND
In addition to above parameter, to handle non-OMF files, SET NEWNAME should be used in
RMAN DUPLICATE / RESTORE command for non-OMF datafiles, so that they get converted
to ASM OMF names on auxiliary during restore:

e.g. :

run {
allocate channel d1 type disk ;
allocate channel d2 type disk ;
set newname for datafile 5 to '+DATA02' ;
....
DUPLICATE / RESTORE command
....

6) All Redo Log members in ASM OMF format


Assume all source redo log members are in diskgroup +DATA01 and +FRA.

If same diskgroups in auxiliary, then set below parameter:

LOG_FILE_NAME_CONVERT='+DATA01', '+DATA01', '+FRA', '+FRA'

If different diskgroups in auxiliary, e.g. UATDATA01, UATFRA, then :

LOG_FILE_NAME_CONVERT='+DATA01', '+UATDATA01', '+FRA', '+UATFRA'

7) Redo Log members in mixed format, i.e. some in


ASM OMF format and some in non-OMF format
Assume, source database has logfiles as below :

SQL> select group#,member from v$logfile order by 1;

GROUP# MEMBER
---------- ------------------------------------------------
1 +DATA01/prod/onlinelog/group_1.285.761755579
1 +FRA/prod/onlinelog/group_1.272.761755579
2 +DATA01/prod/onlinelog/group_2.284.761755615 <(=== OMF Files
2 +FRA/prod/onlinelog/group_2.273.761755615
3 +DATA01/prod/onlinelog/redo03a.log <(============= non-OMF files
3 +FRA/prod/onlinelog/redo03b.log

As best practice recommendation, we should have all logfiles in OMF format at auxiliary
database:

For RMAN DUPLICATE, use LOGFILE clause as below:

run {
allocate channel d1 type disk ;
allocate channel d2 type disk ;
DUPLICATE DATABASE......
.....
LOGFILE
GROUP 1 ('+UATDATA01',
'+UATFRA') SIZE 1G REUSE,
GROUP 2 ('+UATDATA01',
'+UATFRA') SIZE 1G REUSE,
GROUP 3 ('+UATDATA01',
'+UATFRA') SIZE 1G REUSE
;
}

8) All Redo Log members in ASM non-OMF format


Assume, source database has logfiles as below :

SQL> select group#,member from v$logfile order by 1;

GROUP# MEMBER
---------- ------------------------------------------------
1 +DATA01/prod/onlinelog/redo01a.log
1 +FRA/prod/onlinelog/redo01b.log
2 +DATA01/prod/onlinelog/redo02a.log
2 +FRA/prod/onlinelog/redo02b.log
3 +DATA01/prod/onlinelog/redo03a.log
3 +FRA/prod/onlinelog/redo03b.log

If you wish to create similar non-OMF names for auxiliary (not recommended), assuming that
auxiliary db name is UAT, and diskgroup names at auxiliary are +UATDATA01 and
+UATFRA:

Before RMAN DUPLICATE, it may be required to create the directory structure in destination
diskgroup prior to restore, if not already exists:
ASMCMD> cd +UATDATA01 <(=== or cd +DATA01 if diskgroup name is same as source

ASMCMD> mkdir uat <(==== uat is destination db_name / db_unique_name

ASMCMD> cd uat

ASMCMD> mkdir onlinelog

Then, for RMAN DUPLICATE, use LOGFILE clause as below:

run {
allocate channel d1 type disk ;
allocate channel d2 type disk ;
DUPLICATE DATABASE......
.....
LOGFILE
GROUP 1 ('+UATDATA01/uat/onlinelog/redo01a.log',
'+UATFRA/uat/onlinelog/redo01b.log') SIZE 1G REUSE,
GROUP 2 ('+UATDATA01/uat/onlinelog/redo02a.log',
'+UATFRA/uat/onlinelog/redo02b.log') SIZE 1G REUSE,
GROUP 3 ('+UATDATA01/uat/onlinelog/redo03b.log',
'+UATFRA/uat/onlinelog/redo03b.log') SIZE 1G REUSE
;
}

To follow recommendation of generating OMF names for all redo log members in auxiliary even
if they are non-OMF in source database:

For RMAN DUPLICATE, use LOGFILE clause as below:

run {
allocate channel d1 type disk ;
allocate channel d2 type disk ;
DUPLICATE DATABASE......
.....
LOGFILE
GROUP 1 ('+UATDATA01',
'+UATFRA') SIZE 1G REUSE,
GROUP 2 ('+UATDATA01',
'+UATFRA') SIZE 1G REUSE,
GROUP 3 ('+UATDATA01',
'+UATFRA') SIZE 1G REUSE
;
}