OEM and monitoring the -MGMTDB GMIR Database

When you create Grid Infrastructure in 12.1.0.2, you are presented with a new (annoyingly named) “-MGMTDB”

This database is a standard, 12C CDB/PDB storing transient performance and other information (Grid Infrastructure Management Repository). If it is lost, no biggie. Just re-create it (in your voting disk DG. Aside: create a new MGMTDB_DG, move your voting disk there, re-create -MGMTDB, then move your voting disk back out to the proper multiple voting volumes.)

However, Oracle Enterprise Manager Cloud Control 12.1.0.5.0 and earlier sees this oracle database, PDB, listener and all, and decides to discover it. This is incorrect and should not happen. It is supposed to be “masked off” from OEM. Monitoring this database system will only lead to false positives and problems where none really exist, and all of the targets should be ignored (as per the attached picture)

OEM-MGMTDB

In a future release of Oracle Enterprise Manager Cloud Control, these targets will no longer be discovered and will automatically remain hidden from view within OEM, once the team have fixed the bug which – I was very reliably informed – they discovered the root cause of today.

Cloud Control 12c Discovery Problem

You know when things just don’t quite work as they should, and you spend far longer than you think you should have sorting them out. Well, this was one of them. Burned 20 minutes on this!

I’m running Oracle Enterprise Linux 6.6 with Oracle Enterprise Manager Cloud Control 12.1.0.4, and I’m trying to discover some lovely new targets. Discovery from within OEM is simplicity itself: Delegate privileges from the OEM server, allow unfettered sudo access from the installation account (oracle) to root and autodiscover by IP range.

Except that in OEL 6.6 it doesn’t work. The discovery uses nmap, and nmap is looking for an older version of libpcap than is installed at 6.6 and the discovery fails:

/u01/app/oracle/agent12c/agent_inst/discovery/nmap/bin/nmap: error while loading shared libraries: libpcap.so.0.9.4: cannot open shared object file: No such file or directory

But I have a newer version of libpcap installed!

-bash-4.1$ rpm -qa | grep libpcap
libpcap-1.4.0-1.20130826git2dbcaa1.el6.x86_64

So, what to do? You can try to get your hands on an old version of libpcap, or you can cheat and symbolically link the new version to the old version name!

ln -s /usr/lib64/libpcap.so.1.4.0 /usr/lib64/libpcap.so.0.9.4

And all it well with the world again. And I’ve discovered all of my targets from within OEM. Nice.

p.s. ensure you have nmap in your system!

yum install nmap
Setting up Install Process
Package 2:nmap-5.51-4.0.1.el6.x86_64 already installed and latest version
%d bloggers like this: