Re: Oracle Grid control

From: Guillermo Alan Bort <>
Date: Fri, 10 Jun 2011 09:39:35 -0300
Message-ID: <>

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.


On Fri, Jun 10, 2011 at 5:08 AM, goran bogdanovic <> 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 <>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:* [mailto:
>>] *On Behalf Of *Guillermo Alan Bort
>> *Sent:* Thursday, June 09, 2011 10:27 AM
>> *To:*
>> *Cc:*;;
>> *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 <
>>> wrote:
>>> On Thu, Jun 9, 2011 at 12:19 PM, Ram Srinivasan <
>>>> 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
>> NOTICE: Confidential message which may be privileged. Unauthorized
>> use/disclosure prohibited. If received in error, please go to
>> 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 pour des
>> instructions.

Received on Fri Jun 10 2011 - 07:39:35 CDT

Original text of this message