RE: Oracle Grid Control 12c

From: Jorgensen, Finn <>
Date: Mon, 7 Jan 2013 18:04:26 -0500
Message-ID: <9CE162BC5ED2C643956B526A7EDE46FF035944A6DA0E_at_EXM-OMF-04.Ceg.Corp.Net>


Believe me, I feel your pain. My initial environment was a well established and standardized set of over 100 hosts and 1000+ databases. I started right after BP1 was released in May 2012. Opening SR's for issues was a daily occurrence. Many of these issues were fixed in 12cR2 ( but not all. Your list of issues below are all different than my list of issues so I can't tell you how many may be fixed but let me give you a little input anyway:

  1. I had to develop a metric extension to create a blocking lock monitor that did what I wanted it to do. This was easy and has worked reliably so far. It was done in R2 from the get-go.
  2. As I said in 1) my ME works without issues
  3. I have suspicions that filesystem monitor is unreliable but haven't gathered proof for an SR. Haven't seen any problems with tablespace monitor yet.

Also, I ended up creating a document to track all the SR's and problems as well. Some of the patches created and fixes included in R2 are due to my SR's. I felt like I was the only one in the world who implemented 12c and I hit all the errors first.


-----Original Message-----
From: [] On Behalf Of Rich Jesse Sent: Monday, January 07, 2013 4:31 PM
Subject: RE: Oracle Grid Control 12c

Finn replies:

> 12c has its own range of issues but coming from OEM GC 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 in April 2012. My environment: Agents on two AIX servers monitoring three DBs. One OL5.8 server running EM12c w/ 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.




>>> 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

Received on Tue Jan 08 2013 - 00:04:26 CET

Original text of this message