How to Duplicating a Database using RMAN
Duplicating a Database using RMAN
1. Run the script below
on the database in which you plan to duplicate to generate the new paths for
the data files. This example assumes you have enough disk space on one mount
point. However, you can easily change some of the mount points in VI to
point another location or modify the script to suit your specific needs.
select ’set auxname
for datafile ‘ || file# || ‘ to ‘ || ”’/ora<XXX>/oradata/<SID>’ ||substr(name, instr(name, ‘/’, -1)) || ”’;’from v$datafile
/
2. Create the RMAN
script to perform the duplicate. The number of log groups must match the
source database. You may increase or decrease the number of log members as
needed. You must also insert your auxname commands before the rman run
block. If you are not doing a point in time dupilcate you can remove the
optional line “set until time …”.
———————————————————————————————————-connect target sys/<password>@<sid>
connect auxiliary /
connect catalog rman/<password>@<sid>
<Insert data file
rename commands from step 1>
run {
– Optional Line — set until time ‘2001-12-18:08:30:00′;
allocate auxiliary channel a0 type <DISK/SBT_TAPE>;
allocate auxiliary channel a1 type <DISK/SBT_TAPE>;
allocate auxiliary channel a2 type <DISK/SBT_TAPE>;
allocate auxiliary channel a3 type <DISK/SBT_TAPE>;
allocate auxiliary channel a4 type <DISK/SBT_TAPE>;
allocate auxiliary channel a5 type <DISK/SBT_TAPE>;
allocate auxiliary channel a6 type <DISK/SBT_TAPE>;
allocate auxiliary channel a7 type <DISK/SBT_TAPE>;
allocate auxiliary channel a8 type <DISK/SBT_TAPE>;
allocate auxiliary channel a9 type <DISK/SBT_TAPE>;
allocate auxiliary channel a10 type <DISK/SBT_TAPE>;
allocate auxiliary channel a11 type <DISK/SBT_TAPE>;
allocate auxiliary channel a12 type <DISK/SBT_TAPE>;
allocate auxiliary channel a13 type <DISK/SBT_TAPE>;
allocate auxiliary channel a14 type <DISK/SBT_TAPE>;
allocate auxiliary channel a15 type <DISK/SBT_TAPE>;
duplicate target database to <NEW_SID>
logfile
group 1 (’/ora<XXX>/oradata/<SID>/redo01_01.rdo’) size 200M reuse,
group 2 (’/ora<XXX>/oradata/<SID>/redo02_01.rdo’) size 200M reuse,
group 3 (’/ora<XXX>/oradata/<SID>/redo03_01.rdo’) size 200M reuse,
group 4 (’/ora<XXX>/oradata/<SID>/redo04_01.rdo’) size 200M reuse;
}
———————————————————————————————————-
3. Log into the server
where you will be duplicating the database.
4. If you are using RMAN
duplicate to refresh a TEST or Development database first. Shutdown the
instance if it already running.
5. You will need to
recreate/create the password file on for the target database.You do not have to delete the data files of the existing database if one
exists (applicable to only a refresh). It would be a good idea to do so if
you are not sure that the source and the target you are duplicating too has
the same name and number of data files. If not you will have unused data
files on the duplicate database, wasting server resources.
6. STARTUP NOMOUNT the
Target database.Note: You must have an adequately sized SORT_AREA_SIZE for RMAN to do its
quering against the auxiliary database since it will not have any temp space
available in NOMOUNT.
7. For the recovery part
of the duplicate you will need the archive logs of the source database
available. The archive logs can be copied over from the production machine
to the target machine as long as the archive logs are placed in the exact
path as on the production machine. Otherwise, you must do an archive log
backup via Rman to either disk or tape. Remember that if you use a
combination of Disk and Tape backups to allocate channels for both tape and
disk in your script.
8. If you are doing a
duplicate from a point in time you must set the NLS environmental variables.
If not you can skip this step.C- Shellsetenv NLS_LANG american
setenv NLS_DATE_FORMAT YYYY-MM-DD:HH24:MI:SS
Korn Shell
export NLS_LANG= American
export NLS_DATE_FORMAT= YYYY-MM-DD:HH24:MI:SS
9. Run the completed
duplicate script$ rman @runscript
Note: If for any reason
the duplicate fails due to missing archive log file or any other reason, it is
still possible to finish the recovery manually, however the DBID will not be
reset. Also, If you are duplicating a Multimaster replicated production database
be sure to set job_queue_processes=0 to avoid pushing replication transactions
to your production databases.
10. Make sure your global
name is set correctly fro your target database because RMAN does not set
this for you. It is also important to note that if you change the domain you
must rebuild any database links.
SQL> select * from global_name;SQL> alter database rename global_name to <new
name>;
11. Remember to add any
temporary files for any tablespaces that are using them.
12. Change any passwords
for the new database.
Source from oracle.com
- 336 reads
Recent popular content



















