Re: VLDB RTO issue
Date: Mon, 24 Feb 2020 10:59:14 -0600
Message-Id: <F9638FB4-8414-4B6C-9491-93C661368D1A_at_gmail.com>
Thanks everyone for your valuable responses.
Actually we have been considering few of the options as you have suggested like Tim suggested Flashback Database and Mark suggested BCV option.
So here is what I am going to present to my senior mgmt as VLDB solutions, we will have to pick one option, but options 1 & 2 can be combined as our Strategic solution.
- Flashback Database
- RMAN Image copy+incrementally updated backups
- BCV
- Split our VLDB into separate DBs making one as Active/online DB with recent 90 days data and another Arch DB hosting data older than 90 days
Thanks,
Harinder Singh
Sent from my iPhone
> On Feb 23, 2020, at 11:27 PM, Tiwari, Yogesh <Yogesh.Tiwari_at_fidelity.co.in> wrote:
>
> I concur with Clay’s response.
>
> I think, OP has both RPO and RTO clubbed together in the same statement. It is important to identify two separately.
>
> If OP’s question just about going 2hrs back in time, with a discrete description of RPO, and a long enough window, Flashback can easily be meet this requirement, on both prod and dr.
>
> Thanks,
> Yogi
> Disclaimer: The information transmitted is intended for the person or entity to which it is addressed and may contain confidential, privileged or copyrighted material or attorney work product. If you receive this in error, please contact the sender and delete the material from any system. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any comments or statements made are not necessarily those of Fidelity. All e-mails may be monitored or recorded.
>
> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Clay Jackson (cjackson)
> Sent: 22 February 2020 01:42
> To: harinderpsingh_at_gmail.com
> Cc: oracle-l <Oracle-L_at_freelists.org>
> Subject: Re: VLDB RTO issue
>
> Interesting, to say the least.
>
> I think in order to answer this, you also need to know an RPO (Recovery Point Objective - or “How much data are you willing to lose or at best recover from a presumably uncorrupted source).
>
> If the RPO is zero or even near zero, I would submit the “problem” has no reasonable solution.
>
> The requirement for “recovery to a point in time prior to a corruption” without some sort of bound on “how long it will take to determine a corruption has occurred” is problematic in and of itself.”
>
> Once you can apply bounds to the recovery point/detection time, then you can look for strategies that could be used around taking “snapshots”, recoverable in less than 2 hours.
>
> This will probably require some iteration; and of course, testing
>
> Sent from my iPhone
> Clay Jackson
>
>
>
> On Feb 21, 2020, at 1:42 PM, Harinderpal Singh <harinderpsingh_at_gmail.com> wrote:
>
>
> CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
>
> Hi there,
>
> The database for our critical Banking application is 13 TB, and our RTO (Recovery Time objective) is 2 hours. We are running on 12C and have 3 nodes RAC clusters in both Prod & DR and have Active Data Guard set up too.
>
> But our company's Audit & Risk compliance team has flagged us with VLDB break asking us how would you restore your large DB from the backup in 2 hours if there will be any Cyber Attack and corruption gets propagated to DR. I know this kind of restore/recovery may not be required ever, but we still have to prove that we have a strategy in place to meet our RTO of 2 hours in case we have to restore from backup. I would like to mention that we have to keep at least 8-10 years of data in our DB for compliance purposes.
>
> I know there might be lots of DBAs on this forum who could be supporting VLDBs, can you please share how have you implemented VLDB recovery solutions for your DBs?
>
> Thanks,
> Harinder Singh
>
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Feb 24 2020 - 17:59:14 CET