Inyectar errores en el Alert Log de Oracle sin romper nada (DBMS_SYSTEM.KSDWRT)
Mi nombre es Carla y me defino como una apasionada de conocer, compartir ideas, divertirme y aprender todo lo relacionado con Oracle.
Alegre y creativa, con un alto grado de autoexigencia, que busca, incluso sin querer, una forma diferente de ver un mismo problema o solución. Defensora del trabajo en equipo en todas las facetas de la vida y de disfrutar todo lo que haces, siempre con humildad.
Actualmente cuento con más de 15 años de experiencia como administradora de Oracle, habiendo ocupado previamente posiciones como desarrolladora en la rama de Inteligencia de Negocios. Fue en ese momento que me di cuenta de que no quería centrarme en el desarrollo, sino participar en todas las capas que involucraban los datos, desde el despliegue de la base de datos hasta su explotación final.
Siempre estoy dispuesta a ayudar y compartir conocimientos. Creo firmemente que con la tecnología hay que divertirse y no verla como una competencia. La persona con la que tienes que ser el mejor es contigo mismo.
El otro día configurando un parser de logs para pasarle las alertas del alert log a Nagios me encontré con el problema de siempre: ¿cómo pruebo que las alertas saltan bien sin liar una avería en la base de datos?
Lanzar una consulta tonta para probar un ORA-01476 (división por cero) o forzar un ORA-00942 en producción puede no ser buena idea. Y evidentemente no vas a ponerte a simular errores por probar....
Para estas cosas lo más rápido es tirar de un clásico que lleva ahí desde los tiempos de Oracle 8i: DBMS_SYSTEM.KSDWRT.
El truco: KSDWRT
Es un procedimiento interno (no documentado formalmente, como casi todo lo interesante de DBMS_SYSTEM) que te permite escribir la cadena de texto que te dé la gana directamente en el alert.log o en el archivo de traza de tu sesión.
La sintaxis va así de directa:
EXEC DBMS_SYSTEM.KSDWRT(2, 'ORA-00666: This is a test error message for monitoring and can be ignored.');
Tiene dos argumentos bastante simples:
Prametro 1 (Destino):
1-> Escribe solo en el trace file de la sesión.2-> Escribe directamente en el Alert Log.3-> Lo manda a los dos sitios a la vez.
Parámetro 2 (El texto): Literalmente la cadena que le pases. Si le metes el prefijo
ORA-xxxxx, cualquier agente basado en regex (Zabbix, Nagios, Datadog, OEM...) se lo traga como si hubiese saltado una excepción real.
Comprobarlo en caliente
Si lanzas eso con un usuario con privilegios de administración (SYSDBA), te vas a la ruta de trazas o tiras de la V$DIAG_ALERT_EXT si estás en 11g para arriba, y ves la línea limpia:
SELECT message_text
FROM v$diag_alert_ext
WHERE message_text LIKE '%test error message%'
ORDER BY originating_timestamp DESC;
Un par de apuntes de "perra vieja"
Avisa en el texto: Pon siempre algo como
TEST,MONITORING_CHECKoIGNORE. Si no lo pones, el agente de monitorización puede avisar al DBA de guardia a las 3 de la mañana y te va a odiar cuando vea que era una prueba.Ojo con los permisos:
DBMS_SYSTEMno debería tener permisos de ejecución para usuarios que no seanSYS. No se te ocurra darGRANT EXECUTEa esquemas de aplicación para esto.Úsalo para marcas de mantenimiento: Aparte de probar alertas, viene muy bien para meter "hitos" manuales en el log. Por ejemplo, tirar un
KSDWRT(2, 'INFO: Inicio de ventana de mantenimiento de patching')antes de tirar la instancia viene de lujo para auditar luego qué pasó y cuándo.
