We getting a huge number of alerts (Profile xxxxxl8001dps_CMAUS02P timed out, the probe may be hanging!) from the oracle probe .
1) Why this type of alert is generating.
2) How to solve this issue
Release : 9.2.0
Component : UIM - ORACLE
You have 2 options:
1 - Talk to your Oracle Database administrator to check the ENQUEUE_RESOURCES and DML_LOCKS
Number of table and row locks (acquired and converted) that timed out before they could complete. Consider to increase parameter ENQUEUE_RESOURCES or DML_LOCKS.
processes are Oracle initialization parameters.) The number of processes defaults to 50. So the default value for dml_locks = 4 * (1.1 * 50) = 220. However, depending on number of users, this may not be large enough for your system. Not having enough dml_locks and/or enqueue_resources may cause latch contention.
the number of resources that can be locked by the lock manager. The value of enqueue_resources should be no greater than dml_locks + 20.
2 - You can just disable the alarm to no about the enqueue_timeouts
type = 18
active = yes
qos = yes
alarm = no
qos_list = yes
description = Monitors number of table and row locks that timed out
clear_msg = rac_enqueue_timeouts_1
clear_sev = clear
scheduling = rules
msg_variables = $check.x;$profile.x;$instance.x;$INSTANCE_NAME.x;$ENQUEUE_TIMEOUTS.n;$interval_value.n;
condition = >=
column = ENQUEUE_TIMEOUTS
key = $INSTANCE_NAME
samples = 1
qos_name = enqueue_timeouts
qos_desc = Oracle Enqueue Timeouts
qos_unit = Timeouts
qos_abbr = Count
qos_max = 0
qos_value = ENQUEUE_TIMEOUTS
qos_key = $INSTANCE_NAME
The oracle probe has a limit of up to 50 connections. If you go above that limit you will normally encounter performance and scalability issues.