Re: Does anyone use 10gR2 Grid control for enterprise wide monitoring ?

  • From: "Ghassan Salem" <salem.ghassan@xxxxxxxxx>
  • To: sacrophyte@xxxxxxxxx
  • Date: Fri, 22 Dec 2006 17:19:37 +0100

Charles,
I agree GC looks like having some rough edges. but I never had a problem
when I upgraded a target.

To my surprise, I got to install the OMS on a RH4, x64 machine (using an
existing 10gr2 db). The OMS installed and works flawlessly, while the agent
could not link (it's the 32bit version), but I had the x64 version already
installed. I repointed it to the new OMS, secured it again, and it's working
like a charm.

OEM GC10gR2 is a quite complex piece of software. And I wish developers take
time to fix the issues users have with it than to add new features/plugins.

Happy Holidays to all

On 12/22/06, Charles Schultz <sacrophyte@xxxxxxxxx> wrote:

Something that really annoys us is doing some as simple as upgrading a
database can really confuse the way the agent phones home, causing an ugly
miscommunication between agent and the oms. I am not sure why this happens.
In two separate SRs, the Oracle Analyst told us the easiest thing to do is
reinstall the agent. Think about that for a moment. The OMS depends on the
Agent to talk to the Database. The Agent sits in its own Oracle Home and
allegedly knows quite a bit about the Database Oracle Home. When you upgrade
your Database, all the sudden the Agent gets confused and cannot talk
coherently with the OMS. Why?

I did push one Analyst to give the harder solution; this involved
modifying xml files in the agent home (removing the "offending Oracle
Home"), clearing out several directories and restarting the agent. It was
complex enough that if I had to do it again, I would need someone to hold my
hand again. I tried looking for the steps in the documentation, but could
not find them. Perhaps there is a metalink note now that describes the
process.

We continue to use 10gR2 for monitoring, and it comes in handy for various
SQL tuning exercises and overall system monitoring (people like to see the
pretty pictures). However, I do await a future incarnation when at least
upgrading the target is not a cause for agent surgery.

On 12/22/06, Alex Gorbachev <gorbyx@xxxxxxxxx> wrote:
>
> > Even a simple restart of the target database / servers result in ...
>
> When database is bounced, you should have blackout set as well as for
> node bounce.
>
>
> On 12/22/06, Mercadante, Thomas F (LABOR) <
> Thomas.Mercadante@xxxxxxxxxxxxxxxxx>
> >  We had release 1 running on our Aix box and it pretty much
> sucked.  The...
>
> Well, in my experience it's most stable on Linux 32 bit. I didn't try
> it on Solaris but AIX and HP-UX I found somewhat lagging in stability
> and number of bugs.
>
>
> > It's a pretty weird product.  I don't think I need all of the grid
> > functionality (don't want server stats, app server operations, web
> server
> > operations, auto patch install, auto Metalink search for patches –
> please!).
> >  We only need simple Oem functionality – like is the database up or
> down and
> > are there alert log errors.  My opinion is that they took a perfectly
> decent
> > product (9i Oem) and ruined it to try and gain market share competing
> > against Veritas and other infrastructure monitoring tools.  And we,
> the
> > DBA's, get screwed in the process with a tool that no longer works.
>
> Well, you don't really have these extra features unless you license
> them. They are bundled all together but you are not supposed to use
> it. I would recommend disabling those packs and also disable
> collection of metrics you don't use - this might save quite a bit of
> CPU for agents.
>
>
>
> --
> Best regards,
> Alex Gorbachev
>
> The Pythian Group
> Sr. Oracle DBA
>
> http://www.pythian.com/blogs/author/alex/
> http://blog.oracloid.com
> --
> //www.freelists.org/webpage/oracle-l
>
>
>


--
Charles Schultz

Other related posts: