Re: Oracle Grid control

  • From: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
  • To: goran bogdanovic <goran00@xxxxxxxxx>
  • Date: Fri, 10 Jun 2011 09:39:35 -0300

It depends on the scale you are implementing, but it all ends up in the load
balancer.

OEM works on three levels:
1. Repository database: This is a (somewhat) standard Oracle Database and
can benefit from a number of DR solutions (RAC and DG is what we normally
use, but you could go with any other option you see fit)
2. OMS: This is the "web interface" (it actually does a lot more) and the
trickiest component of the lot, the plus side is you can have as many as you
want, usually you shouldn't have more than 500 targets per OMS. If you
balance the load this is just a matter of adding OMS as you add targets
(which is a rather simple process)
3. Agents: Agents are the thing that gathers all the data and sends them to
the repository (not directly). Agents, when secured, will only work on a
fixed address, so you have to make sure this is a load balanced address and
that the load is distrubuted among all OMS so in case of any number of OMS
failing, the rest can take the load. Granted, if you have a very big farm
and a log of OMS crash, you probably will experience bad performance, but
it'll still work.

We usually have DG and at least one OMS in the DR site, so in case of a
total site shutdown we still have monitoring of everything that was moved to
DR and the rest of the sites.

So, as you see the secret is having a load balancer, as this IS a single
point of failure (which can be secured using some HA load balancing
options,  but I will leave that to your network or unix engineers)... for
very small sites I'd recommend HAProxy, but if you can get your hands on
some real hardware load balancers they are far more reliable.

hth
Alan.-


On Fri, Jun 10, 2011 at 5:08 AM, goran bogdanovic <goran00@xxxxxxxxx> wrote:

> question to those who use GC for monitoring:
>
> - which (if any) Disaster Recovery solution did you implement for GC?
>
> many thanks,
> goran
>
>
>
> On Thu, Jun 9, 2011 at 4:36 PM, Amaral, Rui 
> <Rui.Amaral@xxxxxxxxxxxxxxxx>wrote:
>
>>  I agree with Alan.
>>
>> In my current and previous places of work we used/use GC as a general
>> monitoring tool and notification system. Adding custom extensions is nice
>> too but when it comes to the nitty-gritty nothing beats command line,
>> especially during those times when there's an issue that hits the db and os
>> at the same time. Also, ever tried to dig and manipulate the trace files
>> data in GC? run root/oracle commands to debug in GC when the db is in a slow
>> or hung state?
>>
>> Rui Amaral
>> Database Administrator
>> ITS - SSG
>> TD Bank Financial Group
>> 220 Bay St., 11th Floor
>> Toronto, ON, CA, M5K1A2
>> (bb) (647) 204-9106
>>
>>
>>
>>  ------------------------------
>> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
>> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Guillermo Alan Bort
>> *Sent:* Thursday, June 09, 2011 10:27 AM
>> *To:* niall.litchfield@xxxxxxxxx
>> *Cc:* srinivasanram2004@xxxxxxxxx; prabhu_adam@xxxxxxxxxxx;
>> oracle-l@xxxxxxxxxxxxx
>> *Subject:* Re: Oracle Grid control
>>
>> I have two main strategies, for general monitoring GC is the tool of
>> choice.
>>
>> When we have a specific problem in a database I fire up spotlight and toad
>> and do everything from there, it just depends on what you are used to.
>>
>> Oh, and not being able to do things from the command line is most
>> definitely not a plus. Choosing not to is open to discussion, but not being
>> able... not a good idea.
>>
>> <insert rant about overrated DBAs who know nothing about how the database
>> works>
>>
>> Cheers
>> Alan.-
>>
>>
>> On Thu, Jun 9, 2011 at 8:31 AM, Niall Litchfield <
>> niall.litchfield@xxxxxxxxx> wrote:
>>
>>> On Thu, Jun 9, 2011 at 12:19 PM, Ram Srinivasan <
>>> srinivasanram2004@xxxxxxxxx> wrote:
>>>
>>>> Prabhu:
>>>>   all our DBAs are so used to it that they can't do any command line
>>>> tasks any more.
>>>>
>>>
>>> I hope that's not a recommendation :)
>>> --
>>> Niall Litchfield
>>> Oracle DBA
>>> http://www.orawin.info
>>>
>>
>>
>> NOTICE: Confidential message which may be privileged. Unauthorized
>> use/disclosure prohibited. If received in error, please go to
>> www.td.com/legal for instructions.
>> AVIS : Message confidentiel dont le contenu peut être privilégié.
>> Utilisation/divulgation interdites sans permission. Si reçu par erreur,
>> prière d'aller au www.td.com/francais/avis_juridique pour des
>> instructions.
>>
>
>

Other related posts: