RE: Oracle Grid Control 12c
- From: Brian Pardy <brianpa@xxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 8 Jan 2013 14:43:43 +0000
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
> Behalf Of Rich Jesse
> Sent: Monday, January 07, 2013 4:31 PM
> To: oracle-l@xxxxxxxxxxxxx
> 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
>
> --
> //www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
