# 🩻 Análisis Postmortem con AWR: El caso de la AUD$ desbordada

---

## 🧠 Introducción

En ocasiones, las bases de datos nos hablan… pero no siempre estamos escuchando.

Esta vez, los síntomas eran difusos: lentitud intermitente, sesiones en espera, y una sensación general de que “algo no estaba bien”. Fue solo al revisar los reportes AWR cuando la verdad se reveló con claridad clínica: **una tabla** `AUD$` desbordada, sin particionar y con auditoría activada sin control estaba consumiendo más recursos de los que imaginábamos.

Lo que parecía una simple configuración por defecto terminó generando esperas graves como `buffer busy waits` y `gc buffer busy acquire`, afectando al sistema completo.

En esta edición de la botica, te comparto un caso real que nos recordó por qué incluso las tablas del sistema merecen nuestra atención. Y como siempre, te llevas la receta: pasos claros para diagnosticar, corregir y prevenir este tipo de situaciones.

Porque en La Botica del DBA, cada historia trae una lección… y cada lección, su remedio.

---

## 🔍 Síntomas revelados por AWR

Estos fueron los eventos de espera más dominantes:

| Evento | % del DB Time |
| --- | --- |
| buffer busy waits | 58.1% |
| gc buffer busy acquire | 31.6% |
| enq: HW | 7.6% |

La base estaba saturada por contención de buffers y problemas de concurrencia. Algo grave estaba ocurriendo detrás de escena.

---

## 🧬 Hallazgo de laboratorio: AUD$ sin control

El AWR señalaba consistentemente una tabla: `SYS.AUD$`. Al analizar más a fondo, vemos que:

* Auditoría activada de forma amplia (nivel sentencia y objeto).
    
* Inserciones continuas y concurrentes por parte de la aplicación.
    
* Tabla **no particionada**.
    
* Sin políticas de retención ni purga.
    
* Sin optimización para entornos OLTP intensivos.
    

Esto generaba cuellos de botella por contención de bloques, latches y saturación de espacio libre en segmentos.

---

## 🧯 Receta para evitar otro colapso

> Si tienes auditoría activa en producción, **esto te interesa**:

* ✅ **Particionar** `AUD$` por día, mes o rango.
    
* ✅ Usar `DBMS_AUDIT_MGMT` para manejar retención y purga automática.
    
* ✅ Limitar el nivel de auditoría solo a lo necesario.
    
* ✅ Mover `AUD$` a su propia tablespace si aplica.
    
* ✅ Considerar migrar a **auditoría unificada** (`Unified Auditing`) en versiones modernas.
    

---

## 📦 Botiquín del DBA

Aquí algunos comandos de apoyo que puedes tener a mano:

```sql
-- Ver cantidad de registros en AUD$
SELECT COUNT(*) FROM SYS.AUD$;

-- Consultar estadísticas de la tabla
SELECT * FROM DBA_TAB_STATISTICS WHERE TABLE_NAME = 'AUD$';

-- Inicializar gestión de auditoría
BEGIN
  DBMS_AUDIT_MGMT.INIT_CLEANUP(
    AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
    DEFAULT_CLEANUP_INTERVAL => 24 );
END;
/

-- Crear job automático de purga
BEGIN
  DBMS_AUDIT_MGMT.CREATE_PURGE_JOB(
    AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
    AUDIT_TRAIL_PURGE_INTERVAL => 24,
    AUDIT_TRAIL_PURGE_NAME => 'Purge_AUD$',
    USE_LAST_ARCH_TIMESTAMP => TRUE );
END;
/
```

## 🧠 Reflexión final

El análisis postmortem no es para culpar al muerto, sino para aprender y mejorar. El AWR nos mostró la evidencia, pero la causa raíz estaba en una mala configuración de auditoría, algo silencioso pero letal para el rendimiento.

### 💌 ¿Te gustó esta receta?

Suscríbete a nuestro boletín y recibe cada semana/mes a mes un caso real, una solución y/o un tip de rendimiento directo de la botica.

🔗 www.laboticadeldba.com

📩 admin@laboticadeldba.com

Hasta la próxima consulta, colega DBA. — El Boticario del DBA 🧙⚗️