Tunning (optimizacin)

El objetivo de tunning es la puesta a punto (optimizacin) de las sentencias SQL, desde el punto de vista del tiempo de ejecucin y consumo de recursos.
Podemos examinar el comportamiento de una sentencia SQL analizando su plan de ejecucin: 1. con la sentencia EXPLAIN PLAN 2. con trazas TRACE Para optimizar las sentencias SQL podemos: 1. Crear indices adecuados y fomentar su uso (CREATE INDEX). 2. Aplicar HINTS para modificar o influenciar las decisiones del optimizador. 3. Actualizar estadsticas periodicamente (ANALYZE). 4. Usar clausulas STORAGE adecuada en la creacin de tablas (CREATE TABLE). 5. Usar EXPORT IMPORT. 6. Cuidar la programacin.

En particular debemos prestar atencin la sentencias SELECT que son ms dadas a la complejidad.

Indices
Respecto a los indices debemos tener en cuenta: 1. Crear ndices sobre columnas lo ms selectivas posibles (aquellas que reducen al mximo el espacio de bsqueda). 2. En el caso de los ndices compuestos, el orden en el que se declaran estas columnas deber ser de la ms selectiva a la menos selectiva (siempre que sea posible). 3. En algunos casos es conveniente sustituir ndices compuestos por varios ndices simples.

Programacin
Respecto a la programacin: 1. Limitar los accesos a tablas remotas. 2. Utilizar la clusula UNION ALL en lugar de UNION siempre que sea posible. 3. Evitar el uso de llamadas a funciones PL/SQL en sentencias SQL. 4. En cambio para determinados problemas, puede ser til el uso de procedimientos o funciones PL/SQL almacenados en la base de datos en lugar de una sentencia SQL (con un cursor p.ej.). 5. Considerar que hay distintas opciones para obtener el mismo resultado. 6. El orden de las tablas en el Join puede ser importante. 7. Se deben optimizar tambien las subconsultas. 8. Considerar en algunos casos alternativas al Join (consultas anidadas, clusula exists subconsulta , outer-join etc...). 9. Revisar las consultas periodicamente, pueden no se ya optimas debido al constante cambio en el tamao de las tablas, la distribucin de los valores, el esquema etc....

Adems
1. Gestin de las sentencias SQL que contienen vistas. Si una consulta contiene una vista, el optimizador tiene dos formas de actuar: resolver primero la vista y despus la consulta o integrar la vista en el texto de la misma. Si se resuelve primero la vista, el

resultado completo de la vista se determina en primer lugar y, el resto de las condiciones de la consulta se aplican como filtro. Dependiendo del tamao de las tablas involucradas puede resultar conveniente hacerlo de un modo u otro. Debemos tener en cuenta que, si una vista contiene una operacin de conjunto (GROUP BY, SUM, COUNT o DISTINCT), no podr ser integrada en la consulta. 2. Considerar el uso de las bind variables: Las sentencias pueden recoger los parmetros por valor (where salario>1000) o una vez compilada la sentencia haciendo uso de Bind Variables (where salario>:b1). La ventaja de la segunda opcin es que Oracle compila un nica vez la sentencia y reutiliza el cdigo compilado para cada uno de los valores para los parmetros. En este segundo caso, Oracle no puede calcular el grado de selectividad de una consulta y, en su lugar, aplica un grado de selectividad por defecto (asociado a cada tipo de operacin), lo cual puede dar lugar a decisiones "equivocadas". Por lo tanto, trabajando por costes es desaconsejable el uso de Bind Variables, salvo que trabajemos con sentencias que se van a ejecutar repetidas veces y que no ofrezcan muchas dudas en cuanto a los posibles planes de acceso que puede generar. 3. Utilizar las clusulas start with y connect by en el caso de consultas sobre datos relacionados por alguna relacin de herencia.

Algunos indices en Oracle

B-Tree Index Este es el tipo de ndices normal de Oracle, estos ndices son los que ms se utilizan, estn organizados en una estructura de rbol B y por lo general se utilizan para las llaves primarias de manera que se pueda hacer una bsqueda por llave ms rpido. Index Organized Tables Este es un tipo de ndice que naci con la versin 8 de Oracle y se utiliza por lo general para aplicaciones Web debido a que por lo general estas aplicaciones hacen bsquedas de un solo campo por medio de la llave primaria. Una IOT se define desde su creacin, agregando ORGANIZATION INDEX al final de la sentencia CREATE TABLE, y lo que hace es que los datos de la tabla se van guardando dentro del ndice, entonces cuando uno hace un SELECT los datos salen ordenados. Bitmap Index Los ndices de bitmap son muy recomendables en columnas en las cuales los valores ser repiten y representan una divisin en categoras, por ejemplo columnas como gnero, estado civil, etc. Tambin son muy recomendables cuando no cambian mucho, aunque sean muy variantes. Bitmap Join Index Este tipo de ndice, es muy til en tablas que estn relacionadas y hay muchas consultas que hacen Join de estas tablas, al igual que el bitmap index normal, solo se recomienda cuando la cardinalidad de los valores de la columna no es muy grande. Aparte este tipo de ndice, solamente se recomienda en Data Warehose porque son muy rpidos haciendo joins y devuelven los resultados en muy poco tiempo, por el contrario al hacer inserts y updates, tienen consecuencias en el rendimiento. Domain Index Estos ndices se utilizan para un dominio especializado, se utiliza mucho con dominios de texto o

imgenes, ya que en estos ndices se utilizan los indextype donde se puede especificar la implementacin. Cluster Index Este ndice consiste en unas tablas que comparten los mismos bloques de datos, utilizan un valor llamado clster key value que es el valor de las columnas involucradas para una fila en especfico. E clster key sirve para guardar juntas las filas que tengan el mismo valor y solo guarda una vez cada valor distinto. Hash Cluster Index Este ndice es muy parecido al anterior, pero se aplica una funcin de hash al cluster key para poder encontrar las dems filas con el mismo cluster key. Partitioned tables Cuando las tablas crecen mucho, acceder a ellas puede significar un bajo rendimiento, por eso surge el concepto de tablas particionadas que es dividir las tablas en partes independientes, se le puede sacar backup independientemente, el rendimiento de las consultas puede aumentar significativamente, y se pueden hacer transacciones paralelas en particiones diferentes. Es comn que las diferentes particiones, se coloquen en un tablespace diferente para optimizar aun ms el rendimiento. Function Based Index Este tipo de ndice es muy sencillo pero muy til y puede llegar a mejorar los tiempos de respuesta increblemente. Este ndice no es ms que un ndice B-Tree pero sobre una funcin, por ejemplo para las consultas dadas para este proyecto se utiliza mucho la funcin upper entonces cree un ndice B-Tree sobre la funcin upper del campo nombre, entonces en ndice estn los datos ya con la funcin upper aplicada. Patitioned Index Este es un ndice para el cual se definen particiones, exactamente igual que cuando se particiona una tabla, esto se hace con el objetivo de mejorar el tiempo de acceso a los datos cuando el ndice es demasiado grande.