Explain PlanLa intención de este post, es brindar un panorama general sobre EXPLAIN PLAN, y aunque sea breve, espero

que sirva como punto de partida para aquellos que no están familiarizados con el uso de este comando, y que

brinde las consideraciones más globales para obtener planes de ejecución viables.

El optimizador de Oracle crea un query plan por cada sentencia SQL ya sean:

SELECT

Comandos DML: INSERT, DELETE, UPDATE, MERGE

CREATE TABLES AS…

CREATE INDEX …

ALTER INDEX… REBUILD

El query plan es el método elegido por el optimizador como el de mejor performance para ejecutar dicha

sentencia. El comando EXPLAIN PLAN simplemente registra una descripción legible de un query plan en

una tabla llamada TABLE PLAN que residirá en el esquema del usuario que lo ejecute. Hay que tener

presente que EXPLAIN PLAN “adivina” cual sería el query plan que Oracle va a usar para ejecutar la

sentencia, pero para ver cual es realmente el plan que se esta usando (obviamente en consultas ya ejecutadas)

hay que consultar la vista dinámica V$SQL_PLAN.

EXPLAIN PLAN no ejecuta la consulta. Entre la información que brinda esta la secuencia en la que se

acceden a las tablas, el costo estimativo del plan y de cada uno de sus pasos, estimaciones de I/O, el espacio

temporal usado para ordenamientos, la cantidad de filas procesadas y la cantidad de bytes empleados, si usa o

no índices para acceder a los datos, el método de acceso a las tablas, los métodos de joins, operaciones de

filtrado y ordenamiento, información de procesamiento en paralelo, concatenación, etc.

El optimizador no siempre elige el plan adecuado. Ante problemas de rendimiento con aplicaciones de bases

de datos se puede influir en la elección del plan de ejecución escribiendo la sentencia SQL de diferentes

maneras, usando HINTS, y probando diferentes escenarios de indexación intentando influir en el método que

elige la base de datos para recopilar los datos.

El query plan puede variar o no. La optimización empleada (reglas o costos) son las que determinan como

Oracle ejecuta las sentencias. Tomando la optimizacion basada en costos, los planes de ejecución son elegidos

en base a la metadata de los datos que se consultan (ver la sección “Para tener en cuenta“); por lo que el plan

que Oracle utiliza al ejecutar una sentencia SQL puede no ser el mismo en momentos distintos, ya sea porque

cambia el modo del optimizador, o las estadísticas o ciertos recursos ya no están disponibles en tiempo de

ejecución. Por otro lado, se puede mencionar el uso de bind variables en querys que se ejecutan de forma

frecuente, en los que Oracle no generará un plan en tiempo de ejecución, sino que se basará en un plan que ya

halla sido generado y almacenado en la Shared Pool. En este caso el plan de ejecución sera adecuado para las

consultas que devuelvan pocos valores, por ejemplo, e inadecuado para aquellas que tengan una cardinalidad

considerablemente mayor, derivando problemas de performance por uso de CPU excesivo, I/O innecesarios,

mal uso de indices, etc. En este caso, una posible solución es deshabilitar el uso de bind variables, pero por lo

general, como se menciona anteriormente las soluciones mas comunes son rediseñar la consulta y adecuar el

uso de índices.

Si al ajustar consultas no se produce un cambio de plan, puede ser necesario hacer ejecutar Alter System flush

shared_pool; Esto hará que Oracle vuelva a analizar cada consulta y que generar nuevamente los planes sobre

la marcha. Esto no debe realizarse a la ligera, ya que puede afectar dramaticamente el rendimiento en corto

plazo.

Para tener en cuenta

La optimización basada en reglas practicamente no es soportada desde 10g. El uso de la optimización

basada en costos requiere de estadisticas actualizadas (en todas las tablas e índices) para una selección

adecuada del plan de ejecución.

Las estadísticas pueden ser copiadas entre bases de datos al usar expdp e impdp.

Diferentes plataformas y configuraciones, ya sean a nivel de Sistema Operativo o de Base de Datos

(por ejemplo el número de CPUs, uso de RAID o los parametros de la base de datos como

SORT_AREA_SIZE y HASH_AREA_SIZE.) pueden influenciar en que el uso de los planes de

ejecución sea distinto.

Crear y visualizar planes de ejecuciónEl script $ORACLE_HOME/rdbms/admin/utlxplan.sql permite crear la tabla PLAN_TABLE. Los scripts

utlxpls.sql y utlxplp.sql son para ejecuciones de sentencias en serie y en paralelo (para este ultimo caso ver

la columna OTHER_TAG), y se emplean mediante el package DBMS_XPLAN. En windows los scripts se

encuentran en ORACLE_HOME\rdbms\admin.

Para ejecutar EXPLAIN PLAN la sentencia básica es:

view source print ? 1.EXPLAIN PLAN 2.FOR3.select * from some_table where id_name like 'C%';

Si se desea asignarle un id a la sentencia para poder identificarla y emplear otra tabla la sintaxis sería:

view source print ? 1.EXPLAIN PLAN 2.[ SET STATEMENT_ID = 'text' ] 3.[ INTO [esquema.]tabla@dblink ] 4.FOR5.sentencia;

Identificar las sentencias es recomendado ya que con cada ejecucion de explain plan se mantiene los registros

anteriores, especialmente si se usa una misma tabla por varias personas o sesiones.

Herramientas como Toad o SQL Developer tienen integrado en su entorno gráfico la posibilidad de ver el

plan de ejecución.

Para visualizar los planes que estamos registrando en la tabla PLAN_TABLE sin herramientas gráficas,

podemos emplear:

view source print ? 1.select * from table (DBMS_XPLAN.DISPLAY);

para obtener una salida sencilla o mas reducida podemos ejecutar:

view source print ? 1.SELECT    SUBSTR (LPAD(' ', LEVEL-1) || OPERATION || ' (' || OPTIONS || ')',1,30 ) "OPERACION",    OBJECT_NAME "OBJETO"2.FROM PLAN_TABLE  START WITH ID = 0  CONNECT BY PRIOR ID=PARENT_ID;

o bien,

view source print ? 1.SELECT2.operation ||' '||options||' on '||object_name "Query"3.,cost "Cost"4.,cardinality "Rows"5.,bytes "Bytes"6.FROM plan_table 7.WHERE statement_id = 'prueba' ORDER BY id;

siendo opcional el WHERE, dependiendo si se uso o no un id para la sentencia.