Re: Automation: DG Broker

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Thu, 22 Aug 2019 19:48:31 -0400
Message-ID: <1b93c183-2fdb-303f-d89b-2493b40aab7f_at_gmail.com>


Performance is usually a part about any production DB consideration. Flashback is not. Other than that, I agree that there are at least three methods for rebuilding the standby relatively quickly: flashback, snapshot and disk replication. Given the proper hardware, even restoring from backup may not be as painful as it seems at the first glance.  My point is that in the absence of any other information, the folks configuring such things have to account for accidental fail-overs because they might have to rebuild the primary after that. In a configuration without flashback, which is the norm, the primary will have to be rebuilt after a fail-over.

I have had a problem with a client upgrading some 3rd party software and creating a guaranteed restore point, which is a norm today.  The upgrade went wrong and the database was flashed back to the restore point and opened with resetlogs option. Guess what happened to the standby? Fortunately, that wasn't a problem because of something called "HUR" (Hitachi version of SnapVault) and the client has rebuilt the standby very quickly.

Regards

On 8/22/19 2:59 PM, Neil Chandler wrote:
> You pick up on a flashback not being part of the original discussion.
> When did the OP ever ask about performance?

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 23 2019 - 01:48:31 CEST

Original text of this message