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.
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
Shutdown the agent: export AGENT_HOME=/u01/app/oracle/agent11g $AGENT_HOME/bin/emctl stop agent Delete the related targets from Enterprise Manager. Run the deinstaller (silent mode): $AGENT_HOME/oui/bin/runInstaller -invPtrLoc $AGENT_HOME/oraInst.loc -deinstall -silent “REMOVE_HOMES={$AGENT_HOME}” -removeallfiles NOTE: I’ve included the ‘invPtrLoc’ flag above. This is optional, but if you ever come across a server where multiple inventories are used, you’re going to have to
This post explains how to resolve a blackout in an inconsistent state, when you trying ending it from within Enterprise Manager Grid Control 11g, and see the following message: Error stopping the blackout “Blackout-06-Jun-2012 13:55:32”: ORA-20708: The start of the blackout is currently being processed ORA-06512: at “SYSMAN.MGMT_BLACKOUT_ENGINE”, line 3394 ORA-06512: at “SYSMAN.MGMT_BLACKOUT”, line 74 ORA-06512: