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 (220.127.116.11) installation which consists of two OMSes, running on Linux x86-64 (RHEL5) which uses an 18.104.22.168 database management repository.
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