Office Address

  • 123/A, Miranda City Prikano
  • +0989 7876 9865 9
  • info@example.com

Social List

¡No creerás lo fácil que es duplicar la velocidad de tus consultas en Oracle con este simple truco!

Lectura: 4 minutos

¿Alguna vez te has preguntado por qué ciertas consultas en Oracle tardan mucho más de lo esperado? Una de las mejores herramientas para diagnosticar y mejorar el rendimiento de tus queries es EXPLAIN PLAN.
En este post, te mostraré un ejemplo práctico para que veas cómo usarlo y, sobre todo, cómo interpretar el resultado para optimizar tus consultas.


1. ¿Qué es EXPLAIN PLAN?

En pocas palabras, EXPLAIN PLAN te muestra la estrategia (o plan de ejecución) que el optimizador de Oracle va a seguir para ejecutar tu consulta. Puede revelar detalles como:

  • Si se están usando índices o se realiza un Full Table Scan.
  • El tipo de join (Nested Loops, Hash Join, etc.) entre tablas.
  • El orden de las operaciones.
  • Costos estimados de CPU y E/S.

Con esta información, puedes diagnosticar potenciales problemas y guiar tus esfuerzos de optimización.


2. Preparación: la tabla PLAN_TABLE

Antes de usar EXPLAIN PLAN, Oracle necesita un lugar para almacenar temporalmente la información del plan de ejecución. Por defecto, se utiliza una tabla llamada PLAN_TABLE.

  • Si no existe en tu esquema, debes crearla con el script provisto por Oracle:
  • @?/rdbms/admin/utlxplan.sql

Generalmente, en versiones modernas de Oracle, esta tabla ya viene preconfigurada.


3. Ejemplo de EXPLAIN PLAN

Supongamos que tenemos una tabla EMPLOYEES con la siguiente estructura simplificada:

CREATE TABLE employees (
  employee_id   NUMBER PRIMARY KEY,
  first_name    VARCHAR2(50),
  last_name     VARCHAR2(50),
  department_id NUMBER,
  salary        NUMBER
);

Además, existe un índice primario sobre employee_id. Ahora imaginemos una consulta que filtre por departamento y rango de salarios:

EXPLAIN PLAN FOR
SELECT employee_id, first_name, last_name, salary
  FROM employees
 WHERE department_id = 10
   AND salary > 3000;

La instrucción anterior no ejecuta la consulta; solo genera el plan en la tabla PLAN_TABLE.


4. Visualizar y analizar el plan

Para ver el plan de ejecución, podemos usar el paquete DBMS_XPLAN. Un comando sencillo sería:

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE', NULL, 'TYPICAL'));

Ejemplo de salida (hipotética):

Plan hash value: 123456789

--------------------------------------------------------------------------

| Id  | Operation                   | Name           | Rows  | Bytes | Cost |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT            |                |  100  |  2000 |  15  |

|   1 |  TABLE ACCESS BY INDEX ROWID| EMPLOYEES      |  100  |  2000 |  10  |

|   2 |   INDEX RANGE SCAN          | EMPLOYEES_IDX1 |  100  |       |   5  |

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   1 - filter("SALARY">3000)

   2 - access("DEPARTMENT_ID"=10)

Veamos cómo interpretar cada sección:

  1. Id (0, 1, 2): Indica la jerarquía de pasos en el plan de ejecución.
  2. Operation:
    • SELECT STATEMENT: Operación de nivel superior.
    • TABLE ACCESS BY INDEX ROWID: Significa que Oracle primero localiza los ROWIDs a través de un índice y luego accede a las filas en la tabla.
    • INDEX RANGE SCAN: Oracle usa el índice para filtrar las filas según DEPARTMENT_ID = 10.
  3. Name:
    • EMPLOYEES: Es el nombre de la tabla.
    • EMPLOYEES_IDX1: Posiblemente sea el índice sobre department_id o uno que incluya esa columna.
  4. Rows / Bytes: Estimaciones de cuántas filas y cuántos bytes espera procesar Oracle en cada paso.
  5. Cost: Un valor relativo que Oracle utiliza para estimar qué tan “costosa” es la operación. No representa tiempo real, sino un indicador de comparaciones entre diferentes planes.
  6. Predicate Information: Muestra las condiciones de acceso y de filtro.
    • 2 – access(“DEPARTMENT_ID”=10): Significa que este criterio se usa para acceder al índice.
    • 1 – filter(“SALARY”>3000): El filtro sobre salary se aplica después de acceder mediante el índice.

5. Mejorando la consulta

En este ejemplo, Oracle ha podido usar un índice (INDEX RANGE SCAN) para acceder a las filas que cumplen department_id = 10, y luego aplica el filtro salary > 3000.

¿Podríamos mejorarlo?

  • Creación de un índice compuesto: Si esta consulta es muy frecuente y también filtra regularmente por salary, podríamos evaluar crear un índice compuesto sobre (department_id, salary), siempre y cuando tenga sentido para nuestra carga de trabajo y no perjudique otras operaciones (DML).
  • Estadísticas actualizadas: Asegúrate de que las estadísticas de la tabla e índices estén al día. En Oracle, esto se hace normalmente con:
  • EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => ‘TU_ESQUEMA’, TABNAME => ‘EMPLOYEES’);
  • Uso de Hints (no siempre recomendado): En caso de que Oracle no elija el plan que esperas, puedes probar con hints en tu SQL, p. ej.:
  • SELECT /*+ INDEX_COMBINE(employees employees_idx1 employees_idx2) */
  •        employee_id, first_name, last_name, salary
  •   FROM employees
  •  WHERE department_id = 10
  •    AND salary > 3000;

Sin embargo, lo ideal es dejar que el optimizador haga su trabajo, siempre que disponga de estadísticas correctas.


6. Pasos recomendados al analizar planes de ejecución

  1. Verifica las operaciones: ¿Está usando índices o hace Full Table Scan?
  2. Revisa los costos y filas estimadas: ¿Las filas estimadas son razonables o están muy desalineadas con la realidad? Eso podría indicar estadísticas obsoletas.
  3. Mira los predicados de acceso y filtro: Comprueba si tus columnas filtradas se utilizan de forma apropiada en el índice.
  4. Analiza el tipo de join (si hay más de una tabla): Nested Loops vs. Hash Joins. A veces un cambio de tipo de join mejora drásticamente la performance.
  5. Prueba y mide: Después de aplicar mejoras (índices, hints, reescritura de la consulta), vuelve a generar el EXPLAIN PLAN y verifica si el plan y el rendimiento son los esperados.

Utilizar EXPLAIN PLAN y analizar la salida con DBMS_XPLAN.DISPLAY es fundamental para diagnosticar y optimizar el rendimiento de tus consultas en Oracle. Al entender cómo el motor de base de datos accede a tus datos (vía índices o no), cómo junta tablas (Nested Loops, Hash Join…) y cómo aplica filtros, podrás identificar cuellos de botella y tomar acciones concretas para mejorar.

¡Ojalá este ejemplo te ayude a desmitificar EXPLAIN PLAN y a sacarle el máximo provecho a tus consultas!


¿Tienes alguna duda o sugerencia adicional?

¡No dudes en dejar un comentario! Cuéntanos cómo te va usando EXPLAIN PLAN y qué técnicas te han funcionado mejor para mejorar el rendimiento de tus queries.

Post a Comment

Your email address will not be published. Required fields are marked *