CREAR ALERTAS ENTERPRISE MANAGER

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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

-- 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.

1 2	-- Borramos la tabla de pruebas DROP TABLE TEST PURGE;