Re: database migration

After you perform the test exercise, you'll know if your test plan worked, how long it took to execute and if the new OS version caused problems.

You might want to provide a little more detail, such as: database size (GB) (e.g. 100 GB)
[ archivelog | noarchivelog ] mode (e.g. archivelog) average redo log generation rate (e.g. 8 GB/day) [ enterprise | standard ] edition of the database server software?
(e.g. standard)

Is any downtime allowed? (e.g. Yes - 15 minutes at cutover) Network connection between servers [ gigabit, SAN, backup tapes + FedEx ] (GigE Full duplex)
What percent of the user tablespaces are read only (if any)? (e.g. 10%, 10 GB)
Read, write rate of source and target database storage subsystems.
(e.g. 40 MB/sec)

For the example data above, the rate limiting factor for the file copy will be the write rate on the target system:

102400 MB / 40 (MB/sec) = 2560 sec or about 42 minutes.

If your downtime window is large enough, simply copy a cold backup set from source to target.

If your downtime window will not allow for a cold backup set to be used, another method would be to copy a hot backup set from source to destination.

After the hot backup set has been transferred, the required archived redo logs are copied.
The source database is then shutdown cleanly and then the control files and online redo logs are copied to the target. The hot backup set is mounted as the same database using the current controlfiles and complete recovery is performed. The database is then opened noresetlogs.

This would translate to a downtime window of:

shutdown time of database instance on source host time to transfer controlfiles, online redo logs to target host time to rename files on target host, if needed time to recover database on target host
time to open the database instance on the source host (minimal for noresetlogs)

that ought to get you started.
You are going to run a full test prior to the actual cutover, right?

-bdbafh Received on Sun Mar 05 2006 - 22:36:19 CST