Hace un tiempo estaba revisando un Grid Control que tenía alertas reportadas desde hace mucho (más de 3 años), la cual depuraré sin misericordia…Jajajajaja.
Estas alertas jamás podrían ser eliminadas ya que, si bien tienen un estado "limpio"; pero se encuentran dentro del umbral crítico definido para esta alerta; por lo tanto, nunca seran eliminadas por el agente. De esta manera se puede aplicar este WorkAround, el cual obviamente Oracle no publica nada al respecto y tampoco soporta como procedimiento oficial.
Esto funciona así:
El procedimiento bajo el esquema SYSMAN llamado em_severity.delete_current_severity posee 3 variables de entrada llamadas:
P_TARGET_GUID
P_METRIC_GUID
P_KEY_VALUE
Los valores son rescatadas por la consulta ejecutada a la tabla sysman.mgmt_targets, para luego armar un script dinámico que permita "fumigar" de una vez estas alertas que siempre quedan dando vuelta.
Además, para asegurar que la alerta que será eliminada corresponde al día y hora señalada, se recomienda cambiar la configuración del parámetro NLS_DATE_FORMAT para obtener un resultado más detallado:
alter session set NLS_DATE_FORMAT='DD-MM-YYYY HH24:MI:SS';
select t.target_name
, collection_timestamp
, message
, 'Ejecutar Comando bajo la cuenta SYSMAN :'||'exec em_severity.delete_current_severity(''' ||
t.target_guid || ''',''' ||
metric_guid || ''',''' ||
key_value || ''')' em_severity
from mgmt_targets t
inner join
mgmt_current_severity s
on
t.target_guid = s.target_guid
where
target_name like '&SERVIDOR_ALERTADO'
Resultado
JUDAS1
05-04-2009 17:35:23
Metrics "Global Cache Average CR Get Time" is at 2.29141
Ejecutar Comando bajo la cuenta SYSMAN:
exec em_severity.delete_current_severity('5E0A6DF17A248B926C8A33C034123EE9','97C89AFFEE006CBA603A30604D5A4A00',' ')
Luego verificar que las alertas sean eliminadas desde Grid Control -> bajar al final en el Link Alertas -> navegar al Tab Crítica!!!
Y como siempre...
VIVA LINUX!!!
Alberto Silva Gallardo.
No comments:
Post a Comment