RE: Oracle Grid Control 12c

From: Brian Pardy <brianpa_at_burton.com>
Date: Tue, 8 Jan 2013 14:43:43 +0000
Message-ID: <92C2516C1D75EB4A922A8EE402EC23D55531DC20_at_helo.usa.burton.com>



I'm surprised you've experienced so many problems, as apart from a few installation/upgrade issues EM12cR2 has been very reliable for me. It's just a gut feeling but it seems to me that people who have upgraded from an existing system, particularly 10g, have been having more problems. I started with EM12c, reinstalled EM12c+BP1 fresh, and then performed an upgrade to EM12cR2. I had some Cygwin/X issues during the upgrade that were tracked down during a conference call with the EM team and a persistent issue with significantly increased redo logging on the repository database (bug 14726136), but it's all fixed now.

I'm not running AIX (SUSE Linux) and don't experience any of the issues that you've reported.

  • The maximum blocked session count (TX locks) works perfectly. I've never had PQ create reports of blocked sessions, other than hand-hacked manual PQ coming out of our application software that was creating true blocking locks.
  • I don't rely on the target discovery, but it stills runs each day and I've never provided it with a password. It hasn't once triggered any failed logins.
  • No problems with uname on Linux.
  • Tablespace full and disk full events, incidents and alerts all work perfectly. It's perhaps worth noting that the way these alerts are raised requires that the evaluated metric cross a threshold, and not be above it already at the time the metric is enabled or the thresholds are set. No issues on 10g or 11g.
  • No migration jobs so I can't comment there.

There's a thread on OTN titled 'How can we help to make EM12c better?' that I've tried to steer people towards a few times. Sushil Kumar posted in the thread asking those of us experiencing EM12c issues to file SRs and get on the phone to escalation managers if your SRs aren't getting enough attention. See https://forums.oracle.com/forums/thread.jspa?messageID=10615923 if anyone is interested. Oracle folks on the forums have been digging into specific SRs and providing a nudge in the right direction.

Incident/notification management has changed significantly and took me a lot of time to learn to use efficiently. But now that I understand it I prefer the new functionality. Some things still perplex me -- I still can't figure out how to clear alerts/events generated when Oracle mines server alert logs. I still don't understand why patch 6895422, available 9 months (which fixes an agent TOO_MANY_OPEN_FILES crash due to a file descriptor leakage) isn't included in the base product nor why some date columns insist on sorting alphanumerically rather than a calendar sort (which honestly looks really, really bad, and I had reported in 11g which was logged as a rediscovery from 10g and so on). But I know the bugs I have pursued have received fixes and useful MOS write ups (like note 1502370.1) and are starting to appear in periodic performance bundle patches so I'm seeing good effort on Oracle's part to improve the product. It's going to become more and more visible now with  DBControl desupported...

If you have an environment where you're only monitoring two servers and three DBs, it may be to your benefit to run a fresh installation of EM12cR2 rather than perform another upgrade. There shouldn't be too many jobs/credentials/etc to recreate.

> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On
> Behalf Of Rich Jesse
> Sent: Monday, January 07, 2013 4:31 PM
> To: oracle-l_at_freelists.org
> Subject: RE: Oracle Grid Control 12c
>
> 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
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 08 2013 - 15:43:43 CET

Original text of this message