Move large database to other server using RMAN in less downtime

Question

Hi,
We have large database around 20TB. We want to migrate (move) the database from one server to other server. We do not want to use standby option.
1)     How can we move database using RMAN in less downtime
2)     Other than RMAN is there any option is available to move the database to new server
For option 1 (restore using RMAN),
Whether below options are valid?
If this option is valid, how to implement this?
1)     How can we move database using RMAN in less downtime
a)     Take the full backup from source (source db is up)
b)     Restore the full backup in target (source db is up)
c)     Take the incremental backup from source (source db is up)
d)     Restore incremental backup in target (source db is up)
e)     Do steps c and d, before taking downtime (source db is up)
f)     Shutdown and mount the source db, and take the incremental backup (source db is down)
g)     Restore last incremental backup and start the target database (target is up and application is accessing this new db
database version: 10.2.0.4
OS: SUN solaris 10
Edited by: Rajak on Jan 18, 2012 4:56 AM

Answer 1

Simple:
I do this all the time to relocate file system files... But the principle is the same. You can do this in iterations so you do not need to do it all at once:
Starting 8AM move less-used files and more active files in the afternoon using the following backup method.
SCRIPT-1
RMAN> BACKUP AS COPY
DATAFILE 4 ####"/some/orcl/datafile/usersdbf"
FORMAT "+USERDATA";
Do as many files as you think you can handle during your downtime window.
During your downtime window: stop all applications so there is no contention in the database
SCRIPT-2
ALTER DATABASE DATAFILE 4 offline;
SWITCH DATAFILE 4 TO COPY;
RECOVER DATAFILE 4;
ALTER DATABASE DATAFILE 4 online;
I then execute the delete of the original file at somepoint later - after we make sure everything has recovered and successfully brought back online.
SCRIPT-3
DELETE DATAFILECOPY "/some/orcl/datafile/usersdbf"
For datafiles/tablespaces that are really busy, I typically copy them later in the afternoon as there are fewer archivelogs that it has to go through in order to make them consistent. The ones in the morning have more to go through, but less likelihood of there being anything to do.
Using this method, we have moved upwards 600G at a time and the actual downtime to do the switchover is < 2hrs. YMMV. As I said, this can be done is stages to minimize overall downtime.
If you need some documentation support see:
http://docs.oracle.com/cd/E11882_01/server.112/e18951/asm_rman.htm#CHDBDJJG
And before you do ANYTHING... TEST TEST TEST TEST TEST. Create a dummy tablespace on QFS and use this procedure to move it to ASM to ensure you understand how it works.
Good luck! (hint: scripts to generate these scripts can be your friend.)