Optimización de consultas SQL en Oracle

1. Optimización de consultas sql de Oracle
A continuación se presenta un resumen del contenido que se expone en los cursos
talleres impartidos por Ricardo Martínez para la optimización de consultas en bases de
datos de Oracle. Para más información de los próximos eventos visite el siguiente
enlace:
www.blitzhive.com/Conferencias-y-eventos/
Optimizar sentencias en Oracle tiene como meta mejorar la ejecución de una
instrucción SQL. Considerando la mejor vía de ejecución de la instrucción la
que tenga el coste más bajo entre todas las vías candidatas consideradas.
Teniendo en cuenta el cálculo de los costos de los factores de ejecución de la
consulta. El mejor método de ejecución depende de las condiciones,
incluyendo la escritura de la consulta, el tamaño del conjunto de datos, el
diseño de los datos, y la existencia de estructuras que faciliten el acceso a la
información.
La optimización determina el mejor plan para una instrucción SQL mediante el
examen de métodos con accesos múltiples, tales como exploraciones de tablas
e índices así como diferentes uniones y bucles anidados.
La optimización en Oracle se debe basar en principios básicos para la
resolución de problemas y su posible escalabilidad. Usando un método
enfocado en las estructuras simples que se aplicarán a consultas de un posible
tamaño mayor.
Tenemos prioridad en optimizar las consultas con un gran tiempo de ejecución
o las que se deben ejecutar muchas veces.
Se debe considerar el cambio en el volumen de datos como uno de los
principales factores a la hora de aumentar los tiempos de respuesta de una
consulta.
Las consultas más utilizadas deben encapsularse para ser usadas en
procedimientos almacenados. De esta manera sólo analizaremos y
compilaremos la consulta una sola vez, reduciendo considerablemente la
ralentización de la base de datos.
Las optimizaciones pueden ser basadas en reglas (rule) o basadas en costes
(choose). Las primeras son del tipo estático y responde de la misma manera a
diferentes variables de ejecución. Las segundas actúan de una manera u otra
según determinados factores, como el número de usuarios conectados, el
estado de la base de datos o la carga actual de datos.

2. Vías de ejecución
Determinar una vía o plan específico para optimizar el coste en la ejecución de
una consulta de Oracle, será un proceso al que llegaremos tras haber
planteado los diferentes caminos o soluciones, haberlos ejecutado y
mejorarlos, y en un último paso aclarar si el plan de ejecución elegido es el
mejor ante un eventual cambio en el tamaño y tipo de los datos que
manejaremos.
En Oracle es recomendable realizar siempre las consultas basadas en costes,
sin embargo en determinados casos la mejor opción es por reglas, ya que
estás son inmediatas y la resolución por costes tarda más.
Optimizaciones adaptativas
En determinados casos las consultas formarán parte de funciones las cuales
cambiarán su método de ejecución según el tipo de datos y las variables
introducidas.
Optimización en consultas
Antes de empezar recuerde que:
Una gran parte de las acciones de optimización de consultas se realizarán
sobre consultas SELECT, siendo las mismas las más pesadas en términos de
uso de tiempos.
Los métodos aplicados a continuación serán normalmente pensando en una
base de datos con índices.
Las condiciones de una consulta globales así como las usadas en el filtrado de
JOIN se deben colocar en orden de índices. Los índices extras ralentizan la
ejecución para las consultas de inserción, borrado y actualización. Pero no así
de obtención de datos.

3. Resumen de diferentes métodos que se verán en los cursos-
talleres para la optimización de consultas SQL en bases de
datos Oracle.
Símbolos operacionales
Operadores de Igualdad y Relacionales <,>,=,! . Muy recurrentes a la hora de
obtener filas específicas a modo de filtros en el WHERE. Aunque a la hora de
aplicarlos debemos saber un poco cómo funcionan:
SELECT * FROM tabla WHERE columna > 11;
En la consulta de arriba Oracle debe buscar todos los valores mayores de 11
previamente localizando el valor 11. Al aplicar un = del modo columna >=12 el
DMBS no necesita localizar el 11.
Símbolo % Remainder operator (carta en blanco)
Siempre que después de LIKE se pueda evitar usar el símbolo % como prefijo
o rodeando la cadena se optimizará la consulta, es decir, siempre que el % se
deba utilizar es recomendable buscar la manera de ponerlo al final del string a
modo de sufijo.
En cualquier caso debemos siempre intentar evitar las condiciones con LIKE.
Evita el operador negativo NOT
Los filtrados por NOT suponen un costo mayor que las búsquedas por filtrados
positivos. También para el símbolo !
Evitar el uso de COUNT()
En la mayoría de los casos debemos usar EXISTS cuando se pueda, evitando
el uso COUNT(). En consultas con filtros del tipo WHERE o EXISTS incluso
con filtrados del tipo and rownum = 1

4. Cursores y Subconsultas
Los cursores y subconsultas también son igualmente evitables al máximo en
cualquiera de los casos ralentizarán las consultas.
Evitar GROUP BY
Otra cláusula que debemos intentar no usar, sobre todo en consultas que
contengan JOIN a tablas en las que no se aplican funciones de agregación
como MIN, MAX o SUM. En determinados casos se podrá usar DISTINCT con
idénticos resultados.
Cuando usar ROWNUM
Recordemos que podemos acortar el número de resultados obtenidos mediante
la claúsula ROWNUM, muy útil para consultas de prueba o para comparaciones
de variables.
Evitar HAVING
HAVING es una cláusula a esquivar en los casos que se puede usar WHERE.
Por ejemplo cuando tenemos funciones de agregación.
EXISTS e IN
IN suele ser más lento, pero es más eficiente cuando los criterios de filtro se
encuentran en una subconsulta, por el contrario EXISTS es más eficiente
cuando los criterios del filtrado se encuentran en la consulta principal.
EXISTS prioridad sobre DISCTINCT
Se debe usar la cláusula EXISTS cuando se usa JOIN en tablas con una o
varias relaciones. Recordemos que DISTINCT siempre ordena aunque no se
use ORDER BY.
UNION ALL en vez de UNION
Intenta aplicar siempre en una consulta UNION ALL en vez de UNION.

5. LIKE antes que SUBSTR
Si estamos usando índices LIKE es más rápido, sin índices puede que no haya
diferencia si usamos SUBSTR.
JOIN antes que IN
Como hemos dicho anteriormente debemos intentar usar lo menos posible IN.
En muchos casos JOIN es la única alternativa al IN .
Eviten operaciones aritméticas
Evitemos sobrecargar Oracle con operaciones aritméticas que podemos aplicar
directamente resueltas.
Usar: WHERE columna < 5;
En vez de: WHERE columna + 10 < 15;
Usar BETWEEN antes que WHERE en rangos de valores
Debemos usar BETWEEN siempre que hagamos un filtrador por rango de
valores, por ejemplo trabajando con fechas.
El uso de HINT
Aplica HINT(sugerencia) en las consultas que quieras mejorar, permitiendo a
Oracle hacer una optimización adaptativa de la consulta.
También mientras usamos el optimizador de Oracle. Esta herramienta de
Oracle trabaja con estadísticas que no están actualizadas en tiempo real. Los
HINT ayudan a la optimización de las consultas aplicando sugerencias a la
hora de extraer los datos.
Próximas charlas, curos y talleres para la optimización de Oracle en:
http://blitzhive.com/Programacion/index.php/Optimización-de-Oracle/
Autor: Ricardo Martínez Romero
Contactos personales: rmartinseo@blitzhive.com

6. Perfil linkedin:
https://es.linkedin.com/in/ricardo-mart%C3%ADnez-romero-04305711a
Web y Recursos:
www.blitzhive.com
www.fb.com/blitzhive
http://www.twitter.com/blitzhive