RE: Duplicate from Active Database Question
- From: Brian Pardy <brianpa@xxxxxxxxxx>
- To: oracle-l mailing list <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 24 Jul 2014 12:40:29 +0000
If a clone snap is within your capabilities, is it not possible to split off
the clone and mount that to your sandbox system? That's how I deal with SAP
refreshes from production to sandbox in minutes, not hours. I never stop
production for a refresh. Put it into backup mode, take a clone snap, take it
out of backup mode. Run an "alter system switch logfile" on production, note
the SCN, backup the controlfile to trace, then copy the last few archived logs
over to the sandbox system. Mount the cloned sapdata to test, regenerate the
control files (create controlfile set database "NEWSID" resetlogs), RMAN
catalog the archived logs copied from prod, then:
run {
set until scn [whatever it was];
recover database;
}
At that point I have a list of tables to truncate to clear out RFC connections
and other items, lock all the accounts, change the dbid with nid so that it
doesn't hose my recovery catalog, start a full backup and then hand the
database off to the Basis admins to change the system name inside SAP.
If you're trying to work with a series of several SAP instances you want in
sync, I definitely suggest working with backup mode, clone snaps, then recover
with set until time as Andrew suggested.
The clone snaps may be politically unfeasible in your organization if an SAP
refresh is deemed to be a "DBA job" rather than a "team job" that can involve
your storage crew. You may or may not have access to clone, split, dedupe,
mount, and so on, so this may require you to bring in others to make it happen.
Good luck!
-Brian
David Barbour wrote:
Oracle 11gR2
RHEL 6.3
I've been refreshing a 14TB SAP 'sandbox' instance on our test RAC for close
to a year now using RMAN "DUPLICATE TARGET DATABASE TO <SID> FROM ACTIVE
DATABASE". Now the organization wants to refresh a series of SAP instances in
the test environment at the same time so they'll all be in sync. The
methodologies employed to this are pretty arcane. However, as part of this, we
need to copy the 14TB Production instance back to test. The method for
ensuring synchronization has been - and continues to be for the most part - to
shutdown all the active production instances and make either a datafile backup
or a clone snap. So I know that they're going to shut down the production
constellation at a certain time. Normally, out test environment goes down on
Friday nights for backups, so I have a window to perform an active duplicate
from the running production instance back to test.
What I do know is that it takes about 10 hours to do the refresh. So if I
started on Friday night, it would finish in the wee hours (anything before 9AM
is wee hours to me) of Saturday morning and would be out of sync with the other
databases that will be shut down at 10PM on Saturday night. I could start it
Saturday afternoon so it would finish in the 'dead zone', but I was wondering
if anybody has tried to perform a point-in-time (future) recovery of an active
duplicate.
I know a recovery and a duplicate are fundamentally different, but in the
duplicate from active database it applies the logs and redo to bring the copy
current with the source. I have looked through the documentation and can't
find any mention of using a recover clause with duplicate. Ideally I'd like to
put a recover until cancel in there and apply logs until I reach the dead zone
than let it finish up.
Other related posts:
