Known Problems and Workarounds

The following are known problems with the HA Monitors product or with Event Monitoring Service:

JAGab04570: Delay in changing resource state

What is the problem? When SNMP connectivity to dbsnmp (Oracle SNMP) fails, EMS correctly reports that there are "no instances" of the /rdbms/server/status resource. However, the "no instance" error can persist for up to 60 seconds after corrective action has been taken, restarting Oracle SNMP. This can cause errors in processes that are monitoring the /rdbms/server/status resource. For example, it can cause premature package failures when a package resource dependency (RESOURCE_NAME) is specified.

What is the workaround? When you set up a monitoring request, avoid polling intervals that are less than 60 seconds. In package configuration files, this is controlled by the RESOURCE_POLLING_INTERVAL directive.

JAGab77759: ServiceGuard package service status is reported incorrectly

What is the problem? /cluster/package/service_status/ <package_name>/<service_name> may be incorrectly reported. If monitoring the service status of a package running locally when the ServiceGuard coordinator node is not the same node, service status may incorrectly be reported as UNKNOWN or DOWN when it is really UP. The output of cmviewcl shows the service is UP.

What is the workaround? Configure package and service status monitoring on each node in the cluster. Then correlate the data reported on each node. The coordinator node will report status of UNKNOWN for the remote service. (UNKNOWN means that the service is up and running somewhere in the cluster.)

JAGad03512: Events could be lost when EMS and HA Monitors are upgraded

What is the problem? When updating the Event Monitoring Services, notifications for monitors with active persistent requests can be lost. This can happen for up to two minutes from the update. This cannot happen with a new install, only an update.

What is the workaround? Before updating, find out which monitors are active. Enter the ps -ef |grep resmon command. In the output, check any of the monitors listed in the table below.

Now, update the software.

Immediately after the update, activate the monitor to re-register all of its active persistent requests. Use the commands in the table below.

Table 1-2 Title not available (JAGad03512: Events could be lost when EMS and HA Monitors are upgraded)

monitor name listed in output	command to re-register the monitor's active persistent requests
clustermond	resls /cluster/localNode/status
diskmond	resls /vg
fsmond	resls /system/filesystem/availMb
lanmond	resls /net/interfaces/lan/status
mibmond	resls /system/numUsers
pkgmond	resls /cluster/package/package_status
rdbmsmond	resls /rdbms
svcmond	resls /cluster/package/service_status

When a database is not available, an error message indicates that its resource instance is not available

What is the problem? If a database is unavailable or its server is down, you may see this error message: Resource "/rdbms/..." is not available. The message will pop up in the EMS graphical user interface window when you try to access the following resources: server_started, allowed_max_connects, peak_connects, usage (for both server and database), commits, commits_per_sec, database_used, and database_allocated.
What is the workaround? Before you try to monitor these particular resources, be sure the database is available and its server has been started.

Only Oracle database monitored when both Oracle and Informix databases installed on same system

What is the problem? Both Oracle and Informix have their own RDMS MIB subagents, and each has its own proprietary method of instrumenting the MIB. The HA Database Monitor relies on values in the MIB to monitor the databases and database servers. Only Oracle databases appear if both subagents are running because of:
- Oracle's particular implementation
- only one rdbms MIB subagent can receive MIB requests
What is the workaround? Install each vendor's database on different systems. If that is not feasible, and you need to monitor Informix databases, then stop the Oracle SNMP subagent (dbsnmp) and listener (tnslsnr) and run only the Informix SNMP subagent.