There are a few more variables needed before you pick an optimal solution..
1. How far are the data centers between the Primary and DG sites?
2. How large is the network pipe? what is your hourly copy rate?
3. What is your daily redo generation at primary?
4. How long does it take to complete a level-0 backup take at the primary
site? - Is that even doable without impacting your business?
I would not recommend the First option you had - active duplicate.. too much
risk as well as may be too slow..
As others pointed out, if you have an option to use Storage based replication,
that would be great and will make it easy.
I would suggest looking into the following method also:
1. From Primary add an additional log archive dest to the DG site and ship
archivelogs from primary (without having the entire database at the remote
site) or setup a scp job to copy the archivelogs on regular intervals to the DG
site. The goal is to have all archivelogs before your backup shows up.
2. Take a Rman level-0 backup on Primary DB to tape/disk(s) and scp/snail mail
it to the DG site..
3. Restore the db and apply the archivelogs that are in the DG site to bring it
to the current state.
A small variation to the above plan would be to perform a daily Level-1 backup
and scp it to the DG site, so you can apply it on the standby (if the daily
level-1 is considerably smaller compared to the amount of archivelogs).
-Upendra
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf
of Sheehan, Jeremy <JEREMY.SHEEHAN@xxxxxxx>
Sent: Wednesday, February 21, 2018 3:43 PM
To: christopherdtaylor1994@xxxxxxxxx; ORACLE-L
Subject: RE: Standing up new 60 TB Standby DB on different storage - 3 options
- are there more?
If you have the option to leverage storage replication, that would be a great
way to take care of this. In the past, I’ve used this to rebuild 2TB database
standby in less than 20 minutes. Most of that time was spent configuring data
guard. We leverage EMC and for the most part you can use disks as long as the
replication has started.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Chris Taylor
Sent: Wednesday, February 21, 2018 3:16 PM
To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
Subject: Standing up new 60 TB Standby DB on different storage - 3 options -
are there more?
CAUTION - EXTERNAL EMAIL
Scenario:
60 TB database on 12.1 (no multi-tenant)
Requirement:
Create Standby DB on a new host with new storage
Here are the options I've identified. I'm looking for others - or concerns
about any of these 3. Personally, I favor #1 but with this size database, I'm
not sure how "smart" it is.
1. Active Duplicate from Primary to Standby using RMAN duplicate - I like this
one, but never done a database of this size before. Am concerned about it
failing midstream but I "think" an RMAN duplicate will pick up where it left
off if you have to restart it?
2. RMAN backup to disk on primary , swing luns to new Standby server and
restore backup? Concern here is the time element involved in the backup,
recovery and maintaining archivelogs necessary for the recovery
3. Standby Database Creation using incremental backups of datafiles like this:
https://blog.rackspace.com/standby-database-creation-of-vldbs. Concern here is ;
that I've never done this method and seems like it could be prone to errors
Any other options I'm not considering? Any comments on the above options?
Thanks,
Chris
