Optimizacion Consultas3

EXPLAIN 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.
EXPLAIN PLAN
Uso de un hint,
se verán posteriormente…
Podemos observar que los resultados obtenidos con esta

herramienta, son más amigables que los obtenidos mediante
SQL*Plus.
EXPLAIN PLAN
¿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:
EXPLAIN PLAN
Supongamos la consulta:
SELECT nombre, ciudad, departamento

FROM compania
WHERE ciudad = 'medellin'
AND departamento = 'antioquia';
EXPLAIN PLAN
Un plan de ejecución posible, podría ser el siguiente:
query_plan
--------------------------------------------
TABLE ACCES COMPANIA BY ROWID
AND-EQUAL
INDEX RANGE SCAN COMPANIA$CIUDAD
INDEX RANGE SCAN COMPANIA$DEPARTAMENTO
EXPLAIN PLAN
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
EXPLAIN PLAN
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
EXPLAIN PLAN
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
EXPLAIN PLAN
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:
Sin embargo, esta instrucción hace parte, o mejor dicho, se
ejecuta de manera conjunta con la instrucción:
EXPLAIN PLAN
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:

EXPLAIN PLAN
Luego de haber entendido lo anterior, los pasos en los que se

ejecutará la consulta son:
SELECT STATEMENT
4 SORT ORDER BY
3 NESTED LOOPS
1 TABLE ACCESS FULL CLIENTE
2 TABLE ACCESS BY ROWID EMPLEADOS
Miremos ahora un último ejemplo:

EXPLAIN PLAN
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
EXPLAIN PLAN
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 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 TKPROF
SQL 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

SQL TRACE Y TKPROF
SQL TRACE
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:
SQL TRACE Y TKPROF
SQL TRACE
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 TKPROF
Pasos 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 TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
1. 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 TKPROF
2. 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 TKPROF
2. 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 TKPROF
2. 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_$process
WHERE 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 TKPROF
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 TKPROF
trace_file Es el nombre del archivo generado por

SQL_TRACE
Output_file Es el nombre del archivo en el cual

quedará la información relevante
explain=username/passwor Especifica la conexión, la cual será
d 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).
SQL TRACE Y TKPROF
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.
SQL TRACE Y TKPROF
prs Ordena sobre valores en cnt Ordena sobre el número de llamadas
el momento de parsing.
exe Ordena sobre valores cpu Ordena por el consumo de CPU.
durante llamadas de
ejecución
fch Ordena sobre valores ela Ordena sobre tiempo transcurrido
durante llamadas a fetch.
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.
SQL TRACE Y TKPROF
4. 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
SQL TRACE Y TKPROF
• 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.
SQL TRACE Y TKPROF
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 TKPROF
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 TKPROF
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
SQL TRACE Y 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.
SQL TRACE Y TKPROF
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 TKPROF
(Interpretación los resultados)
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.
SQL TRACE Y TKPROF
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.
SQL TRACE Y TKPROF
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

SQL TRACE Y TKPROF
--------- ------- ------ ------- ------ ------ -------- ------
Parse 1 0 0.43 0 0 0 0
Execute 1 0 0.00 0 0 0 0
Fetch 11 0 323.74 204161 212083 2400 151
--------- ------- ------ ------- ------ ------ -------- ------
Total 13 0 324.17 204161 212083 2400 151
Misses in library cache during parse: 0

Optimizer 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'
SQL TRACE Y TKPROF
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 13.73
valor, mejor
k / (f+g) Menos de 10 95
SQL TRACE Y TKPROF
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?
SQL TRACE Y TKPROF
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).
SQL TRACE Y TKPROF
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_nacimiento
ORDER BY e.apellido, e.nombre;
Se ha utilizado un JOIN, que es más eficiente que el EXISTS,

observemos ahora la salida del TKPROF
SQL TRACE Y TKPROF
--------- ------- ------ ------- ------ ------ -------- ------
Parse 1 0 0.12 0 0 0 0
Execute 2 0 0.96 0 0 1 0
Fetch 11 0 9.82 278 364 370 151
--------- ------- ------ ------- ------ ------ -------- ------
Total 14 0 10.9 278 364 371 151
Misses in library cache during parse: 0

Optimizer 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'
SQL TRACE Y TKPROF
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
SQL TRACE Y TKPROF
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

Optimizacion Consultas3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Optimizacion Consultas3

Cargado por

Copyright:

Formatos disponibles

EXPLAIN PLAN

¿Cómo obtener el EXPLAIN PLAN?

Aunque el proceso mostrado es simple, es recomendable

Observemos a continuación un ejemplo de un EXPLAN PLAN

Podemos observar que los resultados obtenidos con esta

SELECT nombre, ciudad, departamento

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

Siguiendo las pautas observadas, se puede decir lo

3. Luego, se tiene que los resultados de ambas operaciones,

En algunas ocasiones, es necesario tener en cuenta otros

Observemos el siguiente plan de ejecución:

Una ruta de acceso puede estar compuesta por varios pasos

Por consiguiente al ser una operación conjunta, esta se

TABLE ACCESS BY ROWID EMPLEADOS

Luego de haber entendido lo anterior, los pasos en los que se

Miremos ahora un último ejemplo:

Como se observó, el EXPLAIN PLAN ofrece información

Costo - Cardinalidad - Bytes

• Aunque el EXPLAIN PLAN es una herramienta útil, posee

• Por ejemplo, no es posible determinar adecuadamente entre

• Con estas herramientas se puede obtener información

El SQL TRACE es una herramienta que permite rastrear las

En este archivo se guardan varios elementos interesantes,

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

Debido a que la salida del archivo de rastreo es

Esta herramienta de formateo (proporcionada también por

1. Habilitar el SQL TRACE, para instancias o sesiones

A continuación se explica en detalle cada uno de los pasos

Para Habilitar el rastreo de las sentencias de interés, se

ALTER SESSION SET SQL_TRACE = TRUE;

Para activarlo desde PL/SQL, se debe utilizar:

Teniendo ya habilitado el SQL TRACE, el siguiente paso es la búsqueda

Estos archivos de rastreo (.trc) son guardados generalmente en la ruta que

El nombre de los archivos generados por la herramienta, posee

Donde header es generalmente “ORA”, “Oracle_SID_ORA” u

Para hallar la ruta donde se encuentran los archivos

ALTER SYSTEM SET user_dump_dest = 'ruta_de_directorio';

Nota: el cambio de este parámetro debe realizarse antes de

tkprof trace_file output_file

TKPROF, se ejecuta por fuera del entorno de SQLPLUS, es

trace_file Es el nombre del archivo generado por

Output_file Es el nombre del archivo en el cual

Funciones del ordenamiento del TKPROF: Cada clave

A continuación se presenta una tabla completa acerca de

qry Ordena sobre lecturas consistentes.

cu Ordena sobre lecturas actuales

mis Ordenamiento sobre fallos en la

Estadísticas tabuladas: TKPROF lista las estadísticas en filas y

• La suma de las columnas de los totales de query y

• A continuación se presenta el significado de las

CPU: Tiempo total de CPU en segundos para las llamadas de parsing,

ELAPSED: Tiempo total transcurrido para todas las llamadas de parsing,

DISK: Número total de Bloques de datos leídos físicamente de los

QUERY: Número total de buffers traídos en modo consistente para todas

Rows: Las estadísticas acerca de las filas procesadas, aparecen

Para las sentencias SELECT, el número de filas retornadas

Los Resultados del TKPROF, se encuentran tabulados y cada

Observemos detenidamente la salida del TKPROF, y a través

Observemos con detenimiento los elementos de la salida del

Luego de observar los elementos importantes en la salida del

1. Bloques leídos (f+g) a filas procesadas (h). Esto indica de

2. Parsing (d), sobre ejecución (e). Idealmente, el conteo de

3. Filas traidas (i) sobre traidas (j) (Rows Fetched over