1. Documentación en Tahiti -> Oracle Enterprise Manager, 11g Release 1 (11.1) -> Administrator’s Guide -> 1 Monitoring
Documentación en Tahiti -> Oracle Enterprise Manager, 11g Release 1 (11.1) -> Administrator’s Guide -> 4 User-Defined Metrics
2. Las alertas se producen cuando un TARGET se cae o cuando se supera el umbral de una métrica. El agente detecta este evento, genera una alerta y la envía a Enterprise Manager. Si además, alguno de los administradores ha configurado el sistema, puede recibir dichas notificaciones, por ejemplo, por correo electrónico.
Enterprise Manager proporciona un conjunto de métricas y eventos por defecto para proporcionar una monitorización básica de la infraestructura desplegada. Además, nosotros podemos ampliar esta monitorización creando nuestra propias métricas, a través de scripts de SO o SQL.
Vamos a ver las diferentes opciones que tenemos disponibles en EM relacionadas con las alertas y la monitorización.
En la página inicial de OEM ->
-> Click «Targets» ->
-> Click «Databases» ->
-> Click «Search List» ->
-> Click «OEM»
En la sección de «Related Links» podemos acceder a las distintas páginas de Alertas y Métricas.
· Metric Collection Errors -> Errores encontrados por el agente al evaluar métricas
· All Metrics -> Métricas de Rendimiento disponibles para el Target
· Baseline Metric Thresholds -> Revisar métricas basadas en Baselines (nos permite configurar alertas para OLTP o DW)
· Metric and Policy Settings -> Configuración de umbrales de las distinas métricas
· Alert History -> Histórico cronológico de Alertas
· Metric Baselines -> Configuración del Baseline Activo
· User-Defined Metrics -> Administración de métricas definidas por el usuario
3. Revisamos los umbrales que tenemos definidos en la BD de OEM. Vamos a modificar el umbral de ocupación de Tablespaces «Tablespace Space Used (%)» para generar una alerta.
Click «Metric and Policy Settings» ->
-> Click «Edit» en «Tablespace Space Used (%)» (All others) ->
-> Warning Threshold = 10 ->
-> Click «Continue» ->
-> Click «OK» ->
-> Click «OK»
Cambiamos la frecuencia a 5 minutos.
Click «Metric and Policy Settings» ->
-> Click «Every 30 Minutes» en «Tablespace Space Used (%)» (All others) ->
-> Repeat Every = 5 Minutes ->
-> Click «Continue» ->
-> Click «OK» ->
-> Click «OK»
En 5 minutos debemos veremos varias alertas de llenado de Tablespace (Severidad => Warning). En mi caso aparecen los Tablespace SYSTEM y SYSAUX por encima del 10%. Vamos a dejar la configuración original.
Click «Metric and Policy Settings» ->
-> Click «Edit» en «Tablespace Space Used (%)» (All others) ->
-> Warning Threshold = 85 ->
-> Click «Continue» ->
-> Click «Every 5 Minutes» en «Tablespace Space Used (%)» (All others) ->
-> Repeat Every = 30 Minutes ->
-> Click «Continue» ->
-> Click «OK» ->
-> Click «OK»
4. Vamos a definir una métrica definida por usuario. Como ejemplo, vamos a lanzar una consulta que compruebe el máximo número de cursores en uso que tienen las sesiones.
Click «User-Defined Metrics» ->
-> Click «Create» ->
-> Metric Name = «Cursor Usage» ->
-> SQL Query =
SELECT MAX(A.VALUE) "MAXCURSORS" FROM V$SESSTAT A, V$STATNAME B WHERE A.STATISTIC# = B.STATISTIC# AND B.NAME = 'opened cursors current' ORDER BY A.VALUE;
-> User Name = «DBSNMP» ->
-> Password = «************» ->
-> Comparison Operator = «>» ->
-> Warning = «150» ->
-> Critical = «200» ->
-> Alert Message = «Maximum Cursor Usage (value = %value%)» ->
-> Repeat every «5» Minutes ->
-> Click «Test» ->
-> Click «OK»
Forzamos la generación de alertas cargando el número de cursores abiertos en una sesión en OEM. Para ello ejecutamos el siguiente fragmento de código que genera 250 cursores, y esperaremos a que aparezca la alerta crítica en OEM.
DECLARE
CURSOR my_cursor IS
SELECT level, CURSOR(SELECT dummy FROM dual) FROM dual CONNECT BY level < 250;
l_level USER_TABLES.TABLE_NAME%TYPE;
l_outer_count PLS_INTEGER := 0;
l_inner_count PLS_INTEGER := 0;
l_dummy VARCHAR2(20);
c_dummy SYS_REFCURSOR;
BEGIN
OPEN my_cursor;
LOOP
FETCH my_cursor INTO l_level, c_dummy;
EXIT WHEN my_cursor%NOTFOUND;
l_outer_count := l_outer_count + 1;
DBMS_OUTPUT.PUT_LINE('Outer Loop Count: ' || l_outer_count || ', Level: ' || l_level);
l_inner_count := 0;
LOOP
FETCH c_dummy INTO l_dummy;
EXIT WHEN c_dummy%NOTFOUND;
l_inner_count := l_inner_count + 1;
DBMS_OUTPUT.PUT_LINE('Inner Loop Count: ' || l_inner_count || ', Level: ' || l_level);
END LOOP;
END LOOP;
DBMS_LOCK.SLEEP(600);
CLOSE my_cursor; -- Closes all cursor resources here (c_dummy and my_cursor)
END;
/
En un intervalo de 5 minutos aparecera en la página principal de OEM la alerta con severidad Crítica. Una vez hemos comprobado que funciona correctamente y nuestro script ha terminado, podemos reevaluar la alerta manualmente para hacer que desaparezca.
En la página principal de OEM ->
-> Click Alerta «Maxium Cursor Usage (value = ###)» ->
-> Click «Reevaluate Alert»
Borrar las métricas definidas por usuario es trivial.
Click «User-Defined Metrics» ->
-> Seleccionamos nuestra alerta «Cursor Usage» ->
-> Click «Delete» ->
-> Click «Yes»
5. Además de las métricas por defecto y las que podemos definir nosotros (Métricas Definidas por Usuario), también podemos definir umbrales para métricas basadas en BASELINES. Son las llamadas ADAPTIVE METRICS. Ya haremos pruebas con BASELINES en la sección de «Performance Management», así que en este ejercicio definiremos los umbrales para una métrica de ejemplo «Number of Transactions (per second)». El BASELINE que utilizaremos será el de la ventana activa en movimiento correspondiente a la ventana de retención de las estadísticas de AWR.
En la Página principal de OEM ->
-> Click «Baseline Metric Thresholds» ->
-> View = «Basic Metrics» ->
-> Click «Number of Transactions (per second)» ->
-> Critical = «Very High (0.99)» ->
-> Warning = «High (0.95)» ->
-> Ocurrences = 1 ->
-> Click «Preview» (veremos los umbrales sobre la gráfica) ->
-> Click «Apply Thresholds»
Ejecutamos el siguiente script en la BD de OEM para generar un número elevado de transacciones por segundo. Mi sistema acepta hasta 10.000 transacciones por segundo (TPS). Para una BD sin apenas transacciones por segundo, un número superior a 100 TPS debería ser suficiente para forzar la alerta.
-- Borramos la tabla de pruebas "TEST"
DROP TABLE test PURGE;
CREATE TABLE test (
c NUMBER
) TABLESPACE USERS;
-- Configuración entorno
SET ECHO OFF
SET FEEDBACK OFF
SET VERIFY OFF
-- PL/SQL para generar n TPS
DECLARE
tps NUMBER := &1;
BEGIN
tps := (tps / 2);
FOR i IN 1..180
LOOP
FOR i IN 1..tps
LOOP
INSERT INTO test VALUES(1);
COMMIT;
DELETE test WHERE rownum < 2;
COMMIT;
END LOOP;
DBMS_LOCK.SLEEP(1);
END LOOP;
END;
/
Al cabo de unos minutos veremos una alerta con severidad crítica en la página principal de la BD de OEM (HOME). Este tipo de alertas es muy interesante para monitorizar situaciones anómalas en base al rendimiento «habitual» de la BD.
-- Borramos la tabla de pruebas DROP TABLE TEST PURGE;