# Inyectar errores en el Alert Log de Oracle sin romper nada (DBMS_SYSTEM.KSDWRT)

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:

```plaintext
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:

```plaintext
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_CHECK` o `IGNORE`. 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_SYSTEM` no debería tener permisos de ejecución para usuarios que no sean `SYS`. No se te ocurra dar `GRANT EXECUTE` a 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.