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

I'm putting in a production installation for the same reasons. After painfully upgrading oms, agent, repository and database to 10.2.0.2, I cloned the agent to a second server. Ran the agent configuration assistant - which is where I am now after two days. I is simply hanging never to return. I have an SR but will not now get progress until Wednesday or later. The analyst came back and wanted my glogin.sql scripts for each ORACLE_HOME?  

Who would have thought to look at that? It is the default one anyway on that server.  

Joel Patterson
Database Administrator
joel.patterson_at_crowley.com
x72546
904 727-2546

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Charles Schultz Sent: Friday, December 22, 2006 11:01 AM To: gorbyx_at_gmail.com
Cc: Thomas.Mercadante_at_labor.state.ny.us; premjhere_at_gmail.com; rjamya; oracle-l
Subject: Re: Does anyone use 10gR2 Grid control for enterprise wide monitoring ?  

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