Explain Plan

La intencin 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 estn familiarizados con el uso de este comando, y que brinde las consideraciones ms globales para obtener planes de ejecucin 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 mtodo elegido por el optimizador como el de mejor performance para ejecutar dicha sentencia. El comando EXPLAIN PLAN simplemente registra una descripcin 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 sera 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 dinmica V$SQL_PLAN. EXPLAIN PLAN no ejecuta la consulta. Entre la informacin 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 mtodo de acceso a las tablas, los mtodos de joins, operaciones de filtrado y ordenamiento, informacin de procesamiento en paralelo, concatenacin, etc. El optimizador no siempre elige el plan adecuado. Ante problemas de rendimiento con aplicaciones de bases de datos se puede influir en la eleccin del plan de ejecucin escribiendo la sentencia SQL de diferentes maneras, usando HINTS, y probando diferentes escenarios de indexacin intentando influir en el mtodo que elige la base de datos para recopilar los datos. El query plan puede variar o no. La optimizacin empleada (reglas o costos) son las que determinan como Oracle ejecuta las sentencias. Tomando la optimizacion basada en costos, los planes de ejecucin son elegidos en base a la metadata de los datos que se consultan (ver la seccin 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 estadsticas o ciertos recursos ya no estn disponibles en tiempo de ejecucin. 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 ejecucin, sino que se basar en un plan que ya halla sido generado y almacenado en la Shared Pool. En este caso el plan de ejecucin 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 solucin es deshabilitar el uso de bind variables, pero por lo general, como se menciona anteriormente las soluciones mas comunes son redisear 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 optimizacin basada en reglas practicamente no es soportada desde 10g. El uso de la optimizacin basada en costos requiere de estadisticas actualizadas (en todas las tablas e ndices) para una seleccin adecuada del plan de ejecucin. Las estadsticas 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 nmero 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 ejecucin sea distinto.

Crear y visualizar planes de ejecucin

El 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 bsica es: view sourceprint? 1.EXPLAIN PLAN 2.FOR 3.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 sera: view sourceprint? 1.EXPLAIN PLAN 2.[ SET STATEMENT_ID = 'text' ] 3.[ INTO [esquema.]tabla@dblink ] 4.FOR 5.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 grfico la posibilidad de ver el plan de ejecucin. Para visualizar los planes que estamos registrando en la tabla PLAN_TABLE sin herramientas grficas, podemos emplear: view sourceprint? 1.select * from table (DBMS_XPLAN.DISPLAY); para obtener una salida sencilla o mas reducida podemos ejecutar: view sourceprint? 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 sourceprint? 1.SELECT 2.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.