| |
|
Duplicating
a Database using RMAN
By Michael Ritacco, Oraclenotes.com
- 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
/
- 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;
}
----------------------------------------------------------------------------------------------------------
- Log
into the server where you will be duplicating
the database.
- If
you are using RMAN duplicate to refresh a TEST
or Development database first. Shutdown the instance
if it already running.
- 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.
- 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.
- 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.
- 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- Shell
setenv 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
- 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.
- 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>;
- Remember
to add any temporary files for any tablespaces
that are using them.
- Change
any passwords for the new database.
|
|
|
|
|
|
|