Este artículo son las notas del Capítulo 23 "Realización del seguimiento de aplicaciones" de la Guía de ajuste de SQL .
Este capítulo explica qué es el rastreo de aplicaciones de un extremo a otro y cómo generar y leer archivos de rastreo.
conceptos básicos importantes
23.1 Descripción general del seguimiento de aplicaciones de extremo a extremo
El rastreo de aplicaciones de un extremo a otro puede identificar las fuentes de una carga de trabajo excesiva de la base de datos, como declaraciones SQL de alta carga, por identificador de cliente, servicio, módulo, operación, sesión, instancia o base de datos completa .
En un entorno de varios niveles, el nivel intermedio enruta las solicitudes de los clientes finales a diferentes sesiones de la base de datos, lo que dificulta el seguimiento de los clientes en las sesiones de la base de datos. El seguimiento de aplicaciones de un extremo a otro es una infraestructura que utiliza un ID de cliente para realizar un seguimiento exclusivo de un cliente final específico a través de todos los niveles hasta la base de datos y proporciona información sobre lo que el cliente final está haciendo en la base de datos.
23.1.1 Propósito del rastreo de aplicaciones de extremo a extremo
El seguimiento de aplicaciones de un extremo a otro simplifica el diagnóstico de problemas de rendimiento en entornos de varios niveles.
Por ejemplo, puede identificar las fuentes de una carga de trabajo excesiva de la base de datos, como declaraciones SQL de alta carga, y ponerse en contacto con el usuario responsable. Además, los usuarios que tengan problemas pueden contactarlo. Luego puede determinar qué está haciendo esta sesión de usuario en el nivel de PDB
El seguimiento de aplicaciones de un extremo a otro también simplifica la gestión de las cargas de trabajo de las aplicaciones mediante el seguimiento de módulos y operaciones específicos dentro de los servicios. Los nombres de los módulos y las acciones los establece el desarrollador de la aplicación . Por ejemplo, puede establecer estos valores en un programa PL/SQL usando los procedimientos SET_MODULE y SET_ACTION en el paquete DBMS_APPLICATION_INFO .
El seguimiento de aplicaciones de extremo a extremo puede identificar problemas de carga de trabajo en la base de datos:
-
Identificador de cliente
Especifica el usuario final por ID de inicio de sesión, por ejemplo, HR.HR -
Servicio
Especifica un grupo de aplicaciones con atributos comunes, umbrales de nivel de servicio y prioridades, o una sola aplicación, como ACCTG para una aplicación de contabilidad. -
Módulo
Especifica el módulo funcional de la aplicación, como Cuentas por cobrar o Libro mayor -
acción
especifica la operación en el módulo, como una operación INSERTAR o ACTUALIZAR -
sesión
Especifica una sesión en la instancia local basada en el identificador de sesión (SID) de la base de datos dado. -
Instancia
Especifica la instancia de base de datos dada por nombre de instancia -
contenedor
designado
23.1.2 Seguimiento de aplicaciones de extremo a extremo para PDB
La vista V$ permite leer archivos de seguimiento específicos del contenedor.
Los principales casos de uso son los siguientes:
-
Un administrador de CDB debe ver los archivos de seguimiento de un PDB específico.
La vista V$DIAG_TRACE_FILE enumera todos los archivos de seguimiento en el directorio de seguimiento de ADR que contienen datos de seguimiento de un PDB específico. V$DIAG_TRACE_FILE_CONTENTS Muestra el contenido de los archivos de rastreo. -
Los administradores de PDB deben ver los archivos de seguimiento de un PDB específico.
Puede usar SQL Trace para recopilar datos de diagnóstico para sentencias SQL ejecutadas en una aplicación PDB. Los datos de seguimiento incluyen el seguimiento de SQL (evento 10046) y el seguimiento del optimizador (evento 10053). Con la vista V$, los desarrolladores pueden acceder solo a los registros de seguimiento de SQL o del optimizador sin acceder a todo el archivo de seguimiento .
Para permitir que los usuarios y las herramientas determinen qué PDB está asociado con un archivo o parte de un archivo, existen comentarios de PDB en archivos de seguimiento, volcados de eventos y archivos de registro. La información de PDB es parte de los metadatos estructurados almacenados en el archivo .trm de cada archivo de rastreo. Cada registro contiene los siguientes atributos:
- CON_ID, que es el ID del contenedor asociado a los datos
- CON_UID, que es el ID único del contenedor
- NOMBRE, que es el nombre del contenedor
23.1.3 Herramientas para el seguimiento de aplicaciones de extremo a extremo
SQL Trace y TKPROF son dos herramientas básicas de diagnóstico de rendimiento que pueden ayudarlo a evaluar con precisión la eficiencia de las declaraciones SQL que ejecuta su aplicación.
Para obtener los mejores resultados, utilice estas herramientas con EXPLAIN PLAN en lugar de EXPLAIN PLAN solo. Después de escribir la información de rastreo en un archivo, puede usar la utilidad TRCSESS para consolidar estos datos y luego usar TKPROF o SQL Trace para diagnosticarlos .
La interfaz recomendada para el seguimiento de aplicaciones de un extremo a otro es Oracle Enterprise Manager Cloud Control (Cloud Control). Con Cloud Control, puede ver los principales consumidores de cada tipo de consumidor y habilitar o deshabilitar la recopilación de estadísticas y el seguimiento de SQL para consumidores específicos. Si Cloud Control no está disponible, puede administrar esta funcionalidad mediante la API DBMS_MONITOR .
23.1.3.1 Descripción general de la función de seguimiento de SQL
La herramienta SQL Trace proporciona información de rendimiento sobre sentencias SQL individuales.
SQL Trace genera las siguientes estadísticas para cada declaración:
- Analizar, ejecutar y contar
- CPU y tiempo de ejecución
- lectura física y lectura lógica
- número de filas procesadas
- error de caché de biblioteca
- Nombre de usuario para cada ocurrencia de resolución
- Cada confirmación y reversión
- Esperar datos de eventos para cada instrucción SQL y un resumen para cada archivo de seguimiento
Si el cursor de la instrucción SQL está cerrado, SQL Trace también proporciona información sobre el origen de la fila, que incluye:
- Muestra las operaciones de fila del plan de ejecución real para cada instrucción SQL
- Número de filas, lecturas coherentes, lecturas físicas, escrituras físicas y tiempo dedicado a cada operación en la fila
Aunque puede habilitar la función SQL Trace para una sesión o instancia, Oracle recomienda que utilice los paquetes DBMS_SESSION o DBMS_MONITOR en su lugar . Cuando la función Seguimiento de SQL está habilitada para una sesión o instancia, las estadísticas de rendimiento de todas las sentencias SQL ejecutadas en la sesión o instancia del usuario se colocan en un archivo de seguimiento. El uso de la herramienta SQL Trace puede afectar el rendimiento y puede generar una mayor sobrecarga del sistema, un uso elevado de la CPU y poco espacio en disco .
La utilidad de línea de comandos TRCSESS consolida la información de seguimiento de varios archivos de seguimiento en función de criterios específicos, como la sesión o el ID del cliente.
23.1.3.2 Resumen de TKPROF
Para formatear el contenido de un archivo de rastreo y colocar la salida en un archivo de salida legible, ejecute el programa TKPROF.
TKPROF también puede hacer lo siguiente:
- Cree scripts SQL que almacenen estadísticas en la base de datos
- Determinar el plan de ejecución de la sentencia SQL
TKPROF informa los recursos consumidos por cada declaración ejecutada, la cantidad de veces que se llamó y la cantidad de filas que procesó. Esta información le permite encontrar aquellas declaraciones que utilizan la mayoría de los recursos. Con una línea de base disponible, puede evaluar si los recursos utilizados son razonables para la situación laboral dada.
23.2 Habilitación de la recopilación de estadísticas para el seguimiento de extremo a extremo
Para recopilar estadísticas adecuadas mediante PL/SQL, debe habilitar la recopilación de estadísticas para un identificador de cliente, servicio, módulo u operación mediante procedimientos en DBMS_MONITOR.
El nivel predeterminado es la recopilación de estadísticas a nivel de sesión . La recopilación de estadísticas es global para la base de datos y continúa a lo largo de los reinicios de la instancia de la base de datos.
23.2.1 Habilitación de la recopilación de estadísticas para un ID de cliente
El procedimiento CLIENT_ID_STAT_ENABLE habilita la recopilación de estadísticas para un ID de cliente determinado y el procedimiento CLIENT_ID_STAT_DISABLE la deshabilita.
Puede ver el identificador del cliente en la columna CLIENT_IDENTIFIER de V$SESSION.
Suponga que desea habilitar y luego deshabilitar la recopilación de estadísticas para el cliente con ID oe.oe.
-- 为 oe.oe 启用统计信息收集。
EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_ENABLE(client_id => 'OE.OE');
-- 为 oe.oe 禁用统计信息收集。
EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_DISABLE(client_id => 'OE.OE');
23.2.2 Habilitación de la recopilación de estadísticas para servicios, módulos y acciones
El procedimiento SERV_MOD_ACT_STAT_ENABLE habilita la recopilación de estadísticas para una combinación de servicio, módulo y operación, y el procedimiento SERV_MOD_ACT_STAT_DISABLE deshabilita la recopilación de estadísticas para una combinación de servicio, módulo y operación.
Cuando cambia un módulo u operación utilizando el procedimiento DBMS_MONITOR anterior, el cambio entra en vigor en la siguiente llamada de usuario en la sesión. Por ejemplo, si un módulo se establece en module1 en una sesión y si un módulo se restablece en module2 en una llamada de usuario en una sesión, el módulo seguirá siendo module1 mientras dure esa llamada de usuario. En la próxima llamada de usuario en la sesión, el módulo cambia a module2.
-- 启用
BEGIN
DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(
service_name => 'ACCTG'
, module_name => 'PAYROLL' );
END;
BEGIN
DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(
service_name => 'ACCTG'
, module_name => 'GLEDGER'
, action_name => 'INSERT ITEM' );
END;
-- 禁用
BEGIN
DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE(
service_name => 'ACCTG'
, module_name => 'GLEDGER'
, action_name => 'INSERT ITEM' );
END;
23.3 Habilitación del rastreo de aplicaciones de extremo a extremo
Para habilitar el rastreo de identificadores de clientes, servicios, módulos, operaciones, sesiones, instancias o bases de datos, ejecute el procedimiento apropiado en el paquete DBMS_MONITOR.
Según los criterios que proporcione, la información de seguimiento específica se captura en un conjunto de archivos de seguimiento y se fusiona en un único archivo de seguimiento de salida. Puede habilitar el seguimiento para diagnósticos específicos y administración de carga de trabajo con las siguientes condiciones.
23.3.1 Habilitación del seguimiento para un identificador de cliente
-- 要启用和禁用对客户端标识符的跟踪
BEGIN
DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE(
client_id => 'OE.OE' ,
waits => true ,
binds => false );
END;
-- 禁用
EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(client_id => 'OE.OE');
23.3.2 Habilitación del seguimiento para un servicio, módulo y acción
El procedimiento DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE habilita el rastreo de SQL para la combinación especificada de nombre de servicio, módulo y operación globalmente para la base de datos a menos que el procedimiento especifique un nombre de instancia de base de datos.
El procedimiento SERV_MOD_ACT_TRACE_DISABLE deshabilita globalmente el rastreo para una combinación determinada de nombre de servicio, módulo y nombre de acción para todas las instancias habilitadas.
-- 启用
BEGIN
DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(
service_name => 'ACCTG' ,
module_name => 'PAYROLL' ,
waits => true ,
binds => false ,
instance_name => 'inst1' );
END;
-- 禁用
BEGIN
DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(
service_name => 'ACCTG' ,
module_name => 'PAYROLL' ,
instance_name => 'inst1' );
END;
23.3.3 Habilitación del seguimiento para una sesión
El procedimiento SESSION_TRACE_ENABLE habilita el seguimiento de un identificador de sesión (SID) de base de datos determinado en la instancia local.
Aunque el paquete DBMS_MONITOR solo puede ser invocado por usuarios con el rol de DBA, los usuarios también pueden habilitar el seguimiento de SQL para sus propias sesiones llamando al procedimiento DBMS_SESSION.SESSION_TRACE_ENABLE.
-- 为当前会话启用跟踪
BEGIN
DBMS_SESSION.SESSION_TRACE_ENABLE(
waits => true
, binds => false);
END;
-- 为指定会话启用跟踪
SELECT SID, SERIAL#, USERNAME
FROM V$SESSION
WHERE USERNAME = 'OE';
SID SERIAL# USERNAME
---------- ---------- ------------------------------
27 60 OE
BEGIN
DBMS_MONITOR.SESSION_TRACE_ENABLE(
session_id => 27
, serial_num => 60
, waits => true
, binds => false);
END;
-- 为指定会话禁用跟踪
BEGIN
DBMS_MONITOR.SESSION_TRACE_DISABLE(
session_id => 27
, serial_num => 60);
END;
23.3.4 Habilitación del seguimiento para una instancia o base de datos
El procedimiento DBMS_MONITOR.DATABASE_TRACE_ENABLE anula todos los demás seguimientos a nivel de sesión, pero se suma al seguimiento de identificadores de clientes, servicios, módulos y operaciones . Habilite el seguimiento para todas las sesiones actuales y futuras.
Todas las sesiones nuevas heredan la información de espera y vinculación especificada por este procedimiento hasta que llame al procedimiento DATABASE_TRACE_DISABLE. Cuando llama a este procedimiento con el parámetro nombre_instancia, el procedimiento restablece el seguimiento de SQL a nivel de sesión para la instancia nombrada. Si llama a este procedimiento sin un parámetro nombre_instancia, el procedimiento restablece el seguimiento de SQL a nivel de sesión para toda la base de datos.
Requisito previo: debe tener privilegios administrativos para ejecutar el procedimiento DATABASE_TRACE_ENABLE.
-- 启用
BEGIN
DBMS_MONITOR.DATABASE_TRACE_ENABLE(
waits => true
, binds => false
, instance_name => 'inst1' );
END;
-- 禁用
EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE(instance_name => 'inst1');
-- 整库禁用
EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE();
23.4 Generación de archivos de salida usando SQL Trace y TKPROF
Esta sección describe los procedimientos básicos para usar SQL Trace y TKPROF.
El proceso de generación del archivo de salida es el siguiente:
- Establecer parámetros de inicialización para la gestión de archivos de seguimiento.
- Habilite SQL Trace Facility para la sesión deseada, luego ejecute la aplicación. Este paso genera un archivo de seguimiento que contiene estadísticas de las sentencias SQL emitidas por la aplicación.
- Ejecute TKPROF para convertir el archivo de seguimiento creado en el paso 2 en un archivo de salida legible. Este paso puede crear opcionalmente un script SQL que puede usar para almacenar las estadísticas en la base de datos.
- Como alternativa, ejecute el script SQL generado en el paso 3 para almacenar las estadísticas en la base de datos.
23.4.1 Paso 1: Configuración de parámetros de inicialización para la gestión de archivos de rastreo
Para habilitar los archivos de rastreo, debe asegurarse de que se establezcan ciertos parámetros de inicialización.
Cuando la función Rastreo de SQL está habilitada para una sesión, Oracle Database genera un archivo que contiene estadísticas para las sentencias SQL de rastreo de la sesión. Cuando la función SQL Trace está habilitada para una instancia, Oracle Database crea un archivo de seguimiento separado para cada proceso .
Establezca los parámetros de inicialización para la gestión de archivos de rastreo:
- Verifique la configuración de los parámetros de inicialización TIMED_STATISTICS, MAX_DUMP_FILE_SIZE y DIAGNOSTIC_DEST, como se muestra en la "Tabla 23-1".
| parámetro | describir |
|---|---|
| DIAGNOSTIC_DEST | Especifica la ubicación de la página de inicio del Repositorio de diagnósticos automatizados (ADR). Los archivos de diagnóstico para cada instancia de la base de datos se encuentran en este directorio dedicado. |
| MAX_DUMP_FILE_SIZE | Cuando la función Seguimiento de SQL está habilitada en el nivel de instancia de la base de datos, cada llamada a la base de datos escribe una línea de texto en un archivo en el formato de archivo del sistema operativo. El tamaño máximo de estos archivos en el bloque del sistema operativo está limitado por este parámetro de inicialización. El valor predeterminado es ilimitado. |
| TIMED_STATISTICS | Habilite y deshabilite la recopilación de estadísticas programadas, como CPU y tiempo transcurrido, a través de la función SQL Trace, así como la recopilación de varias estadísticas en la vista V$. El valor predeterminado de TIMED_STATISTICS es verdadero si STATISTICS_LEVEL se establece en TYPICAL o ALL. Si STATISTICS_LEVEL se establece en BASIC, el valor predeterminado de TIMED_STATISTICS es falso. Habilitar la temporización provoca llamadas de temporización adicionales a operaciones de bajo nivel. Este es un parámetro dinámico. También es un parámetro de sesión. |
- Idear una forma de identificar los archivos de rastreo generados.
Asegúrese de saber distinguir los archivos de rastreo por su nombre. Puede marcar un archivo de rastreo incluyendo una declaración como SELECT program_name FROM DUAL en su programa. A continuación, puede rastrear cada archivo hasta el proceso que lo creó.
También puede configurar el parámetro de inicialización TRACEFILE_IDENTIFIER para especificar un identificador personalizado para que forme parte del nombre del archivo de rastreo.
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';
-
Si el sistema operativo mantiene varias versiones de archivos, asegúrese de que el límite de versiones sea lo suficientemente alto para acomodar la cantidad de archivos de seguimiento que desea que SQL Trace genere.
-
Si los archivos de seguimiento generados pueden pertenecer a un usuario del sistema operativo que no sea el suyo, asegúrese de tener los permisos necesarios para formatearlos con TKPROF.
23.4.2 Paso 2: Habilitación de la función de seguimiento de SQL
Puede habilitar SQL Trace a nivel de instancia o sesión.
El paquete a utilizar depende del nivel:
-
Una instancia de base de datos
habilita el seguimiento mediante el procedimiento DBMS_MONITOR.DATABASE_TRACE_ENABLE y deshabilita el seguimiento mediante el procedimiento DBMS_MONITOR.DATABASE_TRACE_DISABLE. -
Sesiones de base de datos El rastreo
está habilitado (verdadero) o deshabilitado (falso) mediante el procedimiento DBMS_SESSION.SET_SQL_TRACE.
Nota: Debido a la sobrecarga de ejecutar la herramienta SQL Trace, habilítela solo cuando ajuste las declaraciones SQL y deshabilítela cuando haya terminado.
-- 数据库层面
EXEC DBMS_MONITOR.DATABASE_TRACE_ENABLE(INSTANCE_NAME => 'orcl');
EXEC DBMS_MONITOR.DATABASE_TRACE_DISABLE(INSTANCE_NAME => 'orcl');
-- 会话级层面
EXEC DBMS_SESSION.SET_SQL_TRACE(sql_trace => true);
EXEC DBMS_SESSION.SET_SQL_TRACE(sql_trace => false);
23.4.3 Paso 3: Generación de archivos de salida con TKPROF
TKPROF acepta como entrada un archivo de rastreo generado por la herramienta de rastreo SQL y produce un archivo de salida formateado. TKPROF también puede generar planes de ejecución.
Después de que la herramienta Seguimiento de SQL genere un archivo de seguimiento, puede:
- Ejecute TKPROF en cada archivo de rastreo individual, produciendo múltiples archivos de salida formateados, uno para cada sesión.
- Adjunte el archivo de rastreo, luego ejecute TKPROF en los resultados para generar un archivo de salida formateado para toda la instancia.
- Ejecute la utilidad de línea de comandos TRCSESS para combinar la información de seguimiento de varios archivos de seguimiento, luego ejecute TKPROF en los resultados.
TKPROF no informa de las declaraciones COMMIT y ROLLBACK registradas en los archivos de seguimiento.
Nota: Las siguientes declaraciones de SQL se truncan a 25 caracteres en el archivo de seguimiento de SQL:
SET ROLE
GRANT
ALTER USER
ALTER ROLE
CREATE USER
CREATE ROLE
Ejemplo 23-1 Salida TKPROF
SELECT * FROM emp, dept
WHERE emp.deptno = dept.deptno;
call count cpu elapsed disk query current rows
---- ------- ------- --------- -------- -------- ------- ------
Parse 1 0.16 0.29 3 13 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.03 0.26 2 2 4 14
Misses in library cache during parse: 1
Parsing user id: (8) SCOTT
Rows Execution Plan
------- --------------------------------------------------- 14 MERGE JOIN
4 SORT JOIN
4 TABLE ACCESS (FULL) OF 'DEPT'
14 SORT JOIN
14 TABLE ACCESS (FULL) OF 'EMP'
Para esta declaración, la salida de TKPROF incluye la siguiente información:
- El texto de la instrucción SQL
- Estadísticas de SQL Trace en formato tabular
- El número de errores de caché de la biblioteca para el análisis y la ejecución de sentencias.
- El usuario analiza inicialmente la declaración.
- El plan de ejecución generado por EXPLAIN PLAN.
TKPROF también proporciona un resumen de declaraciones a nivel de usuario y llamadas SQL recursivas al archivo de seguimiento.
23.4.4 Paso 4: Almacenamiento de estadísticas de recurso de seguimiento de SQL
Es posible que desee mantener un historial de las estadísticas generadas por la herramienta SQL Trace para su aplicación y compararlas a lo largo del tiempo.
TKPROF puede generar un script SQL que crea una tabla e inserta filas de estadísticas en ella. El guión contiene lo siguiente:
- Una instrucción CREATE TABLE que crea una tabla de salida denominada TKPROF_TABLE.
- Instrucciones INSERT que agregan filas de estadísticas a TKPROF_TABLE, una para cada instrucción SQL rastreada.
Después de ejecutar TKPROF, ejecute este script para almacenar estadísticas en la base de datos.
23.4.4.1 Generación del script SQL de salida TKPROF
Cuando ejecute TKPROF, use el parámetro INSERT para especificar el nombre del script SQL generado.
Si se omite el parámetro INSERT, TKPROF no genera scripts.
23.4.4.2 Edición del script SQL de salida TKPROF
Después de que TKPROF haya creado el script SQL, es posible que desee editar el script antes de ejecutarlo.
Si ya creó una tabla de salida para las estadísticas recopiladas anteriormente y desea agregar nuevas estadísticas a esa tabla, elimine la instrucción CREATE TABLE del script. Luego, el script inserta la nueva fila en la tabla existente. Si creó varias tablas de salida, tal vez para almacenar estadísticas de diferentes bases de datos en tablas diferentes, edite las declaraciones CREATE TABLE e INSERT para cambiar los nombres de las tablas de salida.
23.4.4.3 Consultar la tabla de salida
Después de crear la tabla de salida, use la declaración SELECT para consultar.
La siguiente instrucción CREATE TABLE crea TKPROF_TABLE:
CREATE TABLE TKPROF_TABLE (
DATE_OF_INSERT DATE,
CURSOR_NUM NUMBER,
DEPTH NUMBER,
USER_ID NUMBER,
PARSE_CNT NUMBER,
PARSE_CPU NUMBER,
PARSE_ELAP NUMBER,
PARSE_DISK NUMBER,
PARSE_QUERY NUMBER,
PARSE_CURRENT NUMBER,
PARSE_MISS NUMBER,
EXE_COUNT NUMBER,
EXE_CPU NUMBER,
EXE_ELAP NUMBER,
EXE_DISK NUMBER,
EXE_QUERY NUMBER,
EXE_CURRENT NUMBER,
EXE_MISS NUMBER,
EXE_ROWS NUMBER,
FETCH_COUNT NUMBER,
FETCH_CPU NUMBER,
FETCH_ELAP NUMBER,
FETCH_DISK NUMBER,
FETCH_QUERY NUMBER,
FETCH_CURRENT NUMBER,
FETCH_ROWS NUMBER,
CLOCK_TICKS NUMBER,
SQL_STATEMENT LONG);
La mayoría de las columnas de la tabla de salida corresponden directamente a las estadísticas que aparecen en el archivo de salida formateado. Por ejemplo, el valor de la columna PARSE_CNT corresponde a las estadísticas de recuento de los pasos de análisis en el archivo de salida.
Las columnas de la siguiente tabla lo ayudan a identificar una fila de estadísticas.
Tabla 23-2 Columnas TKPROF_TABLE utilizadas para identificar filas de estadísticas
| Lista | describir |
|---|---|
| SQL_STATEMENT | Esta es la declaración de SQL para la cual la herramienta Seguimiento de SQL recopila filas de estadísticas. Debido a que el tipo de datos de esta columna es LONG, no se puede usar en expresiones o condiciones de la cláusula WHERE. |
| FECHA_DE_INSERTAR | Esta es la fecha y la hora en que se insertó la fila en la tabla. Este valor difiere de cuando la herramienta Seguimiento de SQL recopila estadísticas. |
| PROFUNDIDAD | Esto indica el nivel de recursividad en el que se emiten las sentencias SQL. Por ejemplo, un valor de 0 indica que el usuario emitió la declaración. Un valor de 1 indica que Oracle Database genera la declaración como una llamada recursiva para procesar una declaración con un valor de 0 (una declaración emitida por el usuario). Un valor de n indica que Oracle Database genera sentencias como llamadas recursivas para procesar sentencias con valor n-1. |
| ID_USUARIO | Esto identifica al usuario que emitió la declaración. Este valor también aparece en el archivo de salida formateado. |
| CURSOR_NUM | Oracle Database utiliza este valor de columna para realizar un seguimiento de a qué cursor se asigna cada instrucción SQL. |
La tabla de salida no almacena el plan de ejecución de la declaración. La siguiente consulta devuelve estadísticas en la tabla de salida.
SELECT * FROM TKPROF_TABLE;
DATE_OF_INSERT CURSOR_NUM DEPTH USER_ID PARSE_CNT PARSE_CPU PARSE_ELAP
-------------- ---------- ----- ------- --------- --------- ----------
21-DEC-2017 1 0 8 1 16 22
PARSE_DISK PARSE_QUERY PARSE_CURRENT PARSE_MISS EXE_COUNT EXE_CPU
---------- ----------- ------------- ---------- --------- -------
3 11 0 1 1 0
EXE_ELAP EXE_DISK EXE_QUERY EXE_CURRENT EXE_MISS EXE_ROWS FETCH_COUNT
-------- -------- --------- ----------- -------- -------- -----------
0 0 0 0 0 0 1
FETCH_CPU FETCH_ELAP FETCH_DISK FETCH_QUERY FETCH_CURRENT FETCH_ROWS
--------- ---------- ---------- ----------- ------------- ----------
2 20 2 2 4 10
SQL_STATEMENT
---------------------------------------------------------------------
SELECT * FROM EMP, DEPT WHERE EMP.DEPTNO = DEPT.DEPTNO
23.5 Directrices para interpretar la salida de TKPROF
Si bien TKPROF proporciona un análisis útil, la medida de eficiencia más precisa es el rendimiento de la aplicación . Al final de la salida de TKPROF hay un resumen del trabajo que realizó el proceso durante la ejecución del rastreo.
23.5.1 Pauta para Interpretar la Resolución de Estadísticas
Las estadísticas de tiempo tienen una resolución de centésimas de segundo . Por lo tanto, es posible que no se cronometre con precisión cualquier operación del cursor que tarde una centésima de segundo o menos.
Al interpretar las estadísticas, tenga en cuenta las limitaciones de tiempo. Tenga especial cuidado al interpretar los resultados de consultas simples que se ejecutan muy rápidamente.
23.5.2 Directrices para sentencias SQL recursivas
SQL recursivo es el SQL adicional que la base de datos Oracle debe emitir para ejecutar la sentencia SQL emitida por el usuario .
Conceptualmente, SQL recursivo es "SQL de efectos secundarios". Por ejemplo, si una sesión inserta una fila en una tabla que no tiene suficiente espacio para la fila, la base de datos realiza llamadas SQL recursivas para asignar espacio de forma dinámica. La base de datos también genera llamadas recursivas cuando la información del diccionario de datos no está disponible en la memoria y, por lo tanto, debe recuperarse del disco.
Si se producen llamadas recursivas cuando la función de seguimiento de SQL está habilitada, TKPROF genera estadísticas para sentencias SQL recursivas y las marca claramente como sentencias SQL recursivas en el archivo de salida. Puede suprimir las llamadas recursivas internas de la base de datos de Oracle (por ejemplo, la gestión del espacio) para que no aparezcan en el archivo de salida configurando el parámetro de línea de comandos SYS en NO. Las estadísticas de las sentencias SQL recursivas se incluyen en la lista de esa sentencia, no en la lista de la sentencia SQL que provocó la llamada recursiva. Por lo tanto, cuando calcule los recursos totales necesarios para procesar una sentencia SQL, tenga en cuenta las estadísticas de esa sentencia y las estadísticas de las llamadas recursivas que realiza la sentencia.
Nota: las operaciones de nivel SQL no incluyen estadísticas SQL recursivas.
23.5.3 Pauta para decidir qué sentencias ajustar
Debe determinar qué sentencias SQL usan la mayoría de los recursos de CPU o disco .
Si el parámetro TIMED_STATISTICS está habilitado, puede encontrar una alta actividad de la CPU en la columna de la CPU. Si TIMED_STATISTICS no está habilitado, verifique las columnas QUERY y CURRENT.
Además de los problemas de bloqueo y los bucles PL/SQL ineficientes, no se necesita tiempo de CPU ni tiempo de ejecución para encontrar la declaración del problema. La clave es el número de accesos al bloque , tanto de consulta (es decir, sujeto a restricciones de coherencia de lectura) como actual (es decir, no sujeto a restricciones de coherencia de lectura). Los encabezados de sección y los bloques que se actualizarán se recuperan de la manera actual, pero todo el procesamiento de consultas y subconsultas solicita datos en forma de consulta. Estas son exactamente las mismas que las estadísticas de instancia CONSISTENT GETS y DB BLOCK GETS . Puede encontrar alta actividad de disco en la columna de disco.
La siguiente lista muestra la salida de TKPROF para una instrucción SQL tal como aparece en el archivo de salida:
SELECT *
FROM emp, dept
WHERE emp.deptno = dept.deptno;
call count cpu elapsed disk query current rows
---- ------- ------- --------- -------- -------- ------- ------
Parse 11 0.08 0.18 0 0 0 0
Execute 11 0.23 0.66 0 3 6 0
Fetch 35 6.70 6.83 100 12326 2 824
------------------------------------------------------------------
total 57 7.01 7.67 100 12329 8 826
Misses in library cache during parse: 0
Si 7,01 segundos de CPU y 824 filas recuperadas son aceptables, entonces no es necesario que busque más en este resultado de seguimiento. De hecho, uno de los principales usos de los informes TKPROF en los ejercicios de ajuste es eliminar procesos de la fase de ajuste detallado.
El resultado muestra que se realizaron 10 llamadas de análisis innecesarias (ya que hubo 11 llamadas de análisis para esta sola declaración) y se realizó una búsqueda de matriz. Se obtuvieron más filas de las que se ejecutaron. Las grandes brechas entre la CPU y los tiempos transcurridos indican E/S física .
23.5.4 Directrices para evitar trampas en la interpretación de TKPROF
Al interpretar la salida de TKPROF, es útil estar al tanto de las trampas comunes.
23.5.4.1 Pauta para evitar la trampa del argumento
Si no conoce el límite de valor en tiempo de ejecución, puede caer en la trampa de parámetros.
EXPLAIN PLAN no puede determinar el tipo de una variable de vinculación a partir del texto de la declaración SQL, siempre asume que el tipo es VARCHAR. Si las variables de vinculación son en realidad números o fechas, TKPROF provoca conversiones de datos implícitas, lo que puede conducir a planes de ejecución ineficientes. Para evitar esto, pruebe diferentes tipos de datos en sus consultas y realice la conversión usted mismo.
23.5.4.2 Pauta para evitar la trampa de coherencia de lectura
Sin saber que una transacción no confirmada realizó una serie de actualizaciones en la columna, es difícil entender por qué se producen tantos accesos a bloques.
Esta situación no suele ser repetible. Si el proceso se vuelve a ejecutar, es poco probable que otra transacción interactúe con él de la misma manera.
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call count cpu elapsed disk query current rows
---- ----- --- ------- ---- ----- ------- ----
Parse 1 0.10 0.18 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.11 0.21 2 101 0 1
Misses in library cache during parse: 1
Parsing user id: 01 (USER1)
Rows Execution Plan
---- --------- ----
0 SELECT STATEMENT
1 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
2 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON_UNIQUE)
23.5.4.3 Pauta para evitar la trampa del esquema
En algunos casos, una consulta de índice aparentemente simple analiza muchos bloques de base de datos y accede a ellos en el esquema actual.
El siguiente ejemplo muestra un ejemplo extremo (y por lo tanto fácil de detectar) de una trampa arquitectónica:
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call count cpu elapsed disk query current rows
-------- ------- -------- --------- ------- ------ ------- ----
Parse 1 0.06 0.10 0 0 0 0
Execute 1 0.02 0.02 0 0 0 0
Fetch 1 0.23 0.30 31 31 3 1
Misses in library cache during parse: 0
Parsing user id: 02 (USER2)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT
2340 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
0 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
Dos estadísticas indican que la consulta puede haberse ejecutado con una exploración completa de la tabla: el acceso al bloque de esquema actual y el número de filas en el plan desde el origen de la fila del acceso a la tabla. La explicación es que el índice requerido se crea después de generar el archivo de rastreo pero antes de ejecutar TKPROF. La generación de un nuevo archivo de seguimiento proporciona los siguientes datos:
SELECT name_id
FROM cq_names
WHERE name = 'FLOOR';
call count cpu elapsed disk query current rows
----- ------ ------ -------- ----- ------ ------- -----
Parse 1 0.01 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
Misses in library cache during parse: 0
Parsing user id: 02 (USER2)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT
1 TABLE ACCESS (BY ROWID) OF 'CQ_NAMES'
2 INDEX (RANGE SCAN) OF 'CQ_NAMES_NAME' (NON-UNIQUE)
En la versión correcta, la llamada de análisis tomó 10 ms de tiempo de CPU y 20 ms de tiempo de ejecución, pero la consulta obviamente no tomó tiempo para ejecutarse y ejecutar la recuperación. Estas excepciones se producen porque 10 milisegundos de pulsos de reloj son demasiado largos en relación con el tiempo que se tarda en ejecutar y obtener datos. En este caso, es importante ejecutar la declaración varias veces para obtener números estadísticamente válidos.
23.5.4.4 Pauta para evitar la trampa del tiempo
En algunos casos, la consulta tarda un tiempo inexplicablemente largo.
Por ejemplo, la actualización de las siguientes 7 filas tardó 19 segundos:
UPDATE cq_names
SET ATTRIBUTES = lower(ATTRIBUTES)
WHERE ATTRIBUTES = :att
call count cpu elapsed disk query current rows
-------- ------- -------- --------- -------- -------- ------- ----------
Parse 1 0.06 0.24 0 0 0 0
Execute 1 0.62 19.62 22 526 12 7
Fetch 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Parsing user id: 02 (USER2)
Rows Execution Plan
------- ---------------------------------------------------
0 UPDATE STATEMENT
2519 TABLE ACCESS (FULL) OF 'CQ_NAMES'
La explicación fue la interferencia de otra transacción . En este caso, otra transacción mantiene un bloqueo compartido en la tabla cq_names durante unos segundos antes y después de que se publique la actualización. El diagnóstico de la aparición de efectos de interferencia requiere experiencia . Por un lado, la comparación de datos es esencial cuando las perturbaciones provocan solo latencias cortas (o pequeños aumentos en los accesos a bloques en el ejemplo anterior). Sin embargo, si la interferencia genera solo una sobrecarga modesta y la declaración es intrínsecamente válida, puede que no sea necesario analizar sus estadísticas.
23.6 Utilidades de rastreo de aplicaciones
Las utilidades de seguimiento de Oracle son TKPROF y TRCSESS.
23.6.1 TRCSESS
La utilidad TRCSESS combina la salida de seguimiento de los archivos de seguimiento seleccionados de acuerdo con los criterios especificados por el usuario.
Después de que TRCSESS haya fusionado la información de seguimiento en un solo archivo de salida, TKPROF puede procesar el archivo de salida.
23.6.1.1 Propósito
TRCSESS es útil para consolidar seguimientos específicos de la sesión con fines de rendimiento o depuración.
El seguimiento de una sesión específica generalmente no es un problema en el modelo de servidor dedicado, ya que un proceso sirve una sesión durante su vida útil. Puede ver la información de seguimiento de las sesiones de los archivos de seguimiento que pertenecen al proceso del servidor. Sin embargo, en una configuración de servidor compartido, las sesiones de usuario son atendidas por diferentes procesos a lo largo del tiempo. Los rastros de las sesiones de los usuarios están dispersos en diferentes archivos de rastreo que pertenecen a diferentes procesos, lo que dificulta obtener una imagen completa del ciclo de vida de la sesión.
23.6.1.2 Directrices
Debe especificar una de las opciones de sesión, ID de cliente, servicio, acción o módulo.
Si especifica más de una opción, TRCSESS fusionará todos los archivos de rastreo que cumplan con los criterios especificados en el archivo de salida.
23.6.1.3 Sintaxis
trcsess [output=output_file_name]
[session=session_id]
[clientid=client_id]
[service=service_name]
[action=action_name]
[module=module_name]
[trace_files]
23.6.1.4 Opciones
TRCSESS admite muchas opciones de línea de comandos.
| parámetro | describir |
|---|---|
| producción | Especifica el archivo donde se genera la salida. Si no se especifica esta opción, la utilidad escribirá en la salida estándar. |
| sesión | Combine la información de seguimiento para las sesiones especificadas. Un identificador de sesión es una combinación de un índice de sesión y un número de secuencia de sesión, como 21.2371. Puede encontrar estos valores en la vista V$SESSION. |
| Identificación del cliente | Combine la información de seguimiento para el ID de cliente especificado. |
| servicio | Combine la información de rastreo para el nombre de servicio especificado. |
| acción | Combine la información de rastreo para el nombre de operación especificado. |
| módulo | Combine la información de rastreo para el nombre del módulo especificado. |
| archivos_rastreo | Enumere los nombres de los archivos de rastreo, separados por espacios, donde TRCSESS debe buscar información de rastreo. Puede utilizar caracteres comodín (*) para especificar nombres de archivos de seguimiento. Si no se especifica ningún archivo de seguimiento, TRCSESS utilizará todos los archivos del directorio actual como entrada. |
23.6.1.5 Ejemplos
Ejemplo 23-2 Seguimiento de una sola sesión:
trcsess session=21.2371
trcsess session=21.2371 main_12359.trc main_12995.trc
La salida es:
[PROCESS ID = 12359]
*** 2014-04-02 09:48:28.376
PARSING IN CURSOR #1 len=17 dep=0 uid=27 oct=3 lid=27 tim=868373970961 hv=887450622 ad='22683fb4'
select * from cat
END OF STMT
PARSE #1:c=0,e=339,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=868373970944
EXEC #1:c=0,e=221,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=868373971411
FETCH #1:c=0,e=791,p=0,cr=7,cu=0,mis=0,r=1,dep=0,og=4,tim=868373972435
FETCH #1:c=0,e=1486,p=0,cr=20,cu=0,mis=0,r=6,dep=0,og=4,tim=868373986238
*** 2014-04-02 10:03:58.058
XCTEND rlbk=0, rd_only=1
STAT #1 id=1 cnt=7 pid=0 pos=1 obj=0 op='FILTER '
STAT #1 id=2 cnt=7 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ$ '
STAT #1 id=3 cnt=7 pid=2 pos=1 obj=37 op='INDEX RANGE SCAN I_OBJ2 '
STAT #1 id=4 cnt=0 pid=1 pos=2 obj=4 op='TABLE ACCESS CLUSTER TAB$J2 '
STAT #1 id=5 cnt=6 pid=4 pos=1 obj=3 op='INDEX UNIQUE SCAN I_OBJ# '
[PROCESS ID=12995]
*** 2014-04-02 10:04:32.738
Archiving is disabled
23.6.2 PROF TK
El programa TKPROF formatea el contenido de un archivo de rastreo y coloca la salida en un archivo de salida legible.
TKPROF también puede hacer lo siguiente:
- Cree scripts SQL que almacenen estadísticas en la base de datos
- Determinar el plan de ejecución de la sentencia SQL
Nota: la salida de TKPROF no incluye automáticamente el plan de ejecución real de la instrucción SQL si el cursor de la instrucción SQL no está cerrado. En este caso, utilice la opción EXPLAIN con TKPROF para generar un plan de ejecución.
TKPROF informa los recursos consumidos por cada declaración ejecutada, la cantidad de veces que se llamó y la cantidad de filas que procesó.
23.6.2.1 Propósito
TKPROF encuentra las sentencias que más recursos consumen .
Con una línea de base disponible , puede evaluar si los recursos utilizados son razonables para la situación de trabajo dada.
23.6.2.2 Directrices
Los archivos de entrada y salida son los únicos parámetros necesarios.
Si invoca TKPROF sin argumentos, la herramienta muestra ayuda en línea.
23.6.2.3 Sintaxis
tkprof input_file output_file
[ waits=yes|no ]
[ sort=option ]
[ print=n ]
[ aggregate=yes|no ]
[ insert=filename3 ]
[ sys=yes|no ]
[ table=schema.table ]
[ explain=user/password ]
[ record=filename4 ]
[ width=n ]
23.6.2.4 Opciones
TKPROF admite muchas opciones de línea de comandos.
| parámetro | describir |
|---|---|
| fichero de entrada | Especifica el archivo de entrada, que es un archivo de seguimiento que contiene estadísticas generadas por la función Seguimiento de SQL. Este archivo puede ser un archivo de seguimiento generado para una única sesión o mediante la concatenación de un único archivo de seguimiento de varias sesiones. |
| archivo de salida | Especifica el archivo en el que TKPROF escribe su salida formateada. |
| MURGA | Especifica si registrar un resumen de los eventos de espera encontrados en el archivo de seguimiento. Los valores válidos son SÍ (predeterminado) y NO. |
| CLASIFICAR | Ordena las instrucciones SQL rastreadas en orden descendente de las opciones de ordenación especificadas antes de incluirlas en el archivo de salida. Si se especifica más de una opción, la salida se ordena en orden descendente por la suma de los valores especificados en las opciones de ordenación. Si omite este parámetro, TKPROF enumera las declaraciones en el archivo de salida en el orden en que se usaron por primera vez. Las opciones de clasificación son las siguientes: |
| IMPRIMIR | Enumere solo la primera instrucción SQL ordenada por enteros en el archivo de salida. Si se omite este parámetro, TKPROF enumera todas las sentencias de SQL rastreadas. Este parámetro no afecta a los scripts SQL opcionales. Los scripts SQL siempre generan datos de inserción para todas las declaraciones SQL rastreadas. |
| AGREGAR | Si especifica AGGREGATE = NO, TKPROF no agregará múltiples usos del mismo literal SQL. |
| INSERTAR | Cree un script SQL que almacene estadísticas de archivos de seguimiento en la base de datos. TKPROF crea este script con el nombre filename3. Este script crea una tabla e inserta una fila de estadísticas en la tabla para cada instrucción SQL rastreada. |
| SISTEMA | Habilita y deshabilita la lista de sentencias SQL emitidas por el usuario SYS o sentencias SQL recursivas en el archivo de salida. El valor predeterminado SÍ hace que TKPROF enumere estas declaraciones. Un valor de NO hace que TKPROF los ignore. Este parámetro no afecta a los scripts SQL opcionales. Los scripts SQL siempre insertan estadísticas para todas las declaraciones SQL rastreadas, incluidas las declaraciones SQL recursivas. |
| MESA | Especifica el esquema y el nombre de la tabla donde TKPROF coloca temporalmente el plan de ejecución antes de escribirlo en el archivo de salida. Si la tabla especificada existe, TKPROF elimina todas las filas de la tabla, las usa en la instrucción EXPLAIN PLAN (escribe más filas en la tabla) y luego elimina las filas. Si la tabla no existe, TKPROF la crea, la usa y la descarta. … |
| EXPLICAR | Determina el plan de ejecución para cada instrucción SQL en el archivo de seguimiento y escribe estos planes de ejecución en el archivo de salida. TKPROF también muestra el número de filas procesadas por cada paso del plan de ejecución. … |
| REGISTRO | Crea un script SQL con el nombre de archivo especificado usando todo el SQL no recursivo en el archivo de seguimiento. Puede utilizar este script para reproducir eventos de usuario en un archivo de seguimiento. |
| ANCHO | Un número entero que controla el ancho de línea de salida de ciertas salidas TKPROF, como los planes de explicación. Este parámetro es útil para el procesamiento posterior de la salida TKPROF. |
Las opciones después del parámetro SORT son las siguientes: El prefijo PRS indica la fase PARSE, EXE indica la fase EXECUTE y FCH indica la fase FETCH:
PRSCNT - 解析次数
PRSCPU - 解析所花费的 CPU 时间
PRSELA - 解析所用时间
PRSDSK - 解析期间从磁盘物理读取的次数
PRSQRY - 解析期间一致模式块读取数
PRSCU - 解析期间读取的当前模式块数
PRSMIS - 分析期间库高速缓存未命中数
EXECNT - 执行次数
EXECPU - 执行所花费的 CPU 时间
EXEELA - 执行所花费的时间
EXEDSK - 执行期间从磁盘物理读取的次数
EXEQRY - 执行期间一致模式块读取数
EXECU - 执行期间当前模式块读取数
EXEROW - 执行期间处理的行数
EXEMIS - 执行期间库缓存未命中数
FCHCNT - 提取次数
FCHCPU - 获取数据所花费的 CPU 时间
FCHELA - 提取所用的时间
FCHDSK - 提取期间从磁盘物理读取的次数
FCHQRY - 获取期间一致模式块读取数
FCHCU - 获取期间当前模式块读取数
FCHROW - 获取的行数
USERID - 解析游标的用户 ID
23.6.2.5 Salida
Esta sección explica la salida de TKPROF.
23.6.2.5.1 Identificación del Usuario que Emite la Sentencia SQL en TKPROF
TKPROF enumera el ID de usuario del usuario que emitió cada instrucción SQL.
如果 SQL 跟踪输入文件包含来自多个用户的统计信息，并且如果该语句是由多个用户发出的，那么 TKPROF 会列出最后一个用户的 ID 来解析该语句。 所有数据库用户的用户 ID 出现在数据字典中的 ALL_USERS.USER_ID 列中。
23.6.2.5.2 Tabular Statistics in TKPROF
TKPROF 列出发出每个 SQL 语句的用户的用户 ID。
如果 SQL 跟踪输入文件包含来自多个用户的统计信息，并且如果该语句是由多个用户发出的，那么 TKPROF 会列出最后一个用户的 ID 来解析该语句。 所有数据库用户的用户 ID 出现在数据字典中的 ALL_USERS.USER_ID 列中。
表 23-4 CALL 列值
| CALL值 | 含义 |
|---|---|
| PARSE | 将 SQL 语句转换为执行计划，包括检查是否有适当的安全授权以及检查表、列和其他引用对象是否存在。 |
| EXECUTE | Oracle 数据库实际执行的语句。 对于 INSERT、UPDATE、DELETE 和 MERGE 语句，这会修改数据。 对于 SELECT 语句，这标识了选定的行。 |
| FETCH | 检索查询返回的行。 仅对 SELECT 语句执行提取。 |
SQL 跟踪工具输出的其他列是语句的所有解析、执行和提取的组合统计信息。 query 和 current 的总和是访问的缓冲区总数，也称为逻辑 I/O (LIO)。 请参见表 23-5。
表 23-5 解析、执行和获取的 SQL 跟踪统计信息。
| SQL Trace统计 | 含义 |
|---|---|
| COUNT | 语句被解析、执行或提取的次数。 |
| CPU | 语句的所有解析、执行或提取调用的总 CPU 时间（以秒为单位）。 如果未启用 TIMED_STATISTICS，则此值为零 (0)。 |
| ELAPSED | 语句的所有解析、执行或提取调用的总耗用时间（以秒为单位）。 如果未启用 TIMED_STATISTICS，则此值为零 (0)。 |
| DISK | 为所有解析、执行或提取调用从磁盘上的数据文件物理读取的数据块总数。 |
| QUERY | 在一致模式下为所有解析、执行或提取调用检索的缓冲区总数。 通常，缓冲区以查询的一致模式检索。 |
| CURRENT | 当前模式中检索到的缓冲区总数。 在当前模式下检索缓冲区以用于 INSERT、UPDATE 和 DELETE 等语句。 |
有关已处理行的统计信息显示在 ROWS 列中。 该列显示 SQL 语句处理的行数。 此总数不包括由 SQL 语句的子查询处理的行。 对于 SELECT 语句，返回的行数出现在提取步骤中。 对于 UPDATE、DELETE 和 INSERT 语句，处理的行数出现在执行步骤中。
注意：关闭游标时会显示行源计数。 在SQL*Plus中，只有一个用户游标，所以每执行一条语句都会导致前一个游标关闭； 因此，显示行源计数。 PL/SQL 有自己的游标处理，并且在父游标关闭时不会关闭子游标。 退出或重新连接会导致显示计数。
23.6.2.5.3 Library Cache Misses in TKPROF
TKPROF 还列出了每个 SQL 语句的解析和执行步骤导致的库缓存未命中数。
这些统计数据出现在表格统计数据之后的单独行中。 如果该语句导致没有库高速缓存未命中，则 TKPROF 不会列出统计信息。 在“示例”中，该语句导致解析步骤有一次库缓存未命中，而执行步骤没有未命中。
23.6.2.5.4 Row Source Operations in TKPROF
在 TKPROF 输出中，行源操作显示对行执行的每个操作处理的行数，以及其他行源信息，例如物理读取和写入。
表 23-6 行源操作
| 行源操作 | 含义 |
|---|---|
| cr | 行源执行的一致读取。 |
| r | 行源执行的物理读取 |
| w | 行源执行的物理写入 |
| time | 以微秒为单位的时间 |
在以下示例 TKPROF 输出中，注意行源操作列下的 cr、r、w 和时间值：
Rows Row Source Operation
------- ---------------------------------------------------
0 DELETE (cr=43141 r=266947 w=25854 time=60235565 us)
28144 HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us)
51427 TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us)
647529 INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK
(cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)
23.6.2.5.5 Wait Event Information in TKPROF
如果存在等待事件信息，则 TKPROF 输出包括等待事件部分。
输出类似于以下内容：
Elapsed times include waiting on following events:
Event waited on Times Waited Max. Wait Total Waited
--------------------------- ------------ --------- ------------
db file sequential read 8084 0.12 5.34
direct path write 834 0.00 0.00
direct path write temp 834 0.00 0.05
db file parallel read 8 1.53 5.51
db file scattered read 4180 0.07 1.45
direct path read 7082 0.00 0.05
direct path read temp 7082 0.00 0.44
rdbms ipc reply 20 0.00 0.01
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
此外，在文件末尾对整个跟踪文件的等待事件进行汇总。
要确保将等待事件信息写入会话的跟踪文件，请运行以下 SQL 语句：
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';
23.6.2.6 Examples
本节演示常见的 TKPROF 用例。
示例 23-4 打印资源最密集的语句
如果您正在使用 SORT 参数和 PRINT 参数的组合处理大型跟踪文件，那么您可以生成仅包含最高资源密集型语句的 TKPROF 输出文件。 以下语句打印跟踪文件中产生最多物理 I/O 的 10 个语句：
TKPROF ora53269.trc ora53269.prf SORT = (PRSDSK, EXEDSK, FCHDSK) PRINT = 10
示例 23-5 生成 SQL 脚本
此示例运行 TKPROF，接受名为 examp12_jane_fg_sqlplus_007.trc 的跟踪文件，并写入名为 outputa.prf 的格式化输出文件：
TKPROF examp12_jane_fg_sqlplus_007.trc OUTPUTA.PRF EXPLAIN=hr
TABLE=hr.temp_plan_table_a INSERT=STOREA.SQL SYS=NO SORT=(EXECPU,FCHCPU)
此示例可能比屏幕上的单行长，您可能需要使用连续字符，具体取决于操作系统。
请注意此示例中的其他参数：
- EXPLAIN 值导致 TKPROF 作为用户 hr 连接并使用 EXPLAIN PLAN 语句为每个跟踪的 SQL 语句生成执行计划。 您可以使用它来获取访问路径和行源计数。
注意：如果 SQL 语句的游标没有关闭，则 TKPROF 输出不会自动包含 SQL 语句的实际执行计划。 在这种情况下，您可以使用带有 TKPROF 的 EXPLAIN 选项来生成执行计划。 - TABLE 值导致 TKPROF 使用模式 scott 中的表 temp_plan_table_a 作为临时计划表。
- INSERT 值导致 TKPROF 生成名为 STOREA.SQL 的 SQL 脚本，该脚本存储数据库中所有跟踪的 SQL 语句的统计信息。
- 值为 NO 的 SYS 参数导致 TKPROF 从输出文件中省略递归 SQL 语句。 这样就可以忽略临时表操作等Oracle数据库内部语句。
- SORT 值导致 TKPROF 按照执行所花费的 CPU 时间和在将它们写入输出文件之前获取行所花费的 CPU 时间的总和对 SQL 语句进行排序。 为了获得最高效率，请始终使用 SORT 参数。
示例 23-6 TKPROF 标头
此示例显示了 TKPROF 报告的样本标题。
TKPROF: Release 12.1.0.0.2
Copyright (c) 1982, 2012, Oracle and/or its affiliates. All rights reserved.
Trace file: /disk1/oracle/log/diag/rdbms/orcla/orcla/trace/orcla_ora_917.trc
Sort options: default
***************************************************************************
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
***************************************************************************
示例 23-7 TKPROF 主体
此示例显示了 TKPROF 报告的样本主体。
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.01 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 44
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 28.59 28.59
********************************************************************************
select condition
from
cdef$ where rowid=:1
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 2 0 1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS BY USER ROWID OBJ#(31) (cr=1 r=0 w=0 time=151 us)
********************************************************************************
SELECT last_name, job_id, salary
FROM employees
WHERE salary =
(SELECT max(salary) FROM employees)
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 15 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.02 0.01 0 15 0 1
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 44
Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS FULL EMPLOYEES (cr=15 r=0 w=0 time=1743 us)
1 SORT AGGREGATE (cr=7 r=0 w=0 time=777 us)
107 TABLE ACCESS FULL EMPLOYEES (cr=7 r=0 w=0 time=655 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 9.62 9.62
********************************************************************************
********************************************************************************
delete
from stats$sqltext st
where (hash_value, text_subset) not in
(select --+ hash_aj
hash_value, text_subset
from stats$sql_summary ss
where ( ( snap_id < :lo_snap
or snap_id > :hi_snap
)
and dbid = :dbid
and instance_number = :inst_num
)
or ( dbid != :dbid
or instance_number != :inst_num)
)
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 29.60 60.68 266984 43776 131172 28144
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 29.60 60.68 266984 43776 131172 28144
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 22
Rows Row Source Operation
------- ---------------------------------------------------
0 DELETE (cr=43141 r=266947 w=25854 time=60235565 us)
28144 HASH JOIN ANTI (cr=43057 r=262332 w=25854 time=48830056 us)
51427 TABLE ACCESS FULL STATS$SQLTEXT (cr=3465 r=3463 w=0 time=865083 us)
647529 INDEX FAST FULL SCAN STATS$SQL_SUMMARY_PK
(cr=39592 r=39325 w=0 time=10522877 us) (object id 7409)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 8084 0.12 5.34
direct path write 834 0.00 0.00
direct path write temp 834 0.00 0.05
db file parallel read 8 1.53 5.51
db file scattered read 4180 0.07 1.45
direct path read 7082 0.00 0.05
direct path read temp 7082 0.00 0.44
rdbms ipc reply 20 0.00 0.01
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
********************************************************************************
示例 23-8 TKPROF 摘要
此示例显示 TKPROF 报告的摘要。
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.04 0.01 0 0 0 0
Execute 5 0.00 0.04 0 0 0 0
Fetch 2 0.00 0.00 0 15 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 0.04 0.06 0 15 0 1
Misses in library cache during parse: 4
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 6 0.00 0.00
SQL*Net message from client 5 77.77 128.88
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 2 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 2 0 1
Misses in library cache during parse: 1
5 user SQL statements in session.
1 internal SQL statements in session.
6 SQL statements in session.
********************************************************************************
Trace file: main_ora_27621.trc
Trace file compatibility: 9.00.01
Sort options: default
1 session in tracefile.
5 user SQL statements in trace file.
1 internal SQL statements in trace file.
6 SQL statements in trace file.
6 unique SQL statements in trace file.
76 lines in trace file.
128 elapsed seconds in trace file.
23.7 Views for Application Tracing
您可以使用数据字典和 V$ 视图来监视跟踪。
23.7.1 Views Relevant for Trace Statistics
您可以显示使用以下 V$ 和 DBA 视图收集的统计信息。
表 23-7 诊断视图
| 视图 | 描述 |
|---|---|
| DBA_ENABLED_AGGREGATIONS | 当前启用的统计信息的累积全局统计信息 |
| V$CLIENT_STATS | 指定客户端标识符的累积统计信息 |
| V$SERVICE_STATS | 指定服务的累计统计信息 |
| V$SERV_MOD_ACT_STATS | 指定服务、模块和操作的组合的累积统计信息 |
| V$SERVICEMETRIC | 数据库调用经过时间和 CPU 使用的累积统计信息 |
| V$DIAG_TRACE_FILE | 有关当前容器的 ADR 中所有跟踪文件的信息 |
| V$DIAG_APP_TRACE_FILE | 有关当前容器的 ADR 中包含应用程序跟踪数据（SQL_TRACE 或 OPTIMIZER_TRACE 事件数据）的所有跟踪文件的信息 |
| V$DIAG_TRACE_FILE_CONTENTS | ADR 中跟踪文件中的跟踪数据 |
| V$DIAG_SQL_TRACE_RECORDS | ADR 中跟踪文件中的 SQL_TRACE 数据 |
| V$DIAG_OPT_TRACE_RECORDS | ADR 中跟踪文件中的优化器跟踪事件数据 |
| V$DIAG_SESS_SQL_TRACE_RECORDS | 当前用户会话的 ADR 跟踪文件中的 SQL_TRACE 数据 |
| V$DIAG_SESS_OPT_TRACE_RECORDS | 当前用户会话的 ADR 跟踪文件中的优化器跟踪事件数据 |
| V$DIAG_ALERT_EXT | 当前容器的 ADR 中基于 XML 的警报日志的内容 |
23.7.2 Views Related to Enabling Tracing
Cloud Control 报告或 DBA_ENABLED_TRACES 视图可以显示未完成的跟踪。
在 DBA_ENABLED_TRACES 视图中，您可以确定有关如何启用跟踪的详细信息，包括跟踪类型。 跟踪类型指定是否为客户端标识符、会话、服务、数据库或服务、模块和操作的组合启用跟踪。