Re: DataGuard Broker opinions please.

From: Stefan Knecht <knecht.stefan_at_gmail.com>
Date: Tue, 31 Oct 2017 11:46:14 +0700
Message-ID: <CAP50yQ92UTPH4qJV4VRq0G4gbmkpgsn8+entJWx+PtXVmY5E0g_at_mail.gmail.com>



Couldn't agree more with the general consensus of the replies so far. Whenever I encounter a standby database environment that doesn't have the broker setup, first thing I question is why they're not using it.

I'm usually not a fan of one-command-do-it-all-automatic type of things, but in the broker's case it's somewhat different since it's highly transparent. I always do a switchover / failover like this:

You can neatly follow the progress and see everything it's doing. If anything goes wrong, you'll see exactly why and what fails. On top of that, the DRC logs are also highly detailed.

All in all, it's a great tool and should be part of every standby environment.

Stefan

On Tue, Oct 31, 2017 at 12:49 AM, Nassyam Basha <nassyambasha_at_gmail.com> wrote:

> Forget the customer systems, even in my test machines, i manage only with
> Broker. Even I suggest using Data Guard broker to all the customer whomever
> I work.
>
> DG Broker considered as a lousy product but in fact, it is a very
> beautiful utility and simple to manage. Even the troubleshooting is also
> simplified with broker.
>
> The main challenge is when managing with Broker then we should not use
> SQL*Plus to manage Data Guard. for example, we have to change the parameter
> standby_file_management from AUTO to MANUAL, then being lazy DBA the
> command issued from SQL*Plus. Then it creates inconsistency and also we can
> see the warnings in the broker configuration.
>
> I hardly remember the commands, again we have the beautiful "help" like
> for other utilities GDSCTL, srvctl etc and everytime I use the syntax by
> help only. if we manage broker smoothly then it is definitely your best
> mate. :)
>
> DGMGRL> help edit database
> Edits a configuration, database, or instance
> Syntax:
> EDIT CONFIGURATION SET PROTECTION MODE AS
> {MaxProtection|MaxAvailability|MaxPerformance};
>
>
>
> --
> *Nassyam Basha*
> *Senior Principal Consultant - Data Intensity
> <http://www.dataintensity.com/>*
>
> *Mobile: +91 895 1010 800*
> <https://apex.oracle.com/pls/apex/f?p=19297:4:::NO:4:P4_ID:13140>
> Oracle 11g Certified Master
> <http://education.oracle.com/education/otn/NassyamBasha.htm>
> Certified* ITIL *Foundation *2011 *&
> *ITSM* Foundation *ISO/IEC 20000*
> Co-Author: Oracle Data Guard 11gR2
> <http://www.amazon.in/Oracle-Guard-11gR2-Administration-Beginners/dp/1849687900>
> Co-Author: Database Upgrade & Migration Methods
> <https://www.amazon.com/Oracle-Database-Upgrade-Migration-Methods/dp/1484223276/ref=sr_1_1?ie=UTF8&qid=1488562247&sr=8-1&keywords=database+upgrade+and+migration+methods>
> Toad World Community Expert
> <https://www.toadworld.com/members/nassyambasha>
> Co-founder of Oraworld-team <http://www.oraworld-team.com> & IDGOUG
> <http://www.idgoug.org>
>
> [image: Facebook] <https://www.facebook.com/nassyambasha> [image:
> Twitter] <https://twitter.com/oracle_ckpt> [image: LinkedIn]
> <https://in.linkedin.com/in/nassyambasha> [image: Google +]
> <https://plus.google.com/+NassyamBasha> [image: CKPT Blog]
> <http://www.oracle-ckpt.com/>
>
>
> On Mon, Oct 30, 2017 at 10:45 PM, Norman Dunbar <oracle_at_dunbar-it.co.uk>
> wrote:
>
>> Hi Howard,
>>
>> I've used DG Broker on 11g for my last two contracts with no problems at
>> all. We had the setup as one primary and one standby in a remote location
>> for all production databases in one contract, and for my last we had the
>> primary in Dublin with a Dublin based standby plus a separate DR standby in
>> Amsterdam.
>>
>> Linux and Windows, DG works well.
>>
>> Cheers,
>> Norm.
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>

-- 
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat |
_at_zztat_oracle

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Oct 31 2017 - 05:46:14 CET

Original text of this message