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
¿Cómo leer el resultado del EXPLAIN PLAN?
Supongamos la consulta:
SELECT nombre, ciudad, departamento
FROM compania
WHERE ciudad = 'medellin'
AND departamento = 'antioquia';
EXPLAIN PLAN
¿Cómo leer el resultado del 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
¿Cómo leer el resultado del 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
¿Cómo leer el resultado del 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
¿Cómo leer el resultado del 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
¿Cómo leer el resultado del 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:
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
EXPLAIN PLAN
¿Cómo leer el resultado del 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:
TABLE ACCESS BY ROWID EMPLEADOS
INDEX RANGE SCAN EMPLEADO_NOMBRES_IDX
EXPLAIN PLAN
¿Cómo leer el resultado del EXPLAIN PLAN?
Luego de haber entendido lo anterior, los pasos en los que se
ejecutará la consulta son:
4
3
1
2
SELECT STATEMENT
SORT ORDER BY
NESTED LOOPS
TABLE ACCESS FULL CLIENTE
TABLE ACCESS BY ROWID EMPLEADOS
INDEX RANGE SCAN EMPLEADO_NOMBRES_IDX
Miremos ahora un último ejemplo:
EXPLAIN PLAN
¿Cómo leer el resultado del 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
Pasos a Seguir, a la hora de utilizar 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
Pasos a Seguir, a la hora de utilizar 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
Pasos a Seguir, a la hora de utilizar 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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
3. 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 TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
3. Usar el TKPROF para formatear
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
3. Usar el TKPROF para formatear
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
3. 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.
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
3. Usar el TKPROF para formatear
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
Pasos a Seguir, a la hora de utilizar 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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
4. Interpretación los resultados.
• 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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
4. Interpretación los resultados.
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
4. 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 TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
4. 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
SQL TRACE Y TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
4. Interpretación los resultados.
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
4. Interpretación los resultados.
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
Pasos 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.
SQL TRACE Y TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(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.
SQL TRACE Y TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
Supongamos que se tiene la siguiente consulta SQL:
SELECT
FROM
WHERE
e.apellido, e.nombre, e.fecha_nacimiento
empleados e
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
call
--------Parse
Execute
Fetch
--------Total
count
cpu
elapsed
------- ------ ------1
0
0.43
1
0
0.00
11
0
323.74
------- ------ ------13
0
324.17
disk query current
rows
------ ------ -------- -----0
0
0
0
0
0
0
0
204161 212083
2400
151
------ ------ -------- -----204161 212083
2400
151
Misses in library cache during parse:
Optimizer Hint: RULE
Rows
------0
800
800
801
4109475
0
Execution Plan
--------------------------------------------SELECT STATEMENT
FILTER
TABLE ACCESS (BY ROWID) OF 'EMPLEADOS‘
INDEX (RANGE SCAN) OF 'INDICE_EMPLEADOS_NOMAP'
TABLE ACCESS FULL OF 'CLIENTES'
SQL TRACE Y TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
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
SQL TRACE Y TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
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
FROM
WHERE
AND
AND
ORDER BY
e.apellido, e.nombre, e.fecha_nacimiento
empleados e, clientes c
e.apellido = apellido_contacto
e.nombre
= c.apellido_nombre
e.fecha_nacimiento = c.fecha_nacimiento
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
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
call
--------Parse
Execute
Fetch
--------Total
count
cpu
elapsed disk query current
rows
------- ------ ------- ------ ------ -------- -----1
0
0.12
0
0
0
0
2
0
0.96
0
0
1
0
11
0
9.82
278
364
370
151
------- ------ ------- ------ ------ -------- -----14
0
10.9
278
364
371
151
Misses in library cache during parse:
Optimizer Hint: RULE
Rows
-----0
151
151
5151
5151
800
800
0
Execution Plan
--------------------------------------------SELECT STATEMENT
SORT (ORDER BY)
MERGE JOIN
SORT (JOIN)
TABLE ACCESS FULL OF 'CLIENTES'
SORT (JOIN)
TABLE ACCESS FULL OF 'EMPLEADOS'
SQL TRACE Y TKPROF
Pasos a Seguir, a la hora de utilizar SQL TRACE y TKPROF
(Interpretación los resultados)
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
Descargar

EXPLAIN PLAN