This content has been marked as final. Show 4 replies
Won't matter. I might do the Standby and let it catch up after the move, then do the Primary.
Did this last summer using SCP. I deferred the Primary and then it shutdown. If you want to move them cold and the directory structure is the same you can use this :
When I moved mine I did a DEFER then shutdown and moved the standby first. The log catch allowed me to test listener, tnsnames on the Standby before moving the Primary. This leaves less pieces to test on the Primary side.
set heading off set feedback off set pagesize 100 set linesize 400 select 'scp '||a.name ||' server_name:' || a.name as newname from v$datafile a; select 'scp '||a.name ||' server_name:' || a.name as newname from v$controlfile a; select 'scp '||a.member ||' server_name:' || a.member as newname from v$logfile a;
So, let me get this straight.
You would set dest_2_state to deferred on primary,
then shut down standby and copy/move the files,
then bring up standby to mount, alter db rename files,
then enable primary again and start managed recovery on the standby,
(and test everything at this point leaving standby_file_management=manual until both databases are moved).
Then, with a working standby (in the new location),
set dest_2_state on the primary to deferred again,
and shut down primary, copy/move the files,
bring it up to mount state,
alter db rename files,
then open the primary and set dest_2_state to enable again.
Then, test and pray. :-)
Is this about right?
Thanks mseberg. Unfortunately, the original configuration is a mess and needs to be cleaned up in this process.
I've already written the dynamic sql scripts to generate most of the file moves (copies), so the hard part is done.
It is just a very fragile process and of course, this is a critical production environment with no test environment in place.