In this cloud-era it’s almost weird to explore stuff on-premises, but I did…. In this case a slightly Higher Availibility configuration of Oracle Enterprise Manager (OEM) that doesn’t cost anything, is not disruptive to the existing configuration and gives a tiny bit more confidence during patching of OEM : Always On Monitoring (AOM). Maybe a bit underrated functionality – within Oracle .
When Oracle Management Server (OMS) is down for patching, AOM is capable of mailing you when a critical target is down. It’s a limited functionality, but can be quite useful in some cases. Some details has changed since the start in 2016, when DBIservices wrote about it. At the end of the blogpost my findings. (more…)
A very short post this time… The metric ‘swap utilisation (%)’ on the node where Oracle Enterprise Manager resides, shows permanently a very hig value.
Red Hat Linux, 64-bits, 32GB RAM, 4GB swap.
Solution: Eitherway the memory, or the swap-file.
By adding 4 GB to the swap-file to the existing 4 GB (Oracle recommends a lot more by the way in this case) on 30th of March the metric value had the following behaviour, indicating this was the problem:
After installing Oracle Application Server 10.2.0.2, with corresponding OID, Grid Control 10.2.0.5 gave me the obove mentioned error, and the the item OID a ‘metric collection error’.
To fix the metric collection error downloaded and applied Patch 5686191 on top of OID product.This is a sql-script to run against the OID-repository. Unpublished bug according to note 764088.1
Shutdown the DAS:
~/media/5686191> opmnctl stopproc process-type=OC4J_SECURITY
~/media/5686191> /software/oracle/product/10.2/infra/OPatch/opatch apply
Oracle Interim Patch Installer version 184.108.40.206.52
Copyright (c) 2005 Oracle Corporation. All Rights Reserved..
We recommend you refer to the OPatch documentation under
OPatch/docs for usage reference. We also recommend using
the latest OPatch version. For the latest OPatch version
and other support related issues, please refer to document
293369.1 which is viewable from metalink.oracle.com
Oracle Home = /software/oracle/product/10.2/infra
Location of Oracle Universal Installer components = /software/oracle/product/10.2/infra/oui
Location of OraInstaller.jar = “/software/oracle/product/10.2/infra/oui/jlib”
Oracle Universal Installer shared library = /software/oracle/product/10.2/infra/oui/lib/linux/liboraInstaller.so
Location of Oracle Inventory Pointer = /etc/oraInst.loc
Location of Oracle Inventory = /software/oracle/product/10.2/infra/inventory
Path to Java = /software/oracle/product/10.2/infra/jre/1.4.2/bin/java
Log file = /software/oracle/product/10.2/infra/.patch_storage/<patch ID>/*.log
Backing up comps.xml …
OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.
Agent (10.2.0.4) crashes – on a site (64-bit) with many databases (10.2.0.3) a lot, intermittently – , too many open files, emagent.trc gives ‘health check’ error
Agent gave messages – in the past – like this:
Number files opened by Agent is 1140.
These files appeared to be the $ORACLE_HOME/dbs/hc<instance>_.dat which is loaded a lot in memory.
Noticed that the following error was popping up in the emagent.trc of a 10.2.04 – Grid Control-agent on a specific node, every 5 seconds. Annoying, unnecessary:
2007-09-18 12:15:14 Thread-134875 ERROR vpxoci: Error on dequeue from SYS.ALERT_QUE: ORA-00604:
error occurred at recursive SQL level 1
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at line 30
ORA-25228: timeout or end-of-fetch during message dequeue from SYS.ALERT_QUE