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

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_at_gmail.com> 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_at_gmail.com> 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_at_labor.state.ny.us>
> > > 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
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
> --
> Charles Schultz

--
http://www.freelists.org/webpage/oracle-l