Afinando el Job interno MGMT_CAW_EXTRACT_JOB en Oracle OEM

En entornos con Oracle Enterprise Manager (OEM) y AWR Warehouse , gran parte de la magia ocurre gracias a jobs internos gestionados por el propio repositorio.

El problema aparece cuando necesitamos entender su comportamiento o afinar su ejecución (por ejemplo, en entornos RAC) y descubrimos que no existe opción alguna para modificarlo desde la consola de OEM.

Qué es AWR Warehouse?

AWR Warehouse es un componente de Oracle Enterprise Manager que permite centralizar la información histórica de rendimiento (AWR) de múltiples bases de datos en un único repositorio.

En lugar de consultar los datos AWR directamente en cada base de datos (con la retención limitada que tenga configurada):

• Extrae periódicamente los snapshots AWR de las bases de datos monitorizadas.

• Los almacena en un esquema dedicado dentro del repositorio de OEM.

• Permite análisis históricos de largo plazo, comparativas entre sistemas y reporting avanzado.

Esto es especialmente útil cuando:

• Necesitamos análisis de rendimiento de meses o años atrás.

• Queremos comparar varias bases de datos o entornos.

• La retención local de AWR es reducida por motivos de espacio.

¿Cómo se alimenta AWR Warehouse?

La información no llega sola. CAW depende de una serie de jobs internos del repositorio OEM que se encargan de:

• Lanzar procesos de extracción.

• Conectarse a las bases de datos monitorizadas.

• Recoger los datos AWR necesarios.

• Cargarlos en el warehouse de forma centralizada.

En entornos RAC, el lugar donde se ejecuta este job sí importa:

• Puede afectar a la carga de una instancia concreta.

• Puede condicionar la conectividad hacia determinadas bases.

• Puede influir en el rendimiento general del repositorio OEM.

El objetivo es:

Controlar en qué instancia del RAC se ejecuta el proceso de extracción de AWR Warehouse, asegurando un comportamiento más predecible y alineado con nuestra arquitectura.

Aquí es donde entra en juego la necesidad de modificar el INSTANCE_ID del job, algo que OEM no permite hacer desde interfaz, pero que sí es posible a nivel de base de datos.

El Job interno identificado

Tras investigar, identificamos el job interno implicado:

MGMT_CAW_EXTRACT_JOB

Se trata de un job propiedad de SYS, gestionado por DBMS_SCHEDULER, y completamente oculto a nivel de interfaz gráfica.

Este job actúa como orquestador de la extracción, y su correcta ejecución es crítica para que los datos de rendimiento lleguen al warehouse.

¿Se puede modificar desde OEM?

No.

OEM no permite modificar este job desde la interfaz. No hay opción para cambiar atributos como la instancia en la que se ejecuta, ni su planificación.

Así que la única vía posible es actuar directamente contra la base de datos.

Modificando el Job directamente en base de datos

En nuestro caso, el objetivo era forzar la ejecución del job en una instancia concreta del RAC. Para ello, utilizamos el paquete DBMS_SCHEDULER y modificamos el atributo instance_id:

BEGIN
 DBMS_SCHEDULER.set_attribute(
 name => '"SYS"."MGMT_CAW_EXTRACT_JOB"',
 attribute => 'instance_id',
value => '2'
 );
END;
/

Puntos importantes a tener en cuenta:

• El job pertenece al esquema SYS, por lo que es necesario tener privilegios adecuados.

• El nombre debe ir completamente cualificado y entrecomillado.

• Este tipo de cambios no están documentados oficialmente, así que conviene aplicarlos con criterio y siempre en entornos controlados.

Monitorización de la ejecución

Una vez aplicado el cambio, pasamos a monitorizar el comportamiento real del job. Para ello, consultamos la vista DBA_SCHEDULER_JOB_RUN_DETAILS:

SELECT instance_id,
 log_date,
 owner,
 job_name,
 status,
 run_duration,
 output
FROM DBA_SCHEDULER_JOB_RUN_DETAILS
WHERE job_name = 'MGMT_CAW_EXTRACT_JOB'
ORDER BY log_date DESC;

Esta consulta nos permite ver:

• En qué instancia se ejecuta realmente (INSTANCE_ID)

• Cuándo se lanza (LOG_DATE)

• Duración y estado de cada ejecución

• Salida del job, muy útil para confirmar si hay generación efectiva de datos

Comportamiento observado

Aquí viene una de las claves más interesantes:

El job se ejecuta cada 3 horas.

Sin embargo, la extracción real de datos solo se produce cada 24 horas (configurado desde la interfaz)

Es decir:

No todas las ejecuciones implican una carga efectiva de información en el AWR Warehouse.

Esto explica por qué, aun viendo ejecuciones frecuentes, no siempre observamos actividad de generación de datos.