El perfil divide el tiempo total de la sesión en componentes: la CPU de cada tipo de llamada, cada evento de espera y el tiempo que el trace no explica. Es la sección que dice adónde fue el tiempo, y el análisis empieza por el componente mayor.
Qué muestra la sección
La sección Perfil del tiempo de respuesta (en el índice, Perfil) tiene una fila por componente, de la mayor duración a la menor, y una fila Total igual al Tiempo total del Resumen. La suma de las filas es exactamente el tiempo total, sin redondeo: los porcentajes cierran en 100%.
| Componente | Qué mide |
|---|---|
CPU: FETCH dbcalls y los demás tipos de llamada | La CPU (c=) de las llamadas de ese tipo, sin la CPU de las llamadas recursivas que dispararon, que queda en el tipo de llamada de estas. |
| Cada evento de espera | La suma del ela= de las líneas WAIT del evento, como db file sequential read o SQL*Net message from client. |
tiempo no contabilizado dentro de las llamadas | La parte de la duración de las llamadas (e=) que no es CPU, ni espera registrada dentro de ellas, ni llamada recursiva. |
tiempo no contabilizado entre llamadas | El tiempo total menos las llamadas de nivel 0 y las esperas entre ellas: intervalos en los que el trace no registró nada. |
Junto al nombre viene el tipo: la clase de espera de Oracle para los eventos (Idle, User I/O, Network y otras), cpu o no contabilizado. El mismo perfil agrupado por clase está justo debajo (clases de espera y SQL recursivo).
Cómo leerla
| Columna | Qué indica |
|---|---|
| Componente | El nombre del componente. Haga clic en él para abrir la tarjeta (la tarjeta de cada fila). |
| Duración (s) | El tiempo del componente, en segundos, con seis decimales. |
| % del total | La parte del tiempo total, con la barra al lado. |
| Ocurrencias | En las esperas, cuántas líneas WAIT tiene el evento. En la CPU y en el tiempo no contabilizado dentro de las llamadas, cuántas llamadas. En blanco en el tiempo entre llamadas. |
| Media (s) | La duración dividida por las ocurrencias. |
| Mín (s) y Máx (s) | La ocurrencia más corta y la más larga. En blanco en el tiempo no contabilizado. |
El tiempo no contabilizado dentro de las llamadas puede salir negativo: la medición de CPU es menos fina que la de tiempo, y en llamadas cortas la CPU anotada puede superar la duración. No indica un problema en la base de datos (CPU por encima del tiempo transcurrido).
En el informe de ejemplo, SQL*Net message from client suma 0,005000 s en una sola espera, el 71,3% del total de 0,007010 s. La segunda fila, db file sequential read, tiene 2 lecturas con una media de 0,000650 s.
La tarjeta de cada fila
Haga clic en el nombre de un componente para abrir su tarjeta. La tarjeta trae el nombre en lenguaje sencillo (db file sequential read es Lectura de un bloque), el nombre original, lo que mide el componente y tres partes:
- Normal cuando
- El comportamiento esperado, con números de referencia cuando existen. Para
db file sequential read: una media de 0,1 a 1 ms en SSD o flash y de 5 a 10 ms en disco. - Preocupa cuando
- El patrón que indica un problema y su causa más frecuente.
- Dónde mirar
- Qué revisar y en qué parte del informe, con un enlace a la sección o a la fila exacta: la fila del componente en el perfil, su tabla en Latencia, su grupo en Sentencias por componente, los Objetos. Los elementos que terminan en en la base de datos o fuera del informe son comprobaciones que el trace no trae, como
v$session.blocking_session.
La consola tiene una tarjeta propia para más de 50 eventos de espera, para la CPU de cada tipo de llamada y para los dos tiempos no contabilizados. Un evento fuera del catálogo abre la tarjeta de su clase; los eventos gc del RAC tienen una tarjeta común. Cuando el lugar indicado no existe en el informe, la tarjeta apunta a la sección entera o muestra el lugar sin enlace.
Cuándo preocupa
- Un solo componente suma la mayor parte del tiempo total: el análisis empieza por él (componente dominante, CPU dominante).
SQL*Net message from clientestá entre las primeras filas: la base de datos esperó a la aplicación, y ajustar el SQL no reduce ese tiempo (sesión esperando a la aplicación).- El tiempo no contabilizado dentro de las llamadas pesa en el total: cola de CPU, paginación o código sin instrumentación (dentro de las llamadas). Si es negativo, es efecto de la medición de CPU.
- El tiempo no contabilizado entre llamadas pesa en el total: el trace tiene huecos (huecos entre llamadas).
- Un evento de espera pesa y la Media (s) está por encima de lo que la tarjeta llama normal: el recurso está lento. Con una media normal y muchas ocurrencias, el problema es el volumen, y la causa suele estar en el plan.
Adónde ir después
- Perfil del informe de ejemplo, y la fila de db file sequential read: haga clic en el nombre del evento para abrir la tarjeta.
- Sentencias por componente, para ver qué sentencias gastaron el tiempo del componente mayor.
- Distribución de latencia, para separar muchas ocurrencias rápidas de pocas lentas.
- El método, para el orden del análisis.