Optimizacion Consultas3

EXPLAIN PLAN
Cmo obtener el EXPLAIN PLAN?
Aunque el proceso mostrado es simple, es recomendable

utilizar herramientas de terceros las cuales facilitan aun
ms el trabajo. De hecho los planes de ejecucin generados
por terceros son ms ilustrativos que los generados por
Oracle.
Observemos a continuacin un ejemplo de un EXPLAN PLAN

generado por la herramienta JDeveloper de Oracle.
EXPLAIN PLAN
Uso de un hint,
se vern posteriormente
Podemos observar que los resultados obtenidos con esta

herramienta, son ms amigables que los obtenidos mediante
SQL*Plus.
EXPLAIN PLAN
Cmo leer el resultado del EXPLAIN PLAN?
Interpretar un plan de ejecucin, generalmente
requiere prctica. A pesar de esto, he aqu algunas pautas
generales que ayudan a interpretarlo.
1. Mientras ms indentado se encuentre un ruta de acceso
(access path), ms tempranamente se ejecuta.
2. Si dos pasos estn indentados a un mismo nivel, la
sentencia que se encuentre ms 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 ejecucin posible, podra 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 ejecucin:
1. Los accesos ms 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 informacin a la operacin AND_EQUAL.
4. AND_EQUAL a su vez, le entregar informacin a la
operacin TABLE ACCES COMPANIA BY ROWID
En algunas ocasiones, es necesario tener en cuenta otros

factores a la hora de interpretar un plan de ejecucin.
Observemos otro ejemplo
EXPLAIN PLAN
Observemos el siguiente plan de ejecucin:
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 ejecucin. Si observamos detenidamente el
resultado del EXPLAIN PLAN anterior y siguiendo las dos
pautas antes mencionadas se podra pensar que lo primero
que se ejecuta sera:
Sin embargo, esta instruccin hace parte, o mejor dicho, se
ejecuta de manera conjunta con la instruccin:
EXPLAIN PLAN
Por consiguiente al ser una operacin conjunta, esta se

tomar como un grupo, es decir, como una sola operacin.
1. Por lo tanto, la primera operacin a ejecutarse ser:
TABLE ACCESS FULL CLIENTE
Ya que se encuentra al mismo nivel que la operacin
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 informacin

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 vern a
continuacin) 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 ejecucin
Por ejemplo, no es posible determinar adecuadamente entre

dos planes de ejecucin, cual es ms eficiente, por ello se
puede acudir a otras dos herramientas: el SQL TRACE y
TKPROF
Con estas herramientas se puede obtener informacin

acerca de los recursos utilizados por el sistema (memoria,
CPU, etc.), tiempos de parsing, de recuperacin de
registros y de ejecucin
SQL TRACE Y TKPROF
SQL TRACE
El SQL TRACE es una herramienta que permite rastrear las

sentencias SQL ejecutadas dentro de una sesin o instancia,
almacenndolas dentro de un archivo especfico*.
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 extensin trc

SQL TRACE Y TKPROF
SQL TRACE
El archivo generado por el SQL TRACE es bsicamente,
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

prcticamente ilegible, se debe utilizar una herramienta de
formateo que toma como entrada, el archivo de rastreo y
va a generar un archivo con informacin comprensible y
fcil de interpretar que se espera conlleve a la toma de
buenas decisiones.
Esta herramienta de formateo (proporcionada tambin 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 inters
3. Usar el TKPROF para formatear
4. Interpretar los resultados
5. Optimizar la consulta y repetir el proceso si es necesario
A continuacin 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 inters, 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 inters
Teniendo ya habilitado el SQL TRACE, el siguiente paso es la bsqueda

del archivo generado por el mismo.
Estos archivos de rastreo (.trc) son guardados generalmente en la ruta que

tiene por defecto el parmetro de configuracin:
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 inters (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 inters (cont.)
Para encontrar un archivo de rastreo especfico, 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
guardarn los archivos de rastreo, se puede hacer lo siguiente:
ALTER SYSTEM SET user_dump_dest = 'ruta_de_directorio';
Nota: el cambio de este parmetro 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 lnea de comandos del sistema operativo. A
continuacin se muestran las diferentes opciones de los
parmetros de configuracin.
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 informacin relevante
explain=username/passwor Especifica la conexin, la cual ser
d utilizada para generar los planes de
ejecucin SQL.
Sort=(sort keys) Muestra las sentencias SQL en valores
descendientes de acuerdo a las claves
de ordenamiento elegidas, estas son
parsing (prc), ejecucin (.exe),
recuperacin (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 continuacin 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 nmero de llamadas
el momento de parsing.
exe Ordena sobre valores cpu Ordena por el consumo de CPU.
durante llamadas de
ejecucin
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 ejecucin.
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
ejecucin.
SQL TRACE Y TKPROF
4. Interpretacin los resultados.
Estadsticas tabuladas: TKPROF lista las estadsticas 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
ejecucin, chequeo de existencia de objetos, permisos etc.
EXECUTE: Este paso es la ejecucin 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
estadsticas 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 nmero total de bloques ledos.
A continuacin se presenta el significado de las

columnas.
SQL TRACE Y TKPROF
COUNT: Nmero de veces que a una sentencia se le realiz parsing,
ejecucin o fetching.
CPU: Tiempo total de CPU en segundos para las llamadas de parsing,

ejecucin y fetch.
ELAPSED: Tiempo total transcurrido para todas las llamadas de parsing,

fetch y ejecuciones de la sentencia.
DISK: Nmero total de Bloques de datos ledos fsicamente de los

archivos de datos en el disco para las llamadas de parsing, ejecucin y
fetch.
QUERY: Nmero total de buffers trados 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: Nmero total de buffers trados 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 estadsticas acerca de las filas procesadas, aparecen

en esta columna. El nmero total no incluye las filas
procesadas por las subconsultas de la sentencia SQL.
Para las sentencias SELECT, el nmero de filas retornadas

aparece para cada uno de los pasos de fetch. Para las sentencias
UPDATE, DELETE, e INSERT, el nmero de filas procesadas
aparece por cada paso de ejecucin.
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 travs

de este, se podr decidir acerca de la eficiencia de una
consulta SQL especfica. 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 ayudarn a determinar,
que consultas SQL necesitan ser optimizadas.
SQL TRACE Y TKPROF
Tasas de Importancia
1. Bloques ledos (f+g) a filas procesadas (h). Esto indica de

una manera general, el costo relativo de la consulta. Mientras
ms bloques tienen que ser accedidos en relacin a las filas
retornadas, la fila trada ser mucho ms costosa. Una relacin
similar se puede deducir sobre la tasa de bloques ledos sobre
ejecuciones (f+g)/e.
Tasas por encima de 10 o 20, pueden indicar alguna
posibilidad de optimizacin en este campo.
SQL TRACE Y TKPROF
(Interpretacin los resultados)
2. Parsing (d), sobre ejecucin (e). Idealmente, el conteo de

parsing debe ser cercano a uno. Si este valor es alto en
relacin 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 travs de arrays, lo que significa que
existe una buena oportunidad para optimizar.
SQL TRACE Y TKPROF
4. Lecturas de Disco (k) a lecturas lgicas. (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 ms de un 10%
Ahora se observar un ejemplo especfico que mostrar como

se puede utilizar el TKPROF como herramienta eficaz de
anlisis y optimizacin.
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:
- Cun eficiente es la sentencia? (indicado por tradas de

bloque por filas retornadas -- (f + g) / h ).
- Cmo se trajeron los datos? En otras palabras, qu significa

el plan de ejecucin?
- En qu pasos del plan de ejecucin se procesaron la mayor

cantidad de filas? cmo 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 ms 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 ms 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 podra utilizar un ndice en esta tabla, o

redefinir la consulta de manera que sea ms 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 ms 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 lgicas (k / ( f + g )) tambin
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 optimizacin
SQL TRACE Y TKPROF
Otra forma de obtener el EXPLAIN PLAN y

un reporte alternativo de estadsticas 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

Cmo obtener el EXPLAIN PLAN?

Aunque el proceso mostrado es simple, es recomendable

Observemos a continuacin un ejemplo de un EXPLAN PLAN

Podemos observar que los resultados obtenidos con esta

SELECT nombre, ciudad, departamento

Un plan de ejecucin posible, podra 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 ejecucin:

Una ruta de acceso puede estar compuesta por varios pasos

Por consiguiente al ser una operacin 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 informacin

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 informacin

El SQL TRACE es una herramienta que permite rastrear las

En este archivo se guardan varios elementos interesantes,

* Generalmente, estos archivos de rastreo tienen extensin trc

Debido a que la salida del archivo de rastreo es

Esta herramienta de formateo (proporcionada tambin por

1. Habilitar el SQL TRACE, para instancias o sesiones

A continuacin se explica en detalle cada uno de los pasos

Para Habilitar el rastreo de las sentencias de inters, 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 bsqueda

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 parmetro 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 continuacin se presenta una tabla completa acerca de

qry Ordena sobre lecturas consistentes.

cu Ordena sobre lecturas actuales

mis Ordenamiento sobre fallos en la

Estadsticas tabuladas: TKPROF lista las estadsticas en filas y

La suma de las columnas de los totales de query y

A continuacin 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: Nmero total de Bloques de datos ledos fsicamente de los

QUERY: Nmero total de buffers trados en modo consistente para todas

Rows: Las estadsticas acerca de las filas procesadas, aparecen

Para las sentencias SELECT, el nmero de filas retornadas

Los Resultados del TKPROF, se encuentran tabulados y cada

Observemos detenidamente la salida del TKPROF, y a travs

Observemos con detenimiento los elementos de la salida del

Luego de observar los elementos importantes en la salida del

1. Bloques ledos (f+g) a filas procesadas (h). Esto indica de

2. Parsing (d), sobre ejecucin (e). Idealmente, el conteo de

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