During the installation of Oracle Grid Infrastructure 188.8.131.52 you had the option to install the Grid Infrastructure Management Repository (GIMR) database MGMTDB. With 184.108.40.206, that option went away, and the MGMTDB database became mandatory. Given that it’s a database, the question of whether it should be monitored by Enterprise Manager was raised by a number of customers, and unfortunately a variety of different answers were forthcoming from different sources in Oracle.
Before we clarify that confusion, let’s have a look at what the MGMTDB database is used for. The best place to look for that is, of course, the documentation, but let me quote it here for the sake of clarity:
The Oracle Grid Infrastructure Management Repository:
- Is an Oracle database that stores real-time operating system metrics collected by the Cluster Health Monitor. You configure the Oracle Grid Infrastructure Management Repository during an installation of or upgrade to Oracle Clusterware 12c on a cluster.
- Runs on one node in the cluster (this must be a Hub Node in an Oracle Flex Cluster configuration), and must support failover to another node in case of node or storage failure. You can locate the Oracle Grid Infrastructure Management Repository on the same node as the OLOGGERD to improve performance and decrease private network traffic.
- Communicates with any cluster clients (such as OLOGGERD and OCLUMON) through the private network. Oracle Grid Infrastructure Management Repository communicates with external clients over the public network, only.
- Data files are located in the same disk group as the OCR and voting file. If OCR is stored in an Oracle ASM disk group called +MYDG, then configuration scripts will use the same disk group to store the Oracle Grid Infrastructure Management Repository. Oracle increased the Oracle Clusterware shared storage requirement to accommodate the Oracle Grid Infrastructure Management Repository, which can be a network file system (NFS), cluster file system, or an Oracle ASM disk group.
- Size and retention is managed with OCLUMON.
Now the key problem with this is the first few words of the 1st bullet point – “Is an Oracle database …”. As MGMTDB is a database, it also has a DBSNMP user. However, the password for that account is unknown, and in fact, you can’t even connect to the database to change or unlock the password. For those of you that have been around Enterprise Manager for some time, you would already know that we use the DBSNMP account to connect to the database and monitor it. Since we can’t do that, the MGMTDB database should not even be discovered by Enterprise Manager.
Now I was pretty sure there was some code in the product to explicitly NOT discover the MGMTDB database, but I didn’t have an installation of the Grid Infrastructure to prove it one way or another. I received an email on the subject from Niall, a good friend of mine and a customer who has quite a few clusters to look after where he confirmed that in fact the MGMTDB database WAS being discovered. After pursuing this back through Development with Andy Bulloch, a colleague of mine, we found there was a typo in the code so it wasn’t being explicitly blocked from being discovered. The issue has been fixed in the next release of Enterprise Manager, and we are also currently building backports for that patch that will address the issue in EM12c as well. Once that patch is available, I will update this post with the relevant patch number.
We’d like to thank Niall for his persistence in tracking this issue with us. It’s great to have customers who are prepared to work with us to help find and address problems like these.