Cuando una base de datos Oracle se ralentiza, el primer lugar donde un DBA debe mirar es el Informe AWR - una instantánea detallada de lo que ocurre dentro del sistema.
Revela dónde se invierte el tiempo, qué consultas consumen recursos y si la base de datos goza de buena salud o tiene problemas.
En este artículo, repasaremos las secciones clave que hay que comprobar para saber rápidamente si la base de datos funciona bien y dónde hay que centrar los esfuerzos de ajuste.
A continuación se muestra el orden que yo (y la mayoría de los DBA senior) seguimos al analizar un informe AWR:
🔎 Análisis AWR: Lista de comprobación paso a paso
1. 📊 Resumen del informe (sección superior)
Esto le da una resumen rápido de la salud de la base de datos.
- Tiempo de BD frente a tiempo transcurrido
- Muestra el tiempo total dedicado a la actividad de la base de datos.
- 🔍 Si DB Tiempo ≈ Tiempo transcurrido × #CPU núcleosLa carga de la base de datos es pesada.
- Regla de oro:
- ✅ Saludable: El tiempo de BD por segundo es similar al número de CPU (por ejemplo, ~8 s/s para 8 CPU)
- ❌ Malo: Un → mucho más alto indica cuellos de botella.
- Sesiones activas medias (AAS)
- Tiempo DB / Tiempo transcurrido
- ✅ Saludable: AAS ≤ número de núcleos de CPU.
- ❌ Malo: AAS > CPUs → el sistema está CPU-bound o esperando algo.
- %DB CPU
- Porcentaje de tiempo de la BD dedicado a la CPU.
- ✅ 60-90% significa que la mayor parte del tiempo se dedica a hacer un trabajo útil.
- ❌ Demasiado bajo → mayor tiempo de espera (IO, bloqueos, latches, etc.).
2. ⚙️ Perfil de carga
Esto le indica lo "ocupada" que está su base de datos.
- Llamadas a BD / Transacciones / Ejecuciones por segundo - Da idea de la carga de trabajo.
- Tamaño de repetición por segundo - Alto redo = DML pesado.
- Lecturas lógicas por segundo - Refleja la actividad de la caché del búfer.
- Lecturas físicas por segundo - Los valores altos pueden significar un almacenamiento en caché deficiente o exploraciones completas.
- Análisis por segundo - Demasiados parses = mala compartición del cursor (busque % alto de parses duros).
✅ Signos saludables:
- Baja tasa de análisis sintáctico (<5%)
- Lecturas lógicas >> lecturas físicas
- Análisis por ejecución < 0,1 (lo que significa que la mayoría de las sentencias se reutilizan)
3. 🔥 Los 5 principales eventos en primer plano cronometrados
Esto es el corazón del análisis AWR.
- Muestra dónde se pasa la mayor parte del tiempo de la base de datos.
- Busque los principales eventos de espera y compruebe su naturaleza:
| Tipo de evento | Significado | Qué pensar |
|---|---|---|
Tiempo de CPU | Buena señal si top | La base de datos está limitada por la CPU (compruebe el AAS y la CPU) |
archivo db lectura secuencial | E/S de un solo bloque (búsqueda de índices) | OK si es bajo, pero alto → E/S lenta o acceso excesivo al índice. |
archivo db lectura dispersa | Escaneado completo de tablas | Posibles índices que faltan |
sincronización de archivos de registro | Compromete esperas | Confirmar con demasiada frecuencia o redo lento I/O |
enq: TX - contención de bloqueo de fila | Contención de bloqueo | Problemas de concurrencia de aplicaciones |
latch: cadenas de memorias caché | Contención de bloques en caliente | Ajuste de la caché o las consultas |
buffer ocupado espera | Contención por bloques | Posiblemente un problema de almacenamiento o de patrón de acceso a los datos |
✅ Saludable:
- Tiempo de CPU en la cima o cerca de ella
- Los eventos de espera son bajos en tiempo total (<20% tiempo total BD)
❌ Malo:
- Las esperas sin CPU dominan
- Un evento de espera utiliza >30-40% de tiempo de BD → investigar la causa raíz.
4. 🧠 Porcentajes de eficiencia de las instancias
Esta sección suele malinterpretarse, pero algunas métricas clave son útiles:
- Buffer Hit %: Debería ser > 90%
- Biblioteca Hit %: Debería ser > 95%
- Soft Parse %: > 95% (si es bajo → compruebe el pool compartido o el cursor compartido)
- Picaporte Hit %: > 99%
Se trata de directrices generales: unos números malos significan un uso ineficiente de la memoria o problemas de reutilización de SQL.
5. Las mejores sentencias SQL
Compruebe el Top SQL por:
- Tiempo transcurrido
- Tiempo de CPU
- Buffer recibe
- Lecturas físicas
- Ejecuciones
✅ Saludable:
- Ningún SQL domina >30-40% del tiempo de BD.
❌ Problema:
- Una o dos sentencias SQL consumen la mayoría de los recursos → centrarse primero en afinar aquí.
6. 🧰 Estadísticas de E/S y archivos
Consulte Espacio de tablas IO, Archivo IOy Segmentos por lecturas físicas:
- Busque desequilibrios: un archivo de datos o tablespace haciendo 90% de IO → posible hotspot.
- Tiempos de lectura elevados (ms por lectura > 10 ms) → El subsistema IO es lento.
7. 🧵 Desglose de la clase de espera
Esto ofrece una visión de alto nivel de hacia dónde va el tiempo:
- CPU + E/S de usuario: Normalmente OK (carga de trabajo normal)
- Concurrencia, Compromiso, Configuración: Posible ajuste necesario
- Sistema E/S o Red: Posibles problemas de infraestructura
✅ Saludable:
- La mayor parte del tiempo se pasa en la CPU o en E/S de usuario.
❌ Malo:
- Porcentajes elevados en las clases de espera de Concurrencia, Compromiso o Configuración.
8. 📈 Estadísticas del SO
Compruebe la utilización de la CPU y la cola de ejecución:
- %Usuario + %Sys CPU < 90% → CPU OK
- Si Cola de ejecución > #CPUs → Saturación de la CPU
Comprueba también el uso de memoria y swap.
✅ Lista de comprobación rápida de salud final (atajo de DBA)
| Consulte | Buena señal | Mala señal |
|---|---|---|
| DB Tiempo / seg | ≈ Núcleos de CPU | >> núcleos de CPU |
| AAS | ≤ Núcleos de CPU | >> núcleos de CPU |
| CPU time top event | Sí | No |
| Tasa de éxito del búfer | > 90% | < 85% |
| Ratio de análisis sintáctico | > 95% | < 80% |
| Top SQL | Equilibrado | 1-2 SQL dominan |
| Latencia de lectura IO | < 10 ms | > 20 ms |
| Clases de espera | Principalmente CPU/Usuario E/S | Concurrencia, Commit, Config alta |
| Análisis sintáctico % | < 5% | > 10% |
✅ En resumen:
Una base de datos es haciendo bien si:
- El tiempo de BD y el AAS están alineados con la capacidad de la CPU.
- La CPU es la principal "espera".
- No predomina ningún evento SQL o de espera.
- Los porcentajes de aciertos son altos y los de análisis sintáctico, bajos.
- La latencia y la contención son mínimas.