Durante unas semanas notábamos picos puntuales de CPU en nuestros servidores Oracle Grid Infrastructure y bases de datos, sin actividad aparente de los usuarios. La carga aparecía siempre a la misma hora: 15:18, y duraba unos segundos, pero disparaba el consumo de CPU de varios procesos perl y java del agente de Oracle Enterprise Manager Cloud Control (OEM).
Esto nos llevó a una pequeña investigación para entender qué ocurría y, finalmente, a mover la ventana de ejecución de los jobs de inventario de parches del agente a una hora menos conflictiva.
Introducción
En los últimos días detectamos un pico recurrente de carga de CPU alrededor de las 15:18 en nuestros nodos de base de datos. Este patrón se repetía casi a diario y afectaba al rendimiento de las transacciones durante unos minutos.
El objetivo de este artículo es explicar:
Cómo detectamos el patrón.
Cómo lo diagnosticamos hasta identificar la causa raíz.
Cómo reprogramamos la tarea para evitar que se ejecute en horario crítico de negocio.
Detección inicial: patrón recurrente en transacciones
Todo comenzó revisando métricas de nuestra base de datos de negocio. Vimos un patrón repetido de demora de rendimiento en torno a las 15:18.
Correlación con el agente de Cloud Control
Al revisar el log del agente en:
$AGENT_HOME/agent_inst/sysman/log/gcagent.log
Vimos entradas exactamente a esa hora:
2025-08-26 15:18:44,807 [GC.Executor... oracle_home_config:PatchFixedBug] xxxxxxxxxxxxxxxxxx
También lo comprobamos en los dos nodos del RAC con:
$AGENT_HOME/bin/emctl status agent scheduler | grep -i oracle_home_config
Resultado:
2025-08-27 15:18:41.788 : oracle_home:OraHomeXX_rac-xxx-001:oracle_home_config
2025-08-27 15:18:42.857 : oracle_home:OraGIXXHome1_1_rac-xxx-001:oracle_home_config
Y justo en ese momento, top mostraba varios procesos perl y java consumiendo >190% de CPU:
PID USER %CPU COMMAND
51242 agent13 190 java
51273 agent13 84 perl
51522 agent13 81 perl
Diagnóstico
Confirmamos así que:
A las 15:18, el agente de Oracle Enterprise Manager Cloud Control lanza tareas de tipo oracle_home_config:PatchFixedBug, que forman parte de la Configuration Collection.
Estas tareas ejecutan internamente herramientas como OPatch para recoger el inventario de parches aplicados en cada Oracle Home y en la Grid Infrastructure.
Esto provoca un pico puntual de CPU, suficiente para afectar a otras cargas sensibles en ese instante.
Cambiando la ventana de ejecución
Para evitar el impacto en horario de negocio, decidimos mover la ventana de ejecución de esos jobs a la madrugada.
Pasos:
Listar las tareas programadas del agente:
$AGENT_HOME/bin/emctl status agent scheduler
Identificar las tareas oracle_home_config
oracle_home:OraGIXXHome1_1_rac-xxx-001:oracle_home_config oracle_home:OraHomeXX_rac-xxx-001:oracle_home_config
Reprogramarlas con una nueva hora de inicio donde haya menos afección (ejemplo: 04:45 AM):
Repetir para cada Oracle Home.
Confirmar el cambio:
$AGENT_HOME/bin/emctl status agent scheduler | grep oracle_home_config
[agent13@rac-xxx-002 ~]$ $AGENT_HOME/bin/emctl status agent scheduler | grep -i oracle_home_config
2025-08-27 21:42:55.879 : oracle_home:agent13c1_3_rac-xxx-002.paytef.local_8730:oracle_home_config
2025-08-28 04:30:00.000 : oracle_home:OraGIXXHome1_1_rac-xxx-002.paytef.local_8611:oracle_home_config
2025-08-28 04:45:00.000 : oracle_home:OraHomeXX_rac-xxx-002.paytef.local_6495:oracle_home_config
Resultado
Desde que movimos las tareas, desaparecieron los picos de CPU en horario laboral y no hemos vuelto a ver demoras en tiempos a las 15:18.
La tarea sigue ejecutándose correctamente, pero en una ventana sin carga de usuarios.
Conclusión
Aunque el agente de Oracle Enterprise Manager Cloud Control trabaja de forma desatendida, sus tareas de inventario pueden ser muy pesadas.
Monitorizar patrones horarios y correlacionarlos con los logs del agente permite anticiparse a estos cuellos de botella invisibles y recolocar su ventana de ejecución para que no interfieran con el negocio.
