Re: RMAN Duplication for Migration and Archived Logs

The simple approach is to create a standby database. I think it should work 32 bit -> 64 bit as well.

When time X comes - perform a switchover. You would also need to run one script to change "bitness" but you probably aware of it already anyway (I mentioned ML Note in another thread today).

The good thing that when you perform switchover - you would be able to revert the flow of redo logs and, in case you have issues on the new machine, you can switch back. It's a good fallback option.

If you are on SE than you can setup "manual" standby. You can also restore database in advance and not open it in resetlogs but keep applying archive logs that you RSYNC to another node. Again, it's like a manual standby.

DUPLICATE command open database with resetlogs. DUPLICATE FOR STANDBY doesn't. You can make normal DUPLICATE fail somewhere during recovery by providing UNTIL set very far in the future (should be no problem) - it would them fail on recovery and won't open resetlogs.

On 8/1/07, Don Seiler <don_at_seiler.us> wrote:
> OK here it is. Currently we're on Oracle 10.2.0.2 on 32-bit RHEL 3.
> We're going to be migrating to the same version (10.2.0.2) on a 64-bit
> RHEL 4 box.
>
> I've done this migration plenty of times to create development
> instances. However, in the case of the actual production migration,
> we have the question of downtime. My production-to-development
> duplications are currently taking 10 hours, in there I use the UNTIL
> TIME parameter to tell it to do the PITR. I've been given an 12-hour
> overnight downtime window (10 PM Saturday to 10 AM Sunday).
>
> I'm wondering if I can minimize the downtime by starting the
> duplication earlier while the production database is still running.
>
> Here is our current backup scenario:
> * Full backup Saturday evenings to disk
> * Incremental backups all other evenings to disk
> * Archived logs are backed up every 2 hours to disk
> * The directory on disk that holds all of these backup pieces is
> rsynced regularly throughout the day to the auxiliary server.
>
> This is the crazy scheme I've been concocting in my head:
>
> 1. Start the RMAN duplication at, say 3 PM Saturday, specifying UNTIL
> TIME of 10 PM that night.
> 2. While this is going on, new transactions are made (none of them
> are NOLOGGING) in the current production database. Archived redo logs
> are generated, backed up and rsynced throughout the day.
> 3. At 10 PM, change the listener config in the current production box
> to only allow the auxiliary server to connect, and manually kick all
> other connections.
> 4. After that, force 3-4 log switches, call the script to back them up.
> 5. Call the script to rsync.
> 6. Assuming that RMAN won't need them by this point (only 7 hours into
> a 10-hour restore/recovery), we're golden.
>
> Obviously the big "IFs" are:
> 1. Will RMAN let me specify UNTIL TIME into the future? e.g. saying
> UNTIL TIME of 10 PM when it is only 3 PM.
> 2. Will RMAN need those backup pieces on local disk before it begins
> duplication? I'm assuming it doesn't since I've found out that pieces
> are missing 8 hours into a duplication.
>
> If anyone can tell me if this is a crackpot scheme that just might
> work, or simply not possible with rman, I'd appreciate it. Worst case
> scenario is that I perform the restore/recovery completely within the
> downtime window.
>
> --
> Don Seiler
> oracle: http://ora.seiler.us
> ultimate: http://www.mufc.us
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Alex Gorbachev, Oracle DBA Brewer, The Pythian Group
http://www.pythian.com/blogs/author/alex http://www.oracloid.com
BAAG party - www.BattleAgainstAnyGuess.com
--
http://www.freelists.org/webpage/oracle-l