Introducción
En algunos entornos Oracle gestionados desde Enterprise Manager Cloud Control (OEM), puede aparecer un error curioso y molesto en el alert log de la base de datos:
WARNING: too many parse errors, count=4390 SQL hash=0xb6a91e8f PARSE ERROR: ospid=3152219, error=904: Additional information: ... sqlid=fa9vmfqvak7ng Current username=SYS
Este tipo de error suele estar relacionado con llamadas automáticas que hace OEM a paquetes PL/SQL internos. En este caso concreto, se trataba del paquete OMC_ASH_VIEWER, que no estaba correctamente desplegado en la base de datos. Ups!!
Diagnóstico
Para confirmar que el error estaba relacionado con el paquete OMC_ASH_VIEWER ejecutamos:
SELECT dbsnmp.OMC_ASH_VIEWER.getVersion() FROM dual;
ORA-00904: "DBSNMP"."OMC_ASH_VIEWER"."GETVERSION": invalid identifier
¿Qué es OMC_ASH_VIEWER?
Es un paquete PL/SQL creado por OEM dentro del esquema DBSNMP, que se utiliza para recolectar datos de:
Este paquete forma parte del plugin oracle.sysman.db.oms.plugin, y se crea automáticamente mediante el job de OEM llamado:
Deploy Database Management PL/SQL Packages
Solución
Oracle ofrece una solución oficial (Doc ID 2769758.1) para este problema:
- Ejecutar el job desde OEM:
Desde la consola de Enterprise Manager:
Ir a Enterprise → Job → Activity
Hacer clic en Create Job
Buscar y seleccionar el tipo de job: Deploy Database Management PL/SQL Packages
Seleccionar el target afectado (base de datos o PDB)
Proporcionar credenciales SYSDBA válidas
Ejecutar inmediatamente (o programar)
- Verificación
Una vez desplegado correctamente, la siguiente consulta debería funcionar:
SYS@CDB$ROOT> SELECT dbsnmp.OMC_ASH_VIEWER.getVersion() FROM dual;
DBSNMP.OMC_ASH_VIEWER.GETVERSION()
_____________________________________
60
Y el alert log ya no mostrará errores de parse.
¿Qué hace internamente este job?
Este job ejecuta scripts como:
Esto permite a OEM acceder a vistas como GV$SESSION, DBA_HIST_*, V$SQL, etc., y generar informes y gráficos en el panel de rendimiento.
Conclusión
Este tipo de error puede pasar desapercibido si no revisamos el alert log con frecuencia, pero puede generar carga innecesaria y confusión.
Afortunadamente, la solución es sencilla si sabemos lo que buscamos: verificar y desplegar correctamente los paquetes PL/SQL de gestión desde OEM.
¿Te ha pasado algo similar en tus entornos? ¡Cuéntamelo en los comentarios!
