Re: Standing up new 60 TB Standby DB on different storage - 3 options - are there more?

From: Upendra nerilla <nupendra_at_hotmail.com>
Date: Wed, 21 Feb 2018 21:16:34 +0000
Message-ID: <CY1PR10MB0683E28E4A3371D2E177B1E7D8CE0_at_CY1PR10MB0683.namprd10.prod.outlook.com>

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_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Sheehan, Jeremy <JEREMY.SHEEHAN_at_fpl.com> Sent: Wednesday, February 21, 2018 3:43 PM To: christopherdtaylor1994_at_gmail.com; 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Chris Taylor Sent: Wednesday, February 21, 2018 3:16 PM To: ORACLE-L <oracle-l_at_freelists.org> 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

--

http://www.freelists.org/webpage/oracle-l Received on Wed Feb 21 2018 - 22:16:34 CET