explain plan ¿cómo obtener el explain plan? aunque el proceso mostrado es simple, es recomendable...

EXPLAIN PLANEXPLAIN PLAN

¿Cómo obtener el EXPLAIN PLAN?

Aunque el proceso mostrado es simple, es recomendable utilizar herramientas de “terceros” las cuales facilitan aun más el trabajo. De hecho los planes de ejecución generados por terceros son más ilustrativos que los generados por Oracle.

Observemos a continuación un ejemplo de un EXPLAN PLAN generado por la herramienta JDeveloper de Oracle.


Podemos observar que los resultados obtenidos con esta herramienta, son más amigables que los obtenidos mediante SQL*Plus.

Uso de un hint, se verán posteriormente…


¿Cómo leer el resultado del EXPLAIN PLAN?

Interpretar un plan de ejecución, generalmente requiere práctica. A pesar de esto, he aquí algunas pautas generales que ayudan a interpretarlo.

1. Mientras más indentado se encuentre un ruta de acceso (access path), más tempranamente se ejecuta.

2. Si dos pasos están indentados a un mismo nivel, la sentencia que se encuentre más arriba se ejecutará primero.

Observemos un ejemplo:



Supongamos la consulta:

SELECT nombre, ciudad, departamentoFROM companiaWHERE ciudad = 'medellin'AND departamento = 'antioquia';



Un plan de ejecución posibleposible, podría ser el siguiente:

query_plan--------------------------------------------TABLE ACCES COMPANIA BY ROWID AND-EQUAL INDEX RANGE SCAN COMPANIA$CIUDAD INDEX RANGE SCAN COMPANIA$DEPARTAMENTO



Siguiendo las pautas observadas, se puede decir lo

siguiente sobre este plan de ejecución:

1. Los accesos más indentados son los INDEX RANGE

SCAN y como se encuentran al mismo nivel, entonces el

primero que se ejecutará será:

INDEX RANGE SCAN COMPANIA$CIUDAD

2. Y luego:

INDEX RANGE SCAN COMPANIA$DEPARTAMENTO



3. Luego, se tiene que los resultados de ambas operaciones, le suministraran información a la operación AND_EQUAL.

4. AND_EQUAL a su vez, le entregará información a la operación TABLE ACCES COMPANIA BY ROWID

En algunas ocasiones, es necesario tener en cuenta otros factores a la hora de interpretar un plan de ejecución. Observemos otro ejemplo



Observemos el siguiente plan de ejecución:

query_plan-------------------------------------------------SELECT STATEMENT SORT ORDER BY NESTED LOOPS TABLE ACCESS FULL CLIENTE TABLE ACCESS BY ROWID EMPLEADOS INDEX RANGE SCAN EMPLEADO_NOMBRES_IDX



Una ruta de acceso puede estar compuesta por varios pasos en el plan de ejecución. Si observamos detenidamente el resultado del EXPLAIN PLAN anterior y siguiendo las dos pautas antes mencionadas se podría pensar que lo primero que se ejecuta sería:

INDEX RANGE SCAN EMPLEADO_NOMBRES_IDX

Sin embargo, esta instrucción hace parte, o mejor dicho, se ejecuta de manera conjunta con la instrucción:

TABLE ACCESS BY ROWID EMPLEADOS



Por consiguiente al ser una operación conjunta, esta se tomará como un grupo, es decir, como una sola operación.

1. Por lo tanto, la primera operación a ejecutarse será:

TABLE ACCESS FULL CLIENTE

Ya que se encuentra al mismo nivel que la operación conjunta formada por:

TABLE ACCESS BY ROWID EMPLEADOS INDEX RANGE SCAN EMPLEADO_NOMBRES_IDX



Luego de haber entendido lo anterior, los pasos en los que se ejecutará la consulta son:

SELECT STATEMENT4 SORT ORDER BY3 NESTED LOOPS1 TABLE ACCESS FULL CLIENTE2 TABLE ACCESS BY ROWID EMPLEADOS INDEX RANGE SCAN EMPLEADO_NOMBRES_IDX

Miremos ahora un último ejemplo:



query_plan---------------------------------------------PROJECTION SORT UNIQUE UNION MERGE JOIN SORT JOIN TABLE ACCESS FULL COMPANIA SORT JOIN TABLE ACCESS FULL VENTAS TABLE ACCESS BY ROWID COMPETIDOR INDEX UNIQUE SCAN COMPETIDOR_PK


Otros Aspectos acerca del EXPLAIN PLAN

Como se observó, el EXPLAIN PLAN ofrece información que puede ser de utilidad a la hora de obtener una idea del rendimiento de la consulta ejecutada. Dichos datos provienen de las columnas de la tabla del EXPLAIN PLAN y son:

Costo - Cardinalidad - Bytes

Sin embargo, estos simplemente dan una idea superficial de que es lo que ocurre al ejecutar una sentencia, por lo tanto es necesario apoyarse en otras herramientas (que se verán a continuación) para formarse una mejor idea sobre el rendimiento de una consulta.

SQL TRACE Y TKPROFSQL TRACE Y TKPROF

• Aunque el EXPLAIN PLAN es una herramienta útil, posee limitantes que hacen que sea un instrumento incompleto para la toma de decisiones acerca de los planes de ejecución

• Por ejemplo, no es posible determinar adecuadamente entre dos planes de ejecución, cual es más eficiente, por ello se puede acudir a otras dos herramientas: el SQL TRACE y TKPROF

• Con estas herramientas se puede obtener información acerca de los recursos utilizados por el sistema (memoria, CPU, etc.), tiempos de “parsing”, de recuperación de registros y de ejecución

SQL TRACE Y TKPROFSQL TRACE Y TKPROFSQL TRACE

El SQL TRACE es una herramienta que permite rastrear las sentencias SQL ejecutadas dentro de una sesión o instancia, almacenándolas dentro de un archivo específico*.

En este archivo se guardan varios elementos interesantes, tales como: tiempos de CPU, de entradas y salidas de disco, parsing, procesamiento de registros etc.

* Generalmente, estos archivos de rastreo tienen extensión trc


El archivo generado por el SQL TRACE es básicamente, imposible de interpretar directamente. Esto se puede comprobar abriendo el archivo con cualquier editor de texto plano. Ejemplo:


Debido a que la salida del archivo de rastreo es prácticamente ilegible, se debe utilizar una herramienta de formateo que toma como entrada, el archivo de rastreo y va a generar un archivo con información comprensible y fácil de interpretar que se espera conlleve a la toma de buenas decisiones.

Esta herramienta de formateo (proporcionada también por Oracle) es conocida como TKPROF

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, para utilizar SQL TRACE y TKPROF:

1. Habilitar el SQL TRACE, para instancias o sesiones

2. Localizar los archivos de rastreo de interés

3. Usar el TKPROF para formatear

4. Interpretar los resultados

5. Optimizar la consulta y repetir el proceso si es necesario

A continuación se explica en detalle cada uno de los pasos que componen este proceso:

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF1. Habilitar el SQL TRACE, para instancias o sesiones

Para Habilitar el rastreo de las sentencias de interés, se ejecuta el siguiente comando desde SQLPLUS:

ALTER SESSION SET SQL_TRACE = TRUE;

Para activarlo desde PL/SQL, se debe utilizar:

DBMS_SESSION.SET_SQL_TRACE(TRUE);

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF2. Localizar los archivos de rastreo de interés

Teniendo ya habilitado el SQL TRACE, el siguiente paso es la búsqueda del archivo generado por el mismo.

Estos archivos de rastreo (.trc) son guardados generalmente en la ruta que tiene por defecto el parámetro de configuración:

user_dump_dest

El nombre de los archivos generados por la herramienta, posee la siguiente sintaxis:

header_pid.trc

Donde header es generalmente “ORA”, “Oracle_SID_ORA” u “SID_ORA” y el PID es el identificador que Oracle asigna a este proceso.

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF2. Localizar los archivos de rastreo de interés (cont.)

Para hallar la ruta donde se encuentran los archivos de rastreo, se puede ejecutar la siguiente consulta:

SELECT value FROM v$parameter WHERE name = 'user_dump_dest';

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF2. Localizar los archivos de rastreo de interés (cont.)

Para encontrar un archivo de rastreo específico, es necesario conocer cual fue el PID que Oracle asignó a este proceso. Esto se puede averiguar mediante la siguiente consulta:

SELECT spid FROM sys.v_$processWHERE addr = ( SELECT paddr FROM sys.v_$session WHERE audsid = userenv('sessionid') );

Sin embargo, si se quiere personalizar el directorio donde se guardarán los archivos de rastreo, se puede hacer lo siguiente:

ALTER SYSTEM SET user_dump_dest = 'ruta_de_directorio';

Nota: el cambio de este parámetro debe realizarse antes de habilitar el rastreo de sentencias.

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF3. Usar el TKPROF para formatear

Una vez se encuentra el archivo de rastreo requerido, se utiliza la herramienta TKPROF para transformarlo en una forma interpretable. La sintaxis es:

tkprof trace_file output_file [explain=username/password] sort(sort options)]

TKPROF, se ejecuta por fuera del entorno de SQLPLUS, es decir, en una línea de comandos del sistema operativo. A continuación se muestran las diferentes opciones de los parámetros de configuración.

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF3. Usar el TKPROF para formatear

trace_filetrace_file Es el nombre del archivo generado por SQL_TRACE

Output_fileOutput_file Es el nombre del archivo en el cual quedará la información relevante

explain=username/password

Especifica la conexión, la cual será utilizada para generar los planes de ejecución SQL.

Sort=(sort keys) Muestra las sentencias SQL en valores descendientes de acuerdo a las claves de ordenamiento elegidas, estas son parsing (prc), ejecución (.exe), recuperación (fch).


Funciones del ordenamiento del TKPROF: Cada clave de ordenamiento, se compone de 2 partes, la primera indica el tipo de llamada y la segunda parte, los valores a ser ordenados.

A continuación se presenta una tabla completa acerca de las opciones de ordenamiento del TKPROF.

Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF3. Usar el TKPROF para formatear


prs Ordena sobre valores en el momento de parsing.

cnt Ordena sobre el número de llamadas

exe Ordena sobre valores durante llamadas de ejecución

cpu Ordena por el consumo de CPU.

fch Ordena sobre valores durante llamadas a fetch.

ela Ordena sobre tiempo transcurrido

dsk Ordena sobre lecturas de disco

qry Ordena sobre lecturas consistentes.

cu Ordena sobre lecturas actuales

mis Ordenamiento sobre fallos en la cache de la biblioteca., aplica solo a parsing y ejecución.

row Ordena sobre filas procesadas. Aplica solo a exe y fch.


Ejemplo:

• Exedsk: Indica que las sentencias son ordenadas en el archivo de salida de acuerdo a las lecturas de disco durante la ejecución.



Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF4. Interpretación los resultados.

Estadísticas tabuladas: TKPROF lista las estadísticas en filas y columnas para una sentencia SQL. Cada fila corresponde a uno de los 3 pasos del procesamiento del SQL:

PARSE: Este paso traduce la sentencia SQL en un plan de ejecución, chequeo de existencia de objetos, permisos etc.

EXECUTE: Este paso es la ejecución real de la sentencia. Para las sentencias INSERT, UPDATE, y DELETE, este paso modifica los datos. Para las sentencias SELECT, el paso identifica las filas seleccionadas.

FETCH: Este paso trae las filas retornadas por una consulta. Estos “fetches” solo se realizan para sentencias SELECT

• Las otras columnas de la herramienta TKPROF son estadísticas combinadas de todos los “parsings”, ejecuciones y “fetches” de una sentencia.

• La suma de las columnas de los totales de query y current es el número total de bloques leídos.

• A continuación se presenta el significado de las columnas.



COUNT: Número de veces que a una sentencia se le realizó parsing, ejecución o fetching.

CPU: Tiempo total de CPU en segundos para las llamadas de parsing, ejecución y fetch.

ELAPSED: Tiempo total transcurrido para todas las llamadas de parsing, fetch y ejecuciones de la sentencia.

DISK: Número total de Bloques de datos leídos físicamente de los archivos de datos en el disco para las llamadas de parsing, ejecución y fetch.

QUERY: Número total de buffers traídos en modo consistente para todas las llamadas de parsing, fetch y ejecuciones de la sentencia. (los buffers se traen en modo consistente para las consultas).

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF4. Interpretación los resultados.

CURRENT: Número total de buffers traídos en modo current para todas las llamadas de parsing, fetch y ejecuciones de las sentencias que implican modificacines sobre tablas (UPDATE, DELETE, e INSERT).

Rows: Las estadísticas acerca de las filas procesadas, aparecen en esta columna. El número total no incluye las filas procesadas por las subconsultas de la sentencia SQL.

Para las sentencias SELECT, el número de filas retornadas aparece para cada uno de los pasos de fetch. Para las sentencias UPDATE, DELETE, e INSERT, el número de filas procesadas aparece por cada paso de ejecución.

SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF4. Interpretación los resultados.


Los Resultados del TKPROF, se encuentran tabulados y cada valor, como se vio, tiene su propio significado.

Observemos detenidamente la salida del TKPROF, y a través de este, se podrá decidir acerca de la eficiencia de una consulta SQL específica. Esto lo se hará observando algunas tasas puntuales derivadas de esta salida.

Observemos con detenimiento los elementos de la salida del TKPROF



call count cpu elapsed disk query current rows--------- ------- ------ ------- ------ ------ -------- ------Parse(a) (d) -- -- -- -- -- --Execute(b) (e) -- -- -- -- -- --Fetch(c) (j) -- -- -- -- -- (i)--------- ------- ------ ------- ------ ------ -------- ------Total --- -- -- (k) (f) (g) (h)

Luego de observar los elementos importantes en la salida del TKPROF, se pasa a analizar las tasas que ayudarán a determinar, que consultas SQL necesitan ser optimizadas.



Tasas de Importancia

1. Bloques leídos (f+g) a filas procesadas (h). Esto indica de una manera general, el costo relativo de la consulta. Mientras más bloques tienen que ser accedidos en relación a las filas retornadas, la fila traída será mucho más costosa. Una relación similar se puede deducir sobre la tasa de bloques leídos sobre ejecuciones (f+g)/e.

Tasas por encima de 10 o 20, pueden indicar alguna posibilidad de optimización en este campo.


SQL TRACE Y TKPROFSQL TRACE Y TKPROFPasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF

(Interpretación los resultados)Tasas de Importancia

2. Parsing (d), sobre ejecución (e). Idealmente, el conteo de parsing debe ser cercano a uno. Si este valor es alto en relación al conteo de ejecuciones, la sentencia entonces ha sido parseada varias veces sin necesidad.

3. Filas traidas (i) sobre traidas (j) (Rows Fetched over fetches). Esto indica el nivel en el cual, la capacidad del array fetch ha sido utilizada. Una tasa cercana a uno, indica que no hubo procesamiento a través de arrays, lo que significa que existe una buena oportunidad para optimizar.


(Interpretación los resultados)Tasas de Importancia

4. Lecturas de Disco (k) a lecturas lógicas. (f+g). Esto es una medida de la tasa de error (miss rate) dentro del buffer de datos en la cache. Generalmente se busca que esta tasa no represente más de un 10%

Ahora se observará un ejemplo específico que mostrará como se puede utilizar el TKPROF como herramienta eficaz de análisis y optimización.


(Interpretación los resultados)

Supongamos que se tiene la siguiente consulta SQL:

SELECT e.apellido, e.nombre, e.fecha_nacimiento FROM empleados e WHERE EXISTS (SELECT cod FROM clientes c WHERE e.apellido = apellido_contacto AND e.nombre = c.apellido_nombre AND e.fecha_nacimiento = c.fecha_nacimiento)ORDER BY e.apellido, e.nombre;

Ahora observemos cual es la salida respectiva del TKPROF



call count cpu elapsed disk query current rows--------- ------- ------ ------- ------ ------ -------- ------Parse 1 0 0.43 0 0 0 0Execute 1 0 0.00 0 0 0 0Fetch 11 0 323.74 204161 212083 2400 151--------- ------- ------ ------- ------ ------ -------- ------Total 13 0 324.17 204161 212083 2400 151

Misses in library cache during parse: 0Optimizer Hint: RULE

Rows Execution Plan------- --------------------------------------------- 0 SELECT STATEMENT 800 FILTER 800 TABLE ACCESS (BY ROWID) OF 'EMPLEADOS‘ 801 INDEX (RANGE SCAN) OF 'INDICE_EMPLEADOS_NOMAP' 4109475 TABLE ACCESS FULL OF 'CLIENTES'



Observemos ahora, las tasas analizadas anteriormente para saber si existe campo para optimizar.

TASA V. NORMAL V. ENCONTRADO

(f+g) / h Entre 10 y 20 1420 aprox.

d / e 1 (o cerca de 1)

1

i / j Mientras mayor valor, mejor

13.73

k / (f+g) Menos de 10 95



Cuando se observa la salida del TKPROF, de manera general, se debe considerar:

- ¿Cuán eficiente es la sentencia? (indicado por traídas de bloque por filas retornadas -- (f + g) / h ).

- ¿Cómo se trajeron los datos? En otras palabras, ¿qué significa el plan de ejecución?

- ¿En qué pasos del plan de ejecución se procesaron la mayor cantidad de filas? ¿cómo se pueden evitar estos pasos?



Observando las tasas, y el EXPLAIN PLAN de la consulta presentada se tiene que:

- La eficiencia de la consulta es bastante pobre.

- Se procesaron más de 4 millones de filas en el FULL TABLE SCAN de la tabla clientes. (en el ejemplo, esta tabla solo tiene 5150 filas), por lo que nos indica que este SCAN ha ocurrido más de una vez. Observando el EXPLAIN PLAN nos damos cuenta que por cada fila en ‘empleados’ se realizó el SCAN: (800 * 5150 = 4.12 millones).



Para corregir esto, se podría utilizar un índice en esta tabla, o redefinir la consulta de manera que sea más eficiente. Se opta por redefinir la consulta así:

SELECT e.apellido, e.nombre, e.fecha_nacimiento FROM empleados e, clientes c WHERE e.apellido = apellido_contacto AND e.nombre = c.apellido_nombre AND e.fecha_nacimiento = c.fecha_nacimientoORDER BY e.apellido, e.nombre;

Se ha utilizado un JOIN, que es más eficiente que el EXISTS, observemos ahora la salida del TKPROF



call count cpu elapsed disk query current rows--------- ------- ------ ------- ------ ------ -------- ------Parse 1 0 0.12 0 0 0 0Execute 2 0 0.96 0 0 1 0Fetch 11 0 9.82 278 364 370 151--------- ------- ------ ------- ------ ------ -------- ------Total 14 0 10.9 278 364 371 151

Misses in library cache during parse: 0Optimizer Hint: RULE

Rows Execution Plan------ --------------------------------------------- 0 SELECT STATEMENT 151 SORT (ORDER BY) 151 MERGE JOIN 5151 SORT (JOIN) 5151 TABLE ACCESS FULL OF 'CLIENTES' 800 SORT (JOIN) 800 TABLE ACCESS FULL OF 'EMPLEADOS'



Si se observa detenidamente los resultados, ahora solo se hace un TABLE SCAN por cada tabla y la tasa de bloques a fila ( (f + g ) / h) ha bajado a 4.8 (antes 1420). Aunque la tasa de lecturas de disco a lecturas lógicas (k / ( f + g )) también redujo su valor, se muestra que aun hay espacio para mejorarla.

Es obvio que este ejemplo se definió para que los resultados de las salidas fueran bastante visibles y se observara detenidamente el proceso de optimización

Otra forma de obtener el EXPLAIN PLAN y un reporte alternativo de estadísticas al ya presentado, es mediante el uso en SQL*Plus del comando:

SET AUTOTRACE ON

Supongamos la consulta:

SELECT * FROM emp;

La salida que se muestra en SQL*Plus es:


Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=4

Bytes=80) 1 0 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=4 Bytes=80)

Statistics---------------------------------------------------------- 0 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 656 bytes sent via SQL*Net to client 496 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 4 rows processed

explain plan ¿cómo obtener el explain plan? aunque el proceso mostrado es simple, es recomendable...

Documents