Un solo componente con la mayor parte del tiempo es el caso más simple del método: casi toda la ganancia posible está ahí. La causa depende de qué componente domina.
Síntomas
En el Diagnóstico aparece el hallazgo componente domina el tiempo de respuesta (COMPONENTE_DOMINANTE), con el nombre del componente al principio, por ejemplo db file scattered read domina el tiempo de respuesta. El texto dice cuánto del tiempo total viene de ese componente, en porcentaje y en segundos, y termina con Ver en el perfil.
El hallazgo aparece cuando el primer componente del perfil concentra la mayor parte del tiempo total. La gravedad es siempre media. No aparece cuando otro hallazgo ya trata el mismo tiempo:
SQL*Net message from clienttiene el hallazgo de la sesión esperando a la aplicación;- el tiempo no contabilizado dentro de las llamadas tiene un hallazgo propio;
- la CPU y las clases de espera con hallazgo propio (Application, Concurrency, Commit, Configuration, Cluster y Scheduler) aparecen con el hallazgo de la clase, como CPU dominante o bloqueo.
En la práctica, aparece para eventos de las clases User I/O, Network, System I/O, Other y Administrative, para esperas Idle que no son SQL*Net message from client, para eventos no clasificados y para el tiempo no contabilizado entre llamadas.
Causa
Haga clic en el nombre del componente en el perfil para abrir la tarjeta con lo que mide, cuándo es normal y dónde mirar. Los casos más frecuentes:
| Componente | Qué suele ser | Por dónde seguir |
|---|---|---|
db file sequential read, cell single block physical read | Lectura de un bloque a la vez: acceso por índice que lee demasiados bloques, o disco lento | Muchas lecturas de bloque único y lectura lenta |
db file scattered read, direct path read, cell smart table scan | Lectura completa (full scan) de una tabla o un índice grande para devolver pocas filas | Operaciones FULL en el plan de ejecución y operación que concentra el plan |
direct path read temp, direct path write temp | Una ordenación o un hash join que no cupo en la memoria de la sesión (PGA) y fue al TEMP | Columna PW en el plan de ejecución |
SQL*Net more data to client, SQL*Net message from dblink | Respuesta grande para la aplicación, o espera por la base de datos remota de un database link | Filas por FETCH y la sentencia en la base de datos remota |
PL/SQL lock timer | Pausa pedida por el código (DBMS_LOCK.SLEEP o DBMS_SESSION.SLEEP) | El bloque PL/SQL que hace la pausa, en Sentencias por componente |
PX Deq: Execute Reply | La sesión coordina una consulta paralela y espera a los procesos de ejecución paralela | El trabajo está en los traces de esos procesos |
| tiempo no contabilizado entre llamadas | Trace sin esperas, activado y desactivado en medio de la operación, o colección incompleta | Huecos de tiempo entre llamadas |
Solución
- Abra Ver en el perfil y revise la fila del componente: Ocurrencias, Media (s) y Máx (s) dicen si son muchas esperas cortas o pocas largas.
- Busque el componente en la tabla de la causa. Si otro hallazgo del Diagnóstico trata el mismo componente, como lectura lenta o muchas lecturas, empiece por él.
- En Sentencias principales por componente, abra el grupo del componente y busque la sentencia que más gastó en él.
- En el detalle de la sentencia, revise el Perfil de la sentencia y el plan: la operación destacada suele ser la que genera el componente.
- Si el componente es espera por un recurso (disco, red, base de datos remota), vea también Objetos con más tiempo de espera y la carga de ese recurso en el mismo período, fuera del informe.
Cómo confirmar
Después del cambio, genere un trace nuevo de la misma operación y compare: la Duración (s) del componente y el Tiempo total deben bajar juntos. El hallazgo desaparece cuando ningún componente concentra ya la mayor parte del tiempo total. Si el tiempo total bajó poco, el tiempo pasó a otro componente: ataque el nuevo mayor.
En el informe
En el informe de ejemplo, el mayor componente es SQL*Net message from client, que tiene hallazgo propio, y por eso este hallazgo no aparece. El informe del caso 1, de un trace real, tiene este hallazgo para el tiempo no contabilizado entre llamadas (Diagnóstico del caso 1). Los enlaces de abajo abren las secciones del ejemplo:
- Diagnóstico: el hallazgo y el enlace Ver en el perfil.
- Perfil del tiempo de respuesta: el componente es la primera fila, con el mayor % del total.
- Por clase de espera: la clase del componente y sus otros componentes, en Componentes principales.
- Sentencias principales por componente y por clase: las sentencias que gastaron el tiempo del componente.
- Distribución de latencia: los rangos de duración de las esperas de cada evento.
Lea también las páginas del perfil, de las clases de espera y de las sentencias por componente.