Optimizacin de consultas sql de Oracle

A continuacin se presenta un resumen del contenido que se expone en los cursos

talleres impartidos por Ricardo Martnez para la optimizacin de consultas en bases de
datos de Oracle. Para ms informacin de los prximos eventos visite el siguiente
enlace:
www.blitzhive.com/Conferencias-y-eventos/

Optimizar sentencias en Oracle tiene como meta mejorar la ejecucin de una

instruccin SQL. Considerando la mejor va de ejecucin de la instruccin la
que tenga el coste ms bajo entre todas las vas candidatas consideradas.
Teniendo en cuenta el clculo de los costos de los factores de ejecucin de la
consulta. El mejor mtodo de ejecucin depende de las condiciones,
incluyendo la escritura de la consulta, el tamao del conjunto de datos, el
diseo de los datos, y la existencia de estructuras que faciliten el acceso a la
informacin.
La optimizacin determina el mejor plan para una instruccin SQL mediante el
examen de mtodos con accesos mltiples, tales como exploraciones de tablas
e ndices as como diferentes uniones y bucles anidados.
La optimizacin en Oracle se debe basar en principios bsicos para la
resolucin de problemas y su posible escalabilidad. Usando un mtodo
enfocado en las estructuras simples que se aplicarn a consultas de un posible
tamao mayor.
Tenemos prioridad en optimizar las consultas con un gran tiempo de ejecucin
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 ms utilizadas deben encapsularse para ser usadas en
procedimientos almacenados. De esta manera slo analizaremos y
compilaremos la consulta una sola vez, reduciendo considerablemente la
ralentizacin de la base de datos.
Las optimizaciones pueden ser basadas en reglas (rule) o basadas en costes
(choose). Las primeras son del tipo esttico y responde de la misma manera a
diferentes variables de ejecucin. Las segundas actan de una manera u otra
segn determinados factores, como el nmero de usuarios conectados, el
estado de la base de datos o la carga actual de datos.

Vas de ejecucin
Determinar una va o plan especfico para optimizar el coste en la ejecucin 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 ejecucin elegido es el
mejor ante un eventual cambio en el tamao 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 opcin es por reglas, ya que
ests son inmediatas y la resolucin por costes tarda ms.

Optimizaciones adaptativas
En determinados casos las consultas formarn parte de funciones las cuales
cambiarn su mtodo de ejecucin segn el tipo de datos y las variables
introducidas.

Optimizacin en consultas
Antes de empezar recuerde que:
Una gran parte de las acciones de optimizacin de consultas se realizarn
sobre consultas SELECT, siendo las mismas las ms pesadas en trminos de
uso de tiempos.
Los mtodos aplicados a continuacin sern 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
ejecucin para las consultas de insercin, borrado y actualizacin. Pero no as
de obtencin de datos.

Resumen de diferentes mtodos que se vern en los cursostalleres para la optimizacin de consultas SQL en bases de
datos Oracle.
Smbolos operacionales
Operadores de Igualdad y Relacionales <,>,=,! . Muy recurrentes a la hora de
obtener filas especficas a modo de filtros en el WHERE. Aunque a la hora de
aplicarlos debemos saber un poco cmo 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.

Smbolo % Remainder operator (carta en blanco)

Siempre que despus de LIKE se pueda evitar usar el smbolo % 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 bsquedas por filtrados
positivos. Tambin para el smbolo !

Evitar el uso de COUNT()

En la mayora 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

Cursores y Subconsultas
Los cursores y subconsultas tambin son igualmente evitables al mximo en
cualquiera de los casos ralentizarn las consultas.

Evitar GROUP BY
Otra clusula que debemos intentar no usar, sobre todo en consultas que
contengan JOIN a tablas en las que no se aplican funciones de agregacin
como MIN, MAX o SUM. En determinados casos se podr usar DISTINCT con
idnticos resultados.

Cuando usar ROWNUM

Recordemos que podemos acortar el nmero de resultados obtenidos mediante
la clasula ROWNUM, muy til para consultas de prueba o para comparaciones
de variables.

Evitar HAVING
HAVING es una clusula a esquivar en los casos que se puede usar WHERE.
Por ejemplo cuando tenemos funciones de agregacin.

EXISTS e IN
IN suele ser ms lento, pero es ms eficiente cuando los criterios de filtro se
encuentran en una subconsulta, por el contrario EXISTS es ms eficiente
cuando los criterios del filtrado se encuentran en la consulta principal.

EXISTS prioridad sobre DISCTINCT

Se debe usar la clusula 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.

LIKE antes que SUBSTR

Si estamos usando ndices LIKE es ms rpido, 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 aritmticas

Evitemos sobrecargar Oracle con operaciones aritmticas 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 optimizacin adaptativa de la consulta.
Tambin mientras usamos el optimizador de Oracle. Esta herramienta de
Oracle trabaja con estadsticas que no estn actualizadas en tiempo real. Los
HINT ayudan a la optimizacin de las consultas aplicando sugerencias a la
hora de extraer los datos.
Prximas charlas, curos y talleres para la optimizacin de Oracle en:
http://blitzhive.com/Programacion/index.php/Optimizacin-de-Oracle/

Autor: Ricardo Martnez Romero

Contactos personales: rmartinseo@blitzhive.com

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