Cómo generar y analizar un reporte AWR en Oracle Database 19c y 21c

Cuando una base de datos Oracle presenta lentitud, consumo elevado de CPU, problemas de I/O, bloqueos o tiempos de respuesta inconsistentes, uno de los recursos más importantes para un DBA es el reporte AWR.

AWR, o Automatic Workload Repository, conserva estadísticas históricas sobre la carga y el rendimiento de la base de datos. Un reporte AWR compara dos snapshots y muestra lo ocurrido durante ese intervalo: carga, sesiones, SQL costoso, eventos de espera, uso de CPU, actividad de I/O, memoria, bloqueos, redo, undo y otros indicadores.

Esta guía explica cómo generar el reporte y, sobre todo, cómo interpretarlo para diagnosticar incidentes y prevenir problemas en Oracle Database 19c y 21c.

Importante: El uso de AWR requiere una licencia válida de Oracle Diagnostics Pack. Antes de generar, consultar o automatizar reportes AWR, verifica las licencias contratadas por tu organización. Si no cuentas con Diagnostics Pack, considera utilizar Statspack y las vistas dinámicas permitidas por tu licencia.

1. ¿Cómo funciona AWR?

Oracle recopila periódicamente estadísticas de rendimiento y las almacena en snapshots dentro del repositorio AWR.

De forma predeterminada, Oracle genera un snapshot cada 60 minutos y conserva la información durante ocho días. Tanto el intervalo como la retención pueden modificarse, aunque aumentar la retención incrementa el espacio utilizado en el tablespace SYSAUX. La documentación oficial describe este funcionamiento para Oracle Database 19c y Oracle Database 21c.

El reporte no muestra el estado actual de la base de datos. Presenta los valores acumulados o las diferencias registradas entre dos snapshots.

Por esta razón, la selección del intervalo es fundamental. Si el incidente ocurrió entre las 10:15 y las 10:40, un reporte de todo el día puede diluir el problema. Lo recomendable sería generar un reporte que cubra aproximadamente de las 10:00 a las 11:00 y compararlo con otro intervalo saludable.

2. Requisitos previos

Antes de generar el reporte, valida:

Que la edición y las licencias contratadas permitan utilizar Diagnostics Pack.
Que STATISTICS_LEVEL se encuentre en TYPICAL o ALL.
Que existan snapshots para el periodo del incidente.
Que el usuario tenga permisos administrativos suficientes.
Que la hora del incidente esté correctamente identificada.
Que no haya ocurrido un reinicio de la instancia dentro del intervalo.
Que estés conectado al contenedor, PDB o instancia correctos.

Comprueba el nivel de estadísticas:

SHOW PARAMETER statistics_level;

También puedes consultarlo mediante SQL:

SELECT name, value
FROM v$parameter
WHERE name = 'statistics_level';

Un valor BASIC deshabilita varias funciones automáticas de recopilación de estadísticas y no es apropiado para el uso normal de AWR.

3. Revisar la configuración de snapshots

La vista DBA_HIST_WR_CONTROL muestra el intervalo y la retención configurados:

SELECT dbid,
       snap_interval,
       retention,
       topnsql
FROM dba_hist_wr_control;

Oracle documenta DBA_HIST_WR_CONTROL como la vista de control del Workload Repository, incluyendo el intervalo y la retención de snapshots. Consulta la referencia oficial de Oracle 19c.

Para listar los snapshots disponibles:

SELECT snap_id,
       dbid,
       instance_number,
       begin_interval_time,
       end_interval_time,
       startup_time,
       snap_flag,
       error_count
FROM dba_hist_snapshot
ORDER BY snap_id DESC;

Las columnas más importantes son:

SNAP_ID: identificador del snapshot.
INSTANCE_NUMBER: instancia a la que pertenece.
BEGIN_INTERVAL_TIME: inicio del intervalo.
END_INTERVAL_TIME: fin del intervalo.
STARTUP_TIME: hora de inicio de la instancia.
ERROR_COUNT: errores encontrados al crear el snapshot.
SNAP_FLAG: indica si fue automático, manual, importado o creado bajo otra condición.

La definición completa está disponible en la documentación de DBA_HIST_SNAPSHOT.

4. Generar un snapshot manual

Un snapshot manual es útil antes y después de:

Una prueba de carga.
Un despliegue importante.
La ejecución de un proceso batch.
Un cambio de configuración.
Una ventana de mantenimiento.
La reproducción controlada de un problema.

Para crearlo:

EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

También puede especificarse el nivel de recopilación:

BEGIN
    DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(
        flush_level => 'TYPICAL'
    );
END;
/

El nivel ALL recopila más información, pero puede generar una carga y un volumen de datos mayores:

BEGIN
    DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(
        flush_level => 'ALL'
    );
END;
/

No es recomendable utilizar ALL continuamente sin evaluar su impacto.

5. Generar el reporte AWR con SQL*Plus

Conéctate a la base de datos utilizando SQL*Plus:

sqlplus / as sysdba

Localiza el directorio de scripts administrativos:

SHOW PARAMETER oracle_home;

Ejecuta el script principal:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

El script solicitará:

El formato del reporte: html o text.
El número de días de snapshots que deben mostrarse.
El snapshot inicial.
El snapshot final.
El nombre del archivo.

Ejemplo:

Enter value for report_type: html
Enter value for num_days: 1
Enter value for begin_snap: 15420
Enter value for end_snap: 15421
Enter value for report_name: awr_prod_15420_15421.html

Para facilitar la lectura, normalmente conviene seleccionar html.

Scripts relacionados

Oracle incluye diferentes scripts para situaciones específicas:

Script	Uso principal
`awrrpt.sql`	Reporte AWR estándar
`awrrpti.sql`	Permite seleccionar explícitamente DBID e instancia
`awrgrpt.sql`	Reporte global para Oracle RAC
`awrgrpti.sql`	Reporte RAC seleccionando DBID
`awrddrpt.sql`	Compara dos periodos AWR
`awrddrpi.sql`	Comparación seleccionando DBID e instancia
`awrgdrpt.sql`	Comparación global de periodos en RAC
`ashrpt.sql`	Reporte de Active Session History
`addmrpt.sql`	Reporte de Automatic Database Diagnostic Monitor

La disponibilidad exacta de algunos scripts puede depender de la versión y del Release Update instalado.

6. Generar un reporte mediante PL/SQL

También puede generarse directamente con DBMS_WORKLOAD_REPOSITORY.

Reporte HTML

SET LONG 10000000
SET LONGCHUNKSIZE 10000000
SET PAGESIZE 0
SET LINESIZE 32767
SET TRIMSPOOL ON
SET FEEDBACK OFF
SET HEADING OFF

SPOOL awr_report.html

SELECT output
FROM TABLE(
    DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(
        l_dbid     => 123456789,
        l_inst_num => 1,
        l_bid      => 15420,
        l_eid      => 15421
    )
);

SPOOL OFF

Reporte en texto

SET LINESIZE 200
SET PAGESIZE 0
SET LONG 10000000
SET LONGCHUNKSIZE 10000000

SPOOL awr_report.txt

SELECT output
FROM TABLE(
    DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT(
        l_dbid     => 123456789,
        l_inst_num => 1,
        l_bid      => 15420,
        l_eid      => 15421
    )
);

SPOOL OFF

El DBID puede obtenerse con:

SELECT dbid, name
FROM v$database;

Y el número de instancia:

SELECT instance_number, instance_name
FROM v$instance;

7. Consideraciones para Oracle RAC

En RAC no basta con revisar una sola instancia si el problema afectó a todo el servicio.

Debemos determinar:

En qué instancia se ejecutó la mayor parte de la carga.
Si existió desequilibrio entre instancias.
Si el servicio estaba distribuido correctamente.
Si hubo esperas relacionadas con Global Cache.
Si existieron problemas en la interconexión.
Si una instancia concentró sesiones o SQL costoso.

Para una revisión completa utiliza awrgrpt.sql:

@$ORACLE_HOME/rdbms/admin/awrgrpt.sql

Entre los indicadores específicos de RAC deben revisarse:

gc cr request
gc current request
gc buffer busy acquire
gc buffer busy release
Global Cache transfer time
Bloques recibidos por Cache Fusion
Interconnect traffic
Distribución de servicios y sesiones

Una cantidad alta de eventos gc puede indicar acceso remoto excesivo a bloques, mala afinidad de servicios, objetos “calientes”, secuencias, índices con contención o un problema de red entre nodos.

8. Consideraciones para CDB y PDB

En arquitecturas multitenant es necesario confirmar si el análisis se realizará en:

CDB$ROOT
Una PDB concreta
Toda la CDB
Una instancia específica de RAC

Comprueba el contenedor actual:

SHOW CON_NAME;

Lista los contenedores:

SELECT con_id, name, open_mode
FROM v$containers
ORDER BY con_id;

En Oracle 19c y 21c, la recopilación automática de AWR a nivel PDB puede depender de la configuración de:

SHOW PARAMETER awr_pdb_autoflush_enabled;

Si la recopilación a nivel PDB no estaba habilitada antes del incidente, conectarse posteriormente a la PDB no creará de manera retroactiva los datos faltantes.

Al analizar una CDB, presta atención a CON_ID, ya que permite relacionar la actividad con el contenedor correspondiente.

9. Cómo interpretar las secciones más importantes

9.1 Report Summary

La cabecera confirma:

DBID y nombre de la base.
Número y nombre de instancia.
Versión de Oracle.
Plataforma.
Cantidad de CPU.
Memoria.
Snapshots seleccionados.
Duración del periodo.
Tiempo que la instancia estuvo activa.
Número de sesiones.
Cantidad de cores y sockets.

Antes de continuar, valida que el reporte corresponda exactamente a la base, instancia y periodo del incidente.

Si Startup Time cambia entre los snapshots, la instancia fue reiniciada. Comparar contadores a través de un reinicio puede producir resultados incompletos o poco representativos.

9.2 DB Time y DB CPU

DB Time representa el tiempo acumulado consumido por las sesiones activas en llamadas de base de datos.

Incluye:

Tiempo utilizando CPU.
Tiempo esperando eventos no idle.

No es equivalente al tiempo transcurrido. Si diez sesiones trabajan simultáneamente durante un minuto, pueden acumular aproximadamente diez minutos de DB Time.

Una relación útil es:

DB Time = DB CPU + tiempo de espera no idle

Interpretación general:

DB CPU cerca de DB Time: carga principalmente limitada por CPU.
DB Time muy superior a DB CPU: la base pasa una parte significativa del tiempo esperando.
Incremento repentino de DB Time: mayor carga, degradación de SQL, bloqueo o contención.
DB Time elevado con pocas transacciones: cada transacción se volvió más costosa.

9.3 Load Profile

Load Profile muestra la carga por segundo y por transacción.

Incluye normalmente:

DB Time.
DB CPU.
Redo generado.
Logical reads.
Physical reads.
Physical writes.
User calls.
Parses.
Hard parses.
Logons.
Executes.
Rollbacks.
Transactions.

No deben analizarse únicamente los valores absolutos. Lo más útil es compararlos con un periodo normal.

Ejemplos:

Más Logical reads con el mismo volumen de negocio puede indicar un plan de ejecución menos eficiente.
Más Hard parses puede señalar SQL sin variables bind, presión en shared pool o invalidaciones.
Mucho redo puede relacionarse con cargas masivas, commits excesivos o actualizaciones innecesarias.
Muchos logons por segundo pueden indicar falta de pool de conexiones.
Un incremento en rollbacks puede revelar errores de aplicación o transacciones fallidas.

9.4 Instance Efficiency Percentages

Esta sección incluye ratios como:

Buffer Nowait.
Buffer Hit.
Library Hit.
Soft Parse.
Execute to Parse.
Parse CPU to Parse Elapsed.
Non-Parse CPU.

Estos porcentajes pueden orientar, pero no deben utilizarse como diagnóstico aislado.

Por ejemplo, un Buffer Cache Hit Ratio alto no demuestra que la base tenga buen rendimiento. Una consulta que lea millones de bloques desde memoria puede seguir siendo muy costosa.

En análisis L3 deben priorizarse DB Time, eventos de espera, SQL, planes de ejecución y carga real.

9.5 Top Foreground Events

Esta es una de las secciones más importantes. Muestra dónde consumieron tiempo las sesiones de usuario.

Eventos comunes:

Evento	Posible interpretación
`DB CPU`	Procesamiento intensivo, SQL costoso o saturación de CPU
`db file sequential read`	Lecturas individuales, comúnmente accesos por índice
`db file scattered read`	Lecturas multibloque, frecuentemente full scans
`direct path read`	Lecturas directas, operaciones paralelas o scans grandes
`direct path read temp`	Lectura desde TEMP por spill de memoria
`direct path write temp`	Escritura en TEMP por sorts o hash joins
`log file sync`	Sesiones esperando confirmación de commits
`log file parallel write`	Escritura de redo por LGWR
`enq: TX - row lock contention`	Bloqueos entre transacciones
`buffer busy waits`	Contención por bloques
`library cache lock`	Contención o cambios sobre objetos compartidos
`cursor: pin S wait on X`	Contención sobre cursores
`SQL*Net more data to client`	Transferencia elevada de datos al cliente

Una espera alta no siempre significa un problema en Oracle. Debe correlacionarse con el SQL, el volumen de trabajo, el almacenamiento, el sistema operativo y el comportamiento de la aplicación.

9.6 Host CPU y métricas del sistema operativo

Revisa:

Número de CPUs.
Load average.
User CPU.
System CPU.
Idle CPU.
I/O wait.
OS statistics.

Señales de alerta:

CPU idle cercana a cero durante periodos prolongados.
Load average muy superior a la capacidad de CPU.
Alto consumo de system CPU.
Alta espera de I/O.
DB CPU elevado y run queue alta.

AWR presenta la perspectiva de Oracle, pero debe correlacionarse con herramientas del sistema operativo:

top
vmstat 1
iostat -xz 1
sar -u 1
sar -q 1
pidstat 1

9.7 SQL ordered by Elapsed Time

Muestra el SQL que más tiempo total consumió.

Debes revisar:

Elapsed Time.
Executions.
Tiempo por ejecución.
Porcentaje del DB Time.
CPU Time.
I/O Wait.
SQL ID.
Module.

Un SQL puede aparecer arriba por dos razones:

Se ejecuta pocas veces, pero cada ejecución es muy lenta.
Cada ejecución es rápida, pero se ejecuta miles o millones de veces.

La solución es diferente en cada caso.

9.8 SQL ordered by CPU Time

Ayuda a identificar sentencias que consumen CPU.

Posibles causas:

Full scans innecesarios.
Joins costosos.
Funciones ejecutadas fila por fila.
Predicados no selectivos.
Índices ausentes o inadecuados.
Planes de ejecución degradados.
Exceso de logical reads.
Operaciones paralelas no controladas.

9.9 SQL ordered by Gets y Reads

Buffer Gets representa lecturas lógicas. Un número elevado suele indicar que el SQL visita demasiados bloques, incluso si estos están en memoria.

Physical Reads muestra lecturas que necesitaron acceder al almacenamiento.

Analiza ambos indicadores:

Muchos gets y pocas lecturas físicas: SQL ineficiente ejecutándose principalmente desde caché.
Muchas lecturas físicas: working set mayor que la caché, scans grandes o presión de I/O.
Pocas ejecuciones con millones de gets por ejecución: candidato prioritario para tuning.
Muchas ejecuciones con pocos gets: posible optimización desde la aplicación o reducción de llamadas.

Oracle conserva estadísticas históricas del SQL superior en DBA_HIST_SQLSTAT y las complementa con texto, entorno del optimizador y planes. Consulta la documentación de DBA_HIST_SQLSTAT.

9.10 SQL ordered by Parse Calls y Version Count

Estas secciones ayudan a identificar problemas de parsing.

Señales importantes:

Hard parses elevados.
Parse calls cercanos al número de ejecuciones.
Version count alto.
Invalidaciones frecuentes.
Baja reutilización de cursores.

Posibles causas:

Ausencia de variables bind.
Diferencias en parámetros de sesión.
Cambios de NLS.
Objetos recompilados.
Privilegios diferentes.
Bind mismatch.
Cambios en estadísticas.
Shared pool insuficiente.
Código que abre y cierra cursores innecesariamente.

9.11 Segments by Logical Reads, Physical Reads y Buffer Busy Waits

Estas secciones identifican objetos con mayor carga:

Tablas.
Índices.
Particiones.
LOB.
Segmentos temporales.

La información histórica por segmento se encuentra en DBA_HIST_SEG_STAT, que conserva estadísticas de los segmentos superiores capturados desde V$SEGSTAT. Consulta la referencia oficial.

Un segmento con mucha actividad no necesariamente está mal. Puede ser el objeto central de la aplicación. Lo importante es determinar si la actividad coincide con el volumen de negocio y si presenta contención.

9.12 I/O Statistics

Revisa estadísticas por:

Tablespace.
Datafile.
Función.
Tipo de archivo.
Número y tamaño de lecturas.
Número y tamaño de escrituras.
Tiempo promedio de servicio.

Busca:

Datafiles con latencia notablemente superior.
Tablespaces que concentran la mayor carga.
TEMP con actividad excesiva.
Lecturas pequeñas y aleatorias con alta latencia.
Escrituras de redo lentas.
Desequilibrio entre discos o diskgroups.

Si se utiliza ASM, complementa el análisis con:

SELECT name,
       total_mb,
       free_mb,
       usable_file_mb,
       type,
       state
FROM v$asm_diskgroup;

9.13 PGA y uso de TEMP

Las secciones de PGA muestran:

Memoria asignada.
Work areas ejecutadas en modo optimal.
Operaciones one-pass.
Operaciones multipass.
Uso de memoria para sorts y hash joins.

Interpretación:

Optimal: la operación se completó en memoria.
One-pass: fue necesario escribir y leer una vez desde TEMP.
Multipass: se requirieron múltiples pasadas por TEMP.

Una cantidad significativa de operaciones multipass puede indicar:

PGA insuficiente.
SQL con joins o sorts demasiado grandes.
Mala cardinalidad.
Falta de filtros.
Paralelismo excesivo.
Plan de ejecución inadecuado.

No aumentes PGA_AGGREGATE_TARGET automáticamente. Primero identifica el SQL responsable y valida el consumo total del servidor.

9.14 SGA, Buffer Cache y Shared Pool

AWR permite observar:

Buffer cache.
Shared pool.
Large pool.
Java pool.
Caché de cursores.
Reloads.
Invalidations.
Actividad del library cache.

Posibles señales:

Shared pool reloads elevados.
Invalidaciones frecuentes.
Fallos de asignación.
Hard parsing alto.
Presión en buffer cache.
Cambios frecuentes de tamaño bajo administración automática.

Antes de modificar la SGA, correlaciona esta información con:

SELECT component,
       current_size,
       min_size,
       max_size,
       user_specified_size,
       last_oper_type,
       last_oper_mode
FROM v$sga_dynamic_components;

9.15 Redo, commits y `log file sync`

Cuando log file sync aparece entre las principales esperas, revisa:

Commits por segundo.
Redo size.
Redo writes.
Tiempo de log file parallel write.
Tamaño y frecuencia de log switches.
Rendimiento del almacenamiento de redo.
Comportamiento transaccional de la aplicación.

Si log file parallel write también es lento, puede existir un problema de almacenamiento.

Si log file parallel write es rápido, pero log file sync es alto, investiga:

Commits demasiado frecuentes.
Scheduling de CPU.
LGWR.
Contención interna.
Aplicaciones que hacen commit por cada fila.

9.16 Undo

La sección de undo ayuda a detectar:

Consumo elevado.
Transacciones largas.
Riesgo de ORA-01555: snapshot too old.
Retención insuficiente.
Bloques no expirados reutilizados.
Incrementos anormales en la tasa de generación de undo.

Consulta:

SELECT begin_time,
       end_time,
       undoblks,
       txncount,
       maxquerylen,
       ssolderrcnt,
       nospaceerrcnt
FROM v$undostat
ORDER BY begin_time DESC;

9.17 Advisory Sections

El reporte puede incluir recomendaciones para:

Buffer cache.
Shared pool.
PGA.
Java pool.
Streams pool.
SGA Target.
DB cache.
MTTR.

Estas secciones son estimaciones, no instrucciones que deban ejecutarse automáticamente.

Una recomendación de aumentar memoria debe validarse contra:

Memoria física disponible.
Uso de swap.
Límite de PGA.
HugePages.
Otras instancias en el mismo servidor.
Beneficio estimado.
SQL ineficiente que originó la presión.

10. Método de análisis recomendado para un incidente

Un DBA L3 puede seguir esta secuencia:

Paso 1: Confirmar el periodo

Identifica la hora exacta del incidente y selecciona snapshots que lo cubran sin incluir demasiadas horas normales.

Paso 2: Validar el contexto

Comprueba:

Base e instancia.
CDB o PDB.
Versión.
Reinicios.
Duración.
Número de sesiones.
Cambios recientes.

Paso 3: Determinar dónde se consumió el DB Time

Revisa:

DB CPU.
Top Foreground Events.
Wait Classes.
Average Active Sessions.

Paso 4: Identificar el principal consumidor

Determina si el problema fue ocasionado por:

SQL.
CPU.
Almacenamiento.
Bloqueos.
Redo.
Parsing.
TEMP/PGA.
RAC/Cache Fusion.
Conexiones.
Objetos específicos.

Paso 5: Correlacionar

Relaciona el hallazgo con:

SQL ID.
Plan hash value.
Módulo y acción.
Servicio.
Usuario.
Segmento.
Instancia.
Evento de espera.
Métricas del sistema operativo.
Alert log.
Deployments o procesos batch.

Paso 6: Comparar con una línea base

Genera otro AWR para un periodo saludable con:

Mismo día de la semana.
Horario equivalente.
Carga de negocio similar.
Misma configuración, si es posible.

La comparación mediante awrddrpt.sql puede mostrar cambios en carga, eventos, SQL y consumo de recursos.

Paso 7: Aplicar una corrección controlada

La acción podría incluir:

Corregir el SQL.
Estabilizar un plan.
Modificar un índice.
Reducir commits.
Ajustar el pool de conexiones.
Redistribuir servicios RAC.
Corregir bloqueos desde la aplicación.
Ajustar memoria.
Revisar el almacenamiento.
Limitar paralelismo.
Corregir estadísticas.

Paso 8: Verificar después del cambio

Crea snapshots antes y después del cambio y compara:

Tiempo por ejecución.
DB Time.
Buffer gets.
Lecturas físicas.
CPU.
Eventos de espera.
Throughput.
Experiencia real de la aplicación.

11. Qué problemas puede ayudar a prevenir

Un análisis periódico de AWR puede detectar tendencias antes de que se conviertan en incidentes:

Crecimiento progresivo del DB Time.
Aumento de CPU por transacción.
SQL con planes inestables.
Incremento de hard parsing.
Saturación de procesos o sesiones.
Mayor uso de TEMP.
Redo generado de forma anormal.
Aumento de commits por segundo.
Degradación de la latencia de I/O.
Segmentos con contención.
Desequilibrio entre instancias RAC.
Crecimiento de la carga sin capacidad suficiente.
Procesos batch que comienzan a exceder su ventana.
Mayor consumo de PGA o SGA.
Cambios en patrones de conexión.

Para prevención, no basta con archivar reportes. Conviene registrar indicadores clave y comparar periodos equivalentes.

12. Errores comunes al analizar AWR

Generar un reporte demasiado amplio

Un reporte de 24 horas puede ocultar un problema que duró diez minutos.

Analizar únicamente ratios

Un hit ratio alto no garantiza buen rendimiento.

Asumir que el evento superior es la causa raíz

El evento puede ser un síntoma. Debe correlacionarse con SQL, objetos y comportamiento de la aplicación.

Optimizar por tiempo total sin revisar ejecuciones

Un SQL puede consumir mucho tiempo porque se ejecuta millones de veces, no porque una ejecución sea lenta.

Cambiar memoria sin revisar el SQL

Aumentar SGA o PGA puede ocultar temporalmente el problema sin corregirlo.

Ignorar la aplicación

Bloqueos, commits excesivos, falta de pooling y SQL repetitivo frecuentemente se originan fuera de la base.

Comparar periodos con cargas diferentes

Comparar cierre de mes contra un día normal puede producir conclusiones incorrectas.

Ignorar RAC o el contenedor

Un reporte de la instancia o PDB incorrecta puede no mostrar el problema real.

13. Consultas complementarias

SQL histórico por elapsed time

SELECT sql_id,
       plan_hash_value,
       executions_delta,
       elapsed_time_delta / 1000000 AS elapsed_seconds,
       cpu_time_delta / 1000000 AS cpu_seconds,
       buffer_gets_delta,
       disk_reads_delta,
       rows_processed_delta
FROM dba_hist_sqlstat
WHERE snap_id BETWEEN :begin_snap AND :end_snap
ORDER BY elapsed_time_delta DESC
FETCH FIRST 20 ROWS ONLY;

Consultar el texto de un SQL

SELECT sql_id,
       dbms_lob.substr(sql_text, 4000, 1) AS sql_text
FROM dba_hist_sqltext
WHERE sql_id = '&sql_id';

Planes históricos

SELECT sql_id,
       plan_hash_value,
       id,
       parent_id,
       operation,
       options,
       object_owner,
       object_name
FROM dba_hist_sql_plan
WHERE sql_id = '&sql_id'
ORDER BY plan_hash_value, id;

Consumo histórico de procesos y sesiones

SELECT s.end_interval_time,
       r.resource_name,
       r.current_utilization,
       r.max_utilization,
       r.initial_allocation,
       r.limit_value
FROM dba_hist_resource_limit r
JOIN dba_hist_snapshot s
  ON s.snap_id = r.snap_id
 AND s.dbid = r.dbid
 AND s.instance_number = r.instance_number
WHERE r.resource_name IN ('processes', 'sessions')
ORDER BY s.end_interval_time;

La vista DBA_HIST_RESOURCE_LIMIT conserva información histórica sobre límites y consumo de recursos. Consulta la documentación oficial.

Conclusión

Un reporte AWR no debe interpretarse como una lista automática de problemas. Es una fotografía histórica del trabajo realizado por Oracle entre dos snapshots.

Su mayor valor aparece cuando el DBA combina:

DB Time.
Eventos de espera.
SQL y planes.
Estadísticas de objetos.
CPU e I/O.
Memoria.
Redo y undo.
Información de RAC o multitenant.
Métricas del sistema operativo.
Comportamiento de la aplicación.
Comparación contra una línea base.

El objetivo no es encontrar un porcentaje “incorrecto”, sino responder cuatro preguntas:

¿En qué se consumió el tiempo?
¿Qué SQL, objeto, sesión o recurso originó el consumo?
¿Qué cambió respecto a un periodo saludable?
¿Qué corrección puede aplicarse y cómo se medirá su resultado?

Utilizado correctamente, AWR permite diagnosticar incidentes con mayor rapidez, justificar técnicamente los cambios y detectar tendencias antes de que afecten la operación diaria de una base de datos Oracle.