RE: Oracle Grid Control 12c

From: Jorgensen, Finn <Finn.Jorgensen_at_constellation.com>
Date: Mon, 7 Jan 2013 18:10:17 -0500
Message-ID: <9CE162BC5ED2C643956B526A7EDE46FF035944A6DA0F_at_EXM-OMF-04.Ceg.Corp.Net>



Gabriel,

> For example, the tablespace full alert is not working at BP2, neither on 10g or 11g instances.

You can't generalize like that. I have many alerts/incidents like this in my EM environment: Tablespace [SYSTEM] is [90 percent ] full

If it doesn't work at all for you then maybe you only have a warning or a critical threshold set on the metric? 12c requires you set BOTH warning and critical thresholds. Otherwise the metric is completely disabled and you get no incidents created. So let's say you want an alert when a tablespace reaches 90% full and that's it, then set warning to 90 and critical to 101. Then only warning level alerts are generated and you just set up your incident/notification rules accordingly.

Thanks,
Finn

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Gabriel Hanauer Sent: Monday, January 07, 2013 6:01 PM
To: rjoralist2_at_society.servebeer.com
Cc: oracle-l-freelists
Subject: Re: Oracle Grid Control 12c

Rich,
I had almost the same issues as you.

I have 100+ databases monitoring at the environment.

I upgrade to 12c from 11g. The BP1 version is a nightware. Then, I upgraded to BP2.

Some of the issues are solved in the BP2 version. But others not.

For example, the tablespace full alert is not working at BP2, neither on 10g or 11g instances.

Regards,

On Mon, Jan 7, 2013 at 7:30 PM, Rich Jesse <rjoralist2_at_society.servebeer.com
> wrote:

> Finn replies:
>
> > 12c has its own range of issues but coming from OEM GC 10.2.0.5 it's
> still
> > better so the upgrade was a pretty easy decision for me. 12cR2 is
> decently
> > stable. A small installation like yours should be easy.
>
> So is "R2" the *next* magic key I need to fix the plethora of issues I
> have with EM12c? That was supposed to be "BP1".
>
> I did a two-server migration from 10.2.0.5 in April 2012. My environment:
> Agents on two AIX servers monitoring three 11.2.0.3 DBs. One OL5.8
> server running EM12c w/11.2.0.3 repository DB. One EM12c user (me).
> Diag+Tuning Packs licensed.
>
> That seems about as simple as anyone could expect for an EM installation.
> Here's part of my unresolved issue list:
>
> 1) Any PQ causes blocking lock alerts against the PQ threads as
> "Session # is blocking 0 other sessions". Had to disable blocking lock checking.
> Support DB Group says it's EM12c.
>
> 2) Daily target discovery job on agent forgets DB account passwords
> causing daily alarms for login failures on Production DBs.
>
> 3) Daily target discovery job does not know the format of the "uname"
> command on AIX, causing errors. Waiting 8+ months for fix.
>
> 4) Failed tests of a metric extension caused thousands of errors per
> hour in agent's gcagent.log. Support was unable to troubleshoot, but
> somehow they magically stopped after a few weeks. Currently unable to
> test or deploy metric extensions.
>
> 5) Tablespace full metric alarms unreliable. Unable to keep an SR
> open to resolve as the symptoms change.
>
> 6) EM migration jobs run and fail daily after all migrations are complete.
> Stopped jobs are restarted after patches and jobs cannot be dropped
> per Support.
>
> One of my SRs was "resolved" because they really really thought that
> the fix could be in a patch. However, they failed to mention that the
> "patch" is not just a patch, but a full-blown upgrade of EM12c. After
> wasting literally hundreds of hours on these and several other issues
> (>15 SRs), I just don't have the time to start that project for what
> should be just a patch. I have other things to do than to babysit
> EM12c.
>
> I am several months beyond unhappy with this product. Unfortunately,
> it appears that I'm stuck with it for the foreseeable future.
>
> There. I've got some of my EM12c issues documented for my sake, as
> well as some much-needed venting.
>
> GL!
>
> Rich
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
Gabriel Hanauer


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



>>> This e-mail and any attachments are confidential, may contain legal, professional or other privileged information, and are intended solely for the addressee. If you are not the intended recipient, do not use the information in this e-mail in any way, delete this e-mail and notify the sender. -IP1
-- http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 08 2013 - 00:10:17 CET

Original text of this message