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

From: Sheehan, Jeremy <JEREMY.SHEEHAN_at_fpl.com>
Date: Wed, 21 Feb 2018 20:43:25 +0000
Message-ID: <83fb1c4cdb064e5a81be5dd7ca15ad65_at_fpl.com>



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 - 21:43:25 CET

Original text of this message