The majority of Enterprise Manager 12c Cloud Control agent installations are pretty straight forward, just do the usual checks, ensuring firewalls are open etc. and then deploy from the EM console. The Windows installations are not as straight forward these days, as the deployment method uses SSH connectivity which requires the installation and configuration of Cygwin as a
Now that Oracle Enterprise Manager Cloud Control 12c Release 3 (aka EM12cR3!) has been out for a few weeks, I decided to brave it and upgrade our Production stack today. In this post, I’ll be upgrading an EM12cR2 (12.1.0.2) installation which consists of two OMSes, running on Linux x86-64 (RHEL5) which uses an 11.2.0.3 database management repository.
Enterprise Manager Oracle Management Server (OMS) installations generate huge amounts of log and trace files under the covers these days, and although the logs are rotated out-of-the-box, they’re not automatically deleted. Over time (as I was reminded again today 🙄 ), these logs can amount to a large portion of your disk space being used.
Generally speaking, the Java heap memory utilization for your Oracle Management Service (OMS) should be averaging at under 75%, and anything over this could mean the Garbage Collection starts impacting the performance of your Enterprise Manager experience. If you’re using the “out-of-the-box” notification rules, then an OMS suffering such symptoms may start churning out events like this:
Recently, I found myself in a situation whereby multiple database instances were running on a HP-UX clustered environment to ensure high availability, each with their own Serviceguard package, on an agent per package basis. Now on the plus side, if the SG package is failed over to another node, the agent goes with it, and
Put simply, when you install and configure an Management Agent in a clustered environment to monitor your targets through Enterprise Manager Cloud/Grid Control, then that primary node fails, your Oracle services are moved to a secondary node as part of the clustering…but your OMS isn’t aware of the change in nodes. Now if your agent
EMCLI is a Java based Command Line Interface that can be used to communicate with your OMS (Oracle Management Server) as an alternative to the GUI for some operations. Installation is pretty straight forward, and the toolkit can be installed anywhere as long as you have a Java JDK installed (1.6 or higher at the time of
The “Refresh From My Oracle Support” job in EM12c runs daily at 00:00 (midnight) by default. If the OMS host is under load at that time (backups etc.) then this can cause the refresh job to run past the 10 minutes StuckThreadMaxTime limit, which leads to a stuck thread being detected within WebLogic, and EM raising the
After deploying a number of Cloud Control agents recently, a few of the agents started generating critical events with a nasty looking (and unhelpful) error message: Host=[host] Target type=Agent Target name=[host]:[port] Categories=Diagnostics Message=Internal error detected: java.lang.IllegalStateException:oracle.sysman.gcagent.target.interaction.execution.ConfigStateMgr:798. Severity=Critical Whilst the error above isn’t too friendly, it stems from errors with the collection of storage metrics. Further
I’ve just applied PSU1 to our Oracle Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) Production environment in a matter of minutes, so I thought I’d post how straight forward it was 🙂 Download patch 14840279 (PSU) and 6880880 (latest OPatch v11.1.0.0.0) to a convenient location on your OMS server(s), such as /tmp. Set your