Sin embargo, el alert log tradicional en formato texto tenía una característica poco conveniente: podía crecer indefinidamente. En instalaciones con varios años de operación no era extraño encontrar archivos alert_<SID>.log de varios gigabytes, obligando a los administradores a implementar mecanismos externos de rotación.
Oracle AI Database 26ai introduce un cambio importante en este comportamiento mediante el parámetro:
ALERT_LOG_MAX_SIZE
Su propósito es establecer un límite para el espacio utilizado por el alert log mediante un mecanismo automático de segmentación y rotación de archivos.
Nota aclaratoria: El parámetro existe realmente desde Oracle Database 23ai en el RU 23.9. Recordar que en la versión 23ai, 23.9 fue el último RU con ese consecutivo anterior, luego en Octubre de 2025 la versión fue renombrada a 23.26.0
RU 23.9: Julio de 2025
RU 23.26.0: Octubre de 2025 (Esta RU reemplazó conceptualmente a la 23.10 y marcó la transición a 26ai)
RU 23.26.1: Enero de 2026
RU 23.26.2: Abril de 2026
RU 23.26.3: Julio de 2026Nota aclaratoria: El parámetro existe realmente desde Oracle Database 23ai en el RU 23.9. Recordar que en la versión 23ai, 23.9 fue el último RU con ese consecutivo anterior, luego en Octubre de 2025 la versión fue renombrada a 23.26.0
RU 23.9: Julio de 2025
RU 23.26.0: Octubre de 2025 (Esta RU reemplazó conceptualmente a la 23.10 y marcó la transición a 26ai)
RU 23.26.1: Enero de 2026
RU 23.26.2: Abril de 2026
RU 23.26.3: Julio de 2026
El problema histórico del Alert Log
En versiones anteriores de Oracle, el archivo tradicional:
alert_<SID>.log
continuaba creciendo mientras la instancia estuviera operativa y el archivo no fuera administrado externamente.
Conceptualmente:
alert_ORCL.log
│
├── 500 MB
├── 2 GB
├── 5 GB
└── 10 GB ...
Oracle no establecía un tamaño máximo intrínseco para este archivo de texto.
Esto contrastaba con la representación XML del alert log dentro de la infraestructura de diagnóstico de Oracle, que ya utilizaba archivos segmentados.
Por ello, muchos administradores desarrollaron procedimientos propios para copiar, comprimir, truncar o rotar periódicamente el alert log textual.
Con Oracle AI Database 26ai esta situación cambia.
El parámetro ALERT_LOG_MAX_SIZE
ALERT_LOG_MAX_SIZE establece el tamaño máximo que Oracle permite utilizar para los segmentos del alert log.
Puede consultarse mediante:
SHOW PARAMETER alert_log_max_size;
o:
SELECT name,
value,
display_value
FROM v$parameter
WHERE name = 'alert_log_max_size';
Su valor predeterminado es:
1000M
Es decir, aproximadamente 1 GB.
Sin embargo, interpretar este valor simplemente como "un archivo de hasta 1 GB" sería incorrecto.
La característica fundamental del nuevo mecanismo es que Oracle trabaja con segmentos de aproximadamente 50 MB.
Por ejemplo:
ALERT_LOG_MAX_SIZE = 1000M
representa conceptualmente:
1000 MB / 50 MB = 20 segmentos
Oracle puede mantener así aproximadamente veinte segmentos antes de necesitar eliminar los más antiguos.
Segmentación en archivos de 50 MB
Oracle divide el contenido del alert log en segmentos cuyo tamaño máximo aproximado es de 50 MB.
Conceptualmente:
ALERT_LOG_MAX_SIZE = 1000M
┌──────────────────────────────────────────┐
│ │
│ 50M 50M 50M 50M 50M │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ seg1 seg2 seg3 ... seg19 seg20 │
│ │
└──────────────────────────────────────────┘
Cuando el segmento activo alcanza aproximadamente 50 MB, Oracle realiza automáticamente la transición hacia otro segmento.
Esto elimina la necesidad de mantener un único archivo textual que continúe creciendo durante toda la vida de la base de datos.
¿Qué ocurre cuando se alcanza ALERT_LOG_MAX_SIZE?
Este es el aspecto más importante del parámetro.
Cuando el conjunto de segmentos alcanza el límite determinado por ALERT_LOG_MAX_SIZE, Oracle no deja de registrar información.
Tampoco trunca completamente el alert log.
En su lugar, utiliza un comportamiento de rotación:
[01][02][03][04] ... [18][19][20]↑ ↑más antiguo más reciente
Cuando se necesita crear un nuevo segmento:
[02][03][04] ... [19][20][21]↑ ↑más antiguo más reciente
el segmento más antiguo puede ser eliminado para permitir que la información más reciente continúe registrándose sin superar el límite establecido.
Por tanto, ALERT_LOG_MAX_SIZE debe entenderse como un mecanismo de retención basada en volumen de información, no como una retención basada en tiempo.
Esta diferencia es operacionalmente significativa.
Retención por volumen y no por días
Supongamos una base de datos cuyo alert log genera aproximadamente:
40 MB/día
Con:
ALERT_LOG_MAX_SIZE = 1000M
teóricamente podría mantenerse un historial cercano a:
1000 / 40 = 25 días
Pero una base de datos que durante un incidente genere:
400 MB/día
mantendría aproximadamente:
1000 / 400 = 2.5 días
Esto significa que el parámetro no garantiza una cantidad determinada de días de diagnóstico.
Durante una situación anómala, miles de mensajes repetitivos podrían provocar una rotación considerablemente más rápida y, como consecuencia, la desaparición anticipada de información histórica.
Por esta razón, el dimensionamiento debería considerar el volumen real generado por cada base de datos.
Alert Log de texto y XML
Oracle mantiene diferentes representaciones del alert log.
En términos simplificados, dentro de la estructura de diagnóstico podemos encontrar archivos relacionados con:
trace/
alert_<SID>.log
alert/
log.xml
log_1.xml
log_2.xml
...
La representación XML ya utilizaba históricamente un mecanismo de segmentación automática.
El cambio especialmente significativo de ALERT_LOG_MAX_SIZE es que Oracle incorpora una gestión equivalente para evitar el crecimiento ilimitado del alert log tradicional en formato texto.
Con un valor diferente de cero, el parámetro participa en el control del tamaño máximo utilizado por los segmentos del alert log.
De esta forma, Oracle 26ai proporciona una política más uniforme y predecible para controlar el almacenamiento utilizado por esta información diagnóstica.
El caso especial ALERT_LOG_MAX_SIZE=0
El valor:
ALTER SYSTEM SET ALERT_LOG_MAX_SIZE=0;
tiene un significado especial.
En este caso se elimina el límite de tamaño impuesto por el parámetro.
Para el alert log tradicional de texto, esto permite nuevamente un comportamiento similar al histórico:
alert_<SID>.log
│
└── crecimiento sin límite establecido
En cambio, el alert log XML continúa utilizando su mecanismo de segmentación:
log.xml
log_1.xml
log_2.xml
log_3.xml
...
pero la cantidad de segmentos puede continuar creciendo al no existir el límite impuesto por ALERT_LOG_MAX_SIZE.
Por tanto:
ALERT_LOG_MAX_SIZE = 0
no significa "desactivar el alert log", sino desactivar el límite de tamaño asociado al parámetro.
Valores que no sean múltiplos de 50 MB
Otro comportamiento importante es que Oracle trabaja con unidades de segmentación de aproximadamente 50 MB.
Si se establece:
ALTER SYSTEM SET ALERT_LOG_MAX_SIZE=120M;
Oracle no puede representar exactamente 120 MB utilizando segmentos completos de 50 MB.
Conceptualmente:
120 / 50 = 2.4
Se requieren tres segmentos:
3 × 50 MB = 150 MB
Por tanto, Oracle ajusta el límite efectivo al siguiente múltiplo apropiado.
Algunos ejemplos conceptuales serían:
| Configuración | Segmentos necesarios | Tamaño efectivo aproximado |
|---|---|---|
| 50M | 1 | 50 MB |
| 100M | 2 | 100 MB |
| 120M | 3 | 150 MB |
| 200M | 4 | 200 MB |
| 525M | 11 | 550 MB |
| 1000M | 20 | 1000 MB |
Por ello resulta conveniente configurar valores coherentes con la unidad de segmentación utilizada por Oracle.
Modificación dinámica
ALERT_LOG_MAX_SIZE puede modificarse dinámicamente mediante ALTER SYSTEM.
Por ejemplo:
ALTER SYSTEM
SET ALERT_LOG_MAX_SIZE=500M
SCOPE=BOTH;
o:
ALTER SYSTEM
SET ALERT_LOG_MAX_SIZE=2G
SCOPE=BOTH;
No es necesario reiniciar la instancia para modificarlo.
El parámetro tampoco es modificable individualmente dentro de una PDB. Su ámbito corresponde a la instancia y debe administrarse desde el contexto apropiado del CDB.
En ambientes Oracle RAC, diferentes instancias pueden técnicamente utilizar valores diferentes, aunque desde el punto de vista operacional suele resultar conveniente mantener una política homogénea de diagnóstico entre los nodos.
Una nueva filosofía de administración
La incorporación de ALERT_LOG_MAX_SIZE representa un cambio pequeño desde el punto de vista sintáctico, pero considerable desde la perspectiva operacional.
Durante muchos años la administración del alert log textual dependió de procedimientos desarrollados por cada organización:
Alert Log
↓
script externo
↓
copiar
↓
comprimir
↓
truncar
↓
conservar histórico
Oracle 26ai incorpora ahora directamente una parte importante de este proceso:
Alert Log
↓
segmentos de ~50 MB
↓
rotación automática
↓
límite ALERT_LOG_MAX_SIZE
↓
eliminación de segmentos antiguos
Esto reduce la posibilidad de que un alert log olvidado termine consumiendo varios gigabytes del filesystem.
Consideraciones para ambientes de producción
El valor predeterminado de 1000M no debería aceptarse automáticamente como adecuado para todas las bases de datos.
Una estrategia razonable consiste en determinar primero cuánto alert log genera normalmente la instancia.
Por ejemplo:
Volumen promedio diario
×
histórico deseado
=
ALERT_LOG_MAX_SIZE aproximado
Una base que produzca 25 MB diarios y otra que produzca 300 MB diarios tienen necesidades de retención completamente diferentes.
También debe considerarse que precisamente durante un incidente —cuando más importante resulta conservar información diagnóstica— el volumen del alert log puede incrementarse considerablemente.
Por ello, configurar un valor demasiado pequeño puede provocar que los segmentos que contienen el inicio del problema desaparezcan mientras el incidente todavía está siendo investigado.
Conclusión
ALERT_LOG_MAX_SIZE moderniza un componente que durante décadas mantuvo un comportamiento prácticamente inalterado.
La principal diferencia puede resumirse de la siguiente manera:
ANTES
alert_<SID>.log
↓
crecimiento potencialmente ilimitado
ORACLE AI DATABASE 26ai
alert log
↓
segmentos de ~50 MB
↓
rotación automática
↓
ALERT_LOG_MAX_SIZE
↓
eliminación de segmentos antiguos
El valor predeterminado de 1000M proporciona aproximadamente 1 GB de capacidad antes de que sea necesario reutilizar el espacio mediante la eliminación de los segmentos más antiguos.
Por tanto, el parámetro no debe interpretarse únicamente como una medida de protección del filesystem. Constituye también una política de retención diagnóstica basada en volumen.
Para un DBA, esa es probablemente su implicación más importante: cuanto mayor sea la actividad registrada en el alert log, menor será el período histórico representado por una determinada configuración de ALERT_LOG_MAX_SIZE.
Oracle AI Database 26ai sustituye así el modelo histórico de "un archivo que continúa creciendo" por un mecanismo controlado de segmentación, rotación y conservación de la información más reciente, haciendo que la administración del alert log sea más predecible y menos dependiente de procedimientos externos.
