Documentación

Primeros pasos

• Visión general de WaitScopeQué lee WaitScope, qué entrega el informe y qué no hace: el perfil del tiempo de respuesta a partir del trace Oracle 10046 y de deadlock.
• Primer análisis con el trace de ejemploEnvíe el trace sintético por la consola, siga el procesamiento y compare el tiempo total, el perfil, el diagnóstico y el plan con el informe de ejemplo.

Generar el trace

• Activar el trace con DBMS_MONITORActive el trace 10046 con esperas y sin binds por sesión, por client_id o por servicio, módulo y acción, compruebe que quedó activado y desactívelo al final.
• Elegir el nivel del evento 10046Los niveles del evento 10046, cuál necesita WaitScope, cómo activarlo y desactivarlo con ALTER SESSION y los parámetros que evitan un trace sin tiempos o cortado.
• Encontrar el archivo de trace en el servidorMarque el nombre con tracefile_identifier, encuentre la ruta con V$DIAG_INFO o V$PROCESS y copie el .trc de la carpeta de trace del ADR para enviarlo.
• Enviar el trace de un deadlock (ORA-00060)Encuentre por el alert log el trace que Oracle graba por sí solo en el ORA-00060, envíe el archivo y vea en el informe el grafo de espera, las sesiones y la sentencia.
• Qué contiene un trace 10046Los datos que lleva un trace 10046, lo que WaitScope guarda en el informe y borra después del análisis, y qué comprobar en el archivo antes de enviarlo.

Enviar

• Enviar traces por el navegadorEnvíe traces desde la página Análisis de la consola: archivos o carpeta, envío en fragmentos con reanudación, la pregunta sobre el proceso y la cola de procesamiento.
• Enviar traces con la app de AndroidInstale la app desde la página App Android de la consola, elija archivos o carpetas, reciba traces de otras apps y envíe en segundo plano, si lo desea solo por Wi-Fi.
• Enviar traces por la APIEnvíe un trace por la API v1 con el token de la app: iniciar sesión, abrir el envío, enviar los fragmentos de hasta 8 MiB, concluir y seguir el análisis hasta el informe.
• Archivos comprimidos y carpetasFormatos aceptados en el envío, carpeta entera, archivos .trm, un análisis por archivo de zip o tar, comprimido dentro de comprimido y archivo que no es trace.
• Analizar varios traces juntosJunte en un solo análisis los archivos de la misma operación, como los del cambio de tracefile_identifier, y lea en la tarjeta de la colección los archivos y las sesiones.
• Límites y envío repetidoTamaño por envío, límite descomprimido, análisis en cola y guardados, plazo del informe y qué pasa cuando el mismo archivo se envía de nuevo.

Leer el informe

• Resumen: tiempo total, período y entornoEl tiempo total, el período, las llamadas, esperas y sentencias y el entorno del trace en la parte superior del informe, y cómo descargar el informe o eliminar el análisis.
• Diagnóstico: los hallazgos del informeLos hallazgos señalan patrones que suelen explicar el perfil, en orden de gravedad, con la parte del tiempo total y la página de cada código.
• Perfil del tiempo de respuestaLa tabla que divide el tiempo total en CPU por tipo de llamada, eventos de espera y tiempo no contabilizado, y la tarjeta que explica cada fila.
• Clases de espera y SQL recursivoEl perfil agrupado por la clase de espera de Oracle y el tiempo del SQL recursivo, que una sentencia dispara en funciones, triggers y en el diccionario.
• Sentencias por componente y por clasePara cada componente del perfil y cada clase de espera, las sentencias que más tiempo gastaron en él, según el perfil exclusivo de cada sentencia.
• Sentencias SQL por contribuciónLa lista de las sentencias del trace por contribución al tiempo total, con el tiempo inclusivo, la profundidad, las ejecuciones, las filas y las lecturas.
• Detalle de la sentenciaLa página de una sentencia: el peso en el tiempo total, el texto con los objetos destacados, el perfil exclusivo, las llamadas y el SQL recursivo hijo.
• Plan de ejecución y operaciones destacadasEl plan de las líneas STAT, con el tiempo y las lecturas propios de cada operación, las operaciones destacadas y las filas estimadas frente a las reales.
• Tipos de llamadaLas llamadas PARSE, EXEC, FETCH y CLOSE de la sesión sumadas por tipo, con CPU, duración, lecturas, filas y misses, como en el total de tkprof.
• Llamadas de nivel 0 más largasLas llamadas de la aplicación que más tardaron, con la CPU, el instante en que empezó cada una, la línea en el trace y la sentencia de cada una.
• Distribución de latenciaLa duración de cada evento de espera y de cada tipo de llamada en rangos de potencia de 10, para separar muchas ocurrencias rápidas de pocas lentas.
• Lecturas: rangos de disco y SSD y relecturaLas lecturas de bloque en rangos pensados para disco y para SSD, y cuántas veces la sesión volvió a leer un bloque que ya había leído en el mismo trace.
• Objetos con más espera y página del objetoLos objetos que más espera sumaron en el trace y la página de cada uno en la consola, con consultas listas para ejecutar en la base de datos del trace.
• Textos compartibles: SQL sin bindLas sentencias que solo difieren en los literales, juntas en una forma con :s y :n en lugar de los valores, con las variantes, los PARSE y el tiempo sumados.
• Deadlocks: grafo, sesiones y diagnósticoCómo leer el deadlock grabado en el trace: quién esperaba a quién, las sesiones, la fila disputada, el SQL, la pila PL/SQL y el diagnóstico por el lock.
• Errores ORA en el traceLos códigos ORA- de las líneas ERROR y PARSE ERROR del trace, qué significa cada uno, dónde apareció y el enlace a la documentación de Oracle.
• Colección: varios archivos analizados juntosLa tarjeta que describe la colección cuando se analizaron varios traces juntos: los archivos, los tramos de cada uno y el tiempo de cada sesión.

Encontrar la causa raíz

• El método del perfil del tiempo de respuestaCómo encontrar la causa raíz de una lentitud: elegir la operación, medir el tiempo de respuesta con el trace, atacar el mayor componente y medir de nuevo.
• Sesión esperando a la aplicaciónEl hallazgo TEMPO_NA_APLICACAO aparece cuando la espera SQL*Net message from client ocupa buena parte del tiempo total: el tiempo está fuera de la base de datos.
• Un componente domina el tiempo de respuestaEl hallazgo COMPONENTE_DOMINANTE aparece cuando un solo componente del perfil concentra la mayor parte del tiempo total. Vea por dónde seguir en cada caso.
• La CPU domina el tiempo de respuestaEl hallazgo CPU_DOMINANTE aparece cuando la CPU de las llamadas concentra la mayor parte del tiempo total. En general, viene de lectura lógica en exceso o de parse.
• Tiempo no contabilizado dentro de las llamadasEl hallazgo NAO_CONTABILIZADO_DENTRO aparece cuando mucho tiempo queda en las llamadas sin CPU ni espera: trace sin esperas, cola de CPU o swap.
• Huecos de tiempo entre llamadasEl hallazgo NAO_CONTABILIZADO_ENTRE aparece cuando mucho tiempo cae entre llamadas sin espera registrada. Casi siempre, la falla está en la medición.
• CPU medida por encima del tiempo transcurridoEl hallazgo CPU_ACIMA_DO_DECORRIDO aparece cuando el tiempo no contabilizado dentro de las llamadas queda negativo. Es un efecto de la medición de CPU, no de la base de datos.
• Lectura de bloque único lentaEl hallazgo LEITURA_LENTA aparece cuando la lectura de un bloque único demora en promedio más de lo que el almacenamiento debería. Vea si son todas las lecturas o pocas.
• Muchas lecturas de bloque únicoEl hallazgo MUITAS_LEITURAS aparece cuando las lecturas de bloque único ocupan buena parte del tiempo total. Antes de acelerar el disco, revise si el plan lee demasiados bloques.
• Muchos hard parsesEl hallazgo HARD_PARSE aparece cuando buena parte de los PARSE de la sesión son hard parse, o cuando el PARSE de SQL con literales pesa en el tiempo. La causa más común es SQL sin bind variables.
• Un PARSE en cada ejecuciónEl hallazgo PARSE_POR_EXECUCAO aparece cuando una sentencia muy ejecutada hace un PARSE en cada ejecución. Mantener el cursor abierto evita el PARSE repetido.
• SQL con literales en lugar de bind variablesEl hallazgo LITERAIS_SEM_BIND señala el mismo SQL repetido con valores diferentes en el texto, en muchas variantes cuyo PARSE pesa en la sesión. La corrección es usar bind variables.
• Muchos FETCH con pocas filasEl hallazgo FETCH_PEQUENO aparece cuando la aplicación hace muchos FETCH con pocas filas cada uno, en promedio. Un fetch size mayor reduce las idas y vueltas.
• Procesamiento fila a fila en PL/SQLEl hallazgo LINHA_A_LINHA señala SQL recursivo ejecutado o leído muchas veces, una fila a la vez: el bucle en PL/SQL que pide procesamiento en conjunto.
• Espera por bloqueo de otra sesiónEl hallazgo BLOQUEIO aparece cuando la clase Application pesa en el tiempo total: cómo encontrar la sesión que retiene el lock y corregir la causa.
• Contención por estructuras internas de la base de datosEl hallazgo CONCORRENCIA aparece cuando latches, mutexes y buffer busy pesan en el tiempo total: cómo relacionar cada evento con su causa y corregirlo.
• Mucho tiempo esperando la escritura del redo en el commitEl hallazgo COMMIT aparece cuando el log file sync pesa en el tiempo total: cómo distinguir demasiados commits de un redo lento y qué hacer en cada caso.
• Espera ligada a la configuración de la base de datosEl hallazgo CONFIGURACAO aparece cuando cambios de redo log, buffers, ITL o secuencias pesan en el tiempo total: el evento indica el límite que hay que ajustar.
• Intercambio de bloques entre instancias del RACEl hallazgo CLUSTER aparece cuando los eventos gc pesan bastante en el tiempo total: instancias del RAC que se disputan los mismos bloques, y cómo reducir los intercambios.
• Sesión limitada por el Resource ManagerEl hallazgo RESOURCE_MANAGER aparece cuando las esperas resmgr pesan en el tiempo total: cómo encontrar el plan, el grupo y la ventana que retuvieron la sesión.
• Operación del plan que concentra el trabajoEl hallazgo PLANO_PONTO_QUENTE indica la operación que concentra el tiempo o las lecturas del plan de una sentencia pesada, con la pista de qué corregir.
• Estimación de filas errónea en el planEl hallazgo ESTIMATIVA_ERRADA muestra la operación en la que el optimizador se equivocó en las filas por 10 veces o más, y cómo corregir estadísticas y bind peeking.
• Llamadas de nivel 0 lentasEl hallazgo CHAMADAS_LENTAS cuenta las llamadas de la aplicación que tardaron 0,1 s o más y lleva a la lista de las más largas, desde donde se llega a la sentencia.
• Errores de Oracle en el traceEl hallazgo ERROS_ORACLE cuenta los errores ORA- grabados en el trace, menos el ORA-01403: cómo ver dónde apareció cada código y qué corregir.
• ORA-01403 (fin de datos) en el traceEl hallazgo FIM_DE_DADOS aparece cuando el único error del trace es el ORA-01403, el fin normal de una lectura. Vea los casos en que merece atención.
• Rollbacks en el traceEl hallazgo ROLLBACK cuenta las transacciones que terminaron en rollback: cómo saber, por el propio trace, si hubo trabajo deshecho o solo una rutina del pool.
• Deadlock entre sesiones (ORA-00060)El hallazgo DEADLOCK clasifica cada ORA-00060 por el tipo de lock del grafo (TX, TM o UL) y señala la causa probable y la corrección de cada tipo.
• Trace sin intervalo de tiempoEl hallazgo TRACE_VAZIO aparece cuando el archivo tiene líneas del 10046, pero ninguna llamada o espera con tim: no hay tiempo de respuesta que analizar.

Estudios de caso

• Caso 1: tiempo entre llamadas y SQL fila a filaLectura guiada del informe de un trace 10046 real: el 73,6% del tiempo entre llamadas, dos SELECT con literales ejecutados 89.112 veces y el trace cortado en medio de la rutina.
• Caso 2: sesión dominada por espera de I/OLectura guiada del informe de un trace 10046 real: el 51,4% del tiempo en User I/O, una consulta con el 72% del tiempo y sin plan en el fragmento, y un DELETE de casi 3 millones de filas.

Límites y privacidad

• Lo que WaitScope no haceLo que queda fuera del alcance de WaitScope: conexión con la base de datos, monitoreo, los archivos que rechaza y lo que un trace 10046 no puede mostrar.
• Retención, eliminación y privacidad de los datosCuánto tiempo queda guardado el informe, cuándo se borra el trace, cómo eliminar y descargar, quién ve sus análisis y cómo pedir ayuda sin enviar el trace.
• Literales ocultos en el SQLCómo la máscara reemplaza por *** el texto entre comillas y los números del SQL que usted ve y descarga, qué no oculta y cómo activar o desactivar cada opción.

Referencia

• GlosarioLos términos del informe y del trace 10046, del tiempo de respuesta y el componente al hard parse, las lecturas cr y cu y el sql_id.
• Líneas del trace 10046 que lee WaitScopeCada línea del trace 10046 que lee WaitScope, con los campos que usa, los que ignora, la unidad de tiempo y dónde aparece todo en el informe.
• Referencia de la API v1Resumen de la API v1 que usa la app de Android: dirección, token, idioma, códigos de error, rutas de sesión, cuenta, análisis, informe y envío, y los límites.
• Novedades de la consola y de la appQué cambió en cada versión de la consola y de la app de Android de WaitScope, de la más nueva a la más antigua, del HTML descargado que se abre por partes de la consola 1.7.0 a la aceptación de los términos de la 1.5.0.