WaitScope lee el archivo de trace que usted envía y arma el informe solo con lo que contiene. Esta página reúne lo que queda fuera: lo que el servicio no hace, los archivos que rechaza y lo que un trace no puede mostrar.
Lo que WaitScope no hace
- No se conecta a la base de datos. No hay agente, conector, usuario ni esquema en su entorno. WaitScope solo ve los archivos que usted elige enviar.
- No monitorea. No queda conectado a la base de datos ni recoge nada de forma continua: cada análisis es el trace de una operación que usted decidió rastrear. Para seguir la base de datos a lo largo del día, use una herramienta de monitoreo.
- No cambia nada en la base de datos. Las consultas listas de la página del objeto y los bloques de estadísticas solo se ejecutan si usted los copia y los ejecuta en su base de datos.
- No lee los valores de bind. El bloque
BINDSdel trace se ignora, y el informe no muestra con qué valores se ejecutó el SQL. - No guarda el trace. El archivo sale del servidor cuando termina el análisis. No hay descarga del trace ni reprocesamiento: para analizarlo de nuevo, envíe el archivo otra vez. Los plazos están en Retención, eliminación y privacidad de los datos.
- No decide por usted. El diagnóstico señala patrones que suelen explicar el perfil. Como dice el propio informe, son pistas para el análisis, no conclusiones: las decisiones sobre el SQL, la base de datos y la aplicación son suyas.
El informe solo ve lo que está en el trace
El trace 10046 registra la sesión rastreada: las llamadas a la base de datos, las esperas y, cuando Oracle las graba, las filas del plan. Todo lo que muestra el informe sale de ahí.
- Lo que hacían otras sesiones en el mismo momento no aparece. En una espera por bloqueo, el trace muestra cuánto esperó la sesión, pero no quién retenía el recurso. La excepción es el deadlock: el bloque
DEADLOCK DETECTEDtrae las sesiones involucradas. - El plan de ejecución viene de las líneas
STATdel propio trace. Una sentencia sin esas líneas queda sin plan: WaitScope no consulta la base de datos para obtenerlo. - El tiempo en que la sesión espera a la aplicación aparece como la espera
SQL*Net message from client, sin el detalle de lo que hacía la aplicación en ese intervalo.
Archivos rechazados
WaitScope analiza traces del evento 10046 y traces de deadlock (ORA-00060). Cuando el archivo no tiene ninguna línea del 10046 ni bloque de deadlock, el análisis termina con el estado error, y el mensaje dice qué tipo de archivo reconoció WaitScope.
| Archivo | El mensaje comienza con |
|---|---|
| Trace del optimizador (evento 10053) | el archivo es un trace del optimizador (evento 10053), que muestra cómo se eligió el plan |
| Trace de incidente (ORA-00600 u ORA-07445) | el archivo es un trace de incidente (ORA-00600 u ORA-07445), generado para el soporte de Oracle |
| Volcado de estado del sistema o de hanganalyze | el archivo es un dump de estado del sistema o de hanganalyze |
| Alert log de la instancia, en texto o en XML | el archivo es un alert log de la instancia |
| Otro trace de Oracle, sin las líneas del 10046 | el archivo es un trace de Oracle |
| Archivo que no es un trace de Oracle | el archivo no parece un trace de Oracle (evento 10046) |
En los cinco primeros casos, el mensaje continúa así: “sin las líneas del evento 10046 (PARSE, EXEC, FETCH, WAIT) que usa el perfil. Para analizar una sesión, genere el trace con DBMS_MONITOR.SESSION_TRACE_ENABLE(waits => TRUE) o, en la propia sesión, ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'”.
El rechazo solo ocurre cuando falta el 10046. Un trace 10046 que también trae, por ejemplo, un fragmento de ORA-00600 se analiza normalmente. WaitScope lee el trace que graba Oracle (.trc), no informes hechos a partir de él: la salida de TKPROF y los informes de AWR también se rechazan.
Los archivos .trm, que Oracle graba junto al .trc, no son traces: la consola y la app los dejan fuera del envío. En una colección, el archivo que no es trace queda fuera con el aviso “archivo no parece un trace de Oracle y quedó fuera de la colección”; si ninguno es trace, el análisis termina con “ningún archivo de la colección parece un trace de Oracle”.
El archivo rechazado también sale del servidor. Para intentarlo de nuevo, genere el trace con las esperas y envíelo otra vez: vea Activar el trace con DBMS_MONITOR.
Límites de lo que muestra el trace
Trace sin esperas
En los niveles 1 y 4 del evento 10046, o con waits => FALSE en DBMS_MONITOR, Oracle no graba las líneas WAIT. El informe sale, pero el perfil queda solo con CPU y tiempo no contabilizado: la lectura de disco dentro de las llamadas se convierte en tiempo no contabilizado dentro de las llamadas, y la espera por la aplicación se convierte en tiempo no contabilizado entre llamadas. En el Resumen, Esperas igual a 0 muestra este caso.
En este caso, los hallazgos sobre tiempo no contabilizado no significan cola de CPU ni hueco en el trace: falta la información. Genere el trace de nuevo con las esperas, en el nivel 8 o 12 (niveles del evento 10046).
Trace cortado
- Activado después del inicio de la operación. El cursor abierto antes del trace no tiene la línea
PARSING IN CURSOR, y el detalle de la sentencia muestra “Texto no disponible: el cursor se abrió antes del inicio del trace.” La llamada recursiva cuya llamada de nivel 0 comenzó antes del trace genera el aviso “N llamadas recursivas sin llamada de nivel 0 correspondiente (trace iniciado o cortado en medio de una llamada)”. - Desactivado antes del final. Lo que hizo la sesión después de la última línea no entra en el tiempo total. Lo mismo vale para el archivo que se detuvo en el límite de tamaño del trace (parámetro
MAX_DUMP_FILE_SIZE). La sentencia cuyas líneasSTATno llegaron a grabarse queda sin plan. - Operación en varios archivos. La aplicación que cambia el
tracefile_identifierreparte la sesión en varios traces. Analizado solo, cada archivo pierde los cursores abiertos en los otros: envíelos todos juntos, como una colección (analizar varios traces juntos). El archivo que falte aparece como tiempo no contabilizado entre llamadas.
Tiempo no contabilizado
El perfil siempre suma el tiempo total. Lo que el trace no explica por CPU ni por espera entra en dos filas: el tiempo no contabilizado dentro de las llamadas, la parte de la duración de cada llamada que no es CPU ni espera registrada, y el tiempo no contabilizado entre llamadas, el intervalo entre una llamada de nivel 0 y la siguiente sin espera registrada.
WaitScope mide cuánto es, pero el trace no dice qué fue. Las causas frecuentes están en tiempo no contabilizado dentro de las llamadas y tiempo no contabilizado entre llamadas. El valor negativo dentro de las llamadas viene de la granularidad de la medición de CPU (CPU por encima del tiempo transcurrido).
Avisos en la parte superior del informe
Cuando la lectura encuentra algo fuera de lo común, el informe muestra avisos destacados antes del resumen. Los más frecuentes:
- “N esperas sin tim (trace antiguo): la separación entre esperas dentro y fuera de las llamadas usa el nombre del evento”.
- “N líneas demasiado largas se cortaron”.
- Los límites del análisis, que solo alcanza un trace muy grande o con muchas sentencias distintas. El aviso dice qué límite se alcanzó y qué quedó sumado en un grupo o fuera del detalle. En las sentencias, los recuentos estimados aparecen como alrededor de N: vea trace con muchas sentencias.
El texto muy largo de una sentencia aparece cortado, con la nota “Texto truncado: el trace declara N caracteres.”
Adónde ir después
- Niveles del evento 10046: qué nivel graba las esperas que necesita el perfil.
- Líneas del trace 10046 que lee WaitScope: los campos de cada línea y dónde aparecen en el informe.
- Retención, eliminación y privacidad de los datos: qué queda guardado y durante cuánto tiempo.
- Método para encontrar la causa raíz: cómo leer el perfil, del mayor componente al menor.