Nvidal’s Blog

Just another WordPress.com weblog

SQL tunning

SQL Tunning (optimización)

El objetivo de tunning es optimizar las sentencias SQL para un mejor plan de ejecución y evitar la utilización innecesaria de memoria y CPU.

El motor de Oracle tiene dos modos de operación, basado en costo (COST) o regla (RULE).

Reglas: Esta es la primera y más vieja forma de optimización. Bajo la optimización de regla Oracle busca a través del diccionario de datos la forma de determinar la forma más efectiva para realizar una búsqueda de una sentencia SQL.

Costo: La ejecución de una sentencia se basa en estadísticas, es necesario que las tablas estén analizadas lo mas reciente posible para obtener el mejor resultado. En este modo el parse o tren de ejecución es totalmente controlado por el motor de Oracle basado en las estadísticas generadas por el ANALYZE. La única forma de alterarlo es utilizando los HINTS.

Podemos examinar el comportamiento de una sentencia SQL analizando su plan de ejecución:

·         con la sentencia EXPLAIN PLAN

·         con trazas TRACE

Para optimizar las sentencias SQL podemos:

·         Crear índices adecuados y fomentar su uso (CREATE INDEX).

·         Aplicar HINTS para modificar o influenciar las decisiones del optimizador (COST).

·         Actualizar estadísticas periódicamente (ANALYZE). (COST)

·         Cuidar la programación.

En particular debemos prestar atención las sentencias SELECT que son más dadas a la complejidad.

 

Indices

 Respecto a los índices debemos tener en cuenta:

·         Crear índices sobre columnas lo más selectivas posibles (aquellas que reducen al máximo el espacio de búsqueda). Para determinar la selectividad de una columna debemos basarnos en el tipo de información que tiene la columna, mientras más información distinta hayan más selectiva es la misma.

·         En el caso de los índices compuestos, el orden en el que se declaran estas columnas deberá ser de la más selectiva a la menos selectiva (siempre que sea posible).

Programación

Respecto a la programación:

·         Limitar los accesos a tablas remotas.

·         Utilizar la cláusula UNION ALL en lugar de UNION siempre que sea posible.

·         Evitar el uso de llamadas a funciones PL/SQL en sentencias SQL.

·         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.).

·         Considerar que hay distintas opciones para obtener el mismo resultado.

·         El orden de las tablas en el Join puede ser importante.

·         Se deben optimizar tambien las subconsultas.

·         Considerar en algunos casos alternativas al Join (consultas anidadas, cláusula exists subconsulta , outer-join etc…).

·         Revisar las consultas periódicamente, pueden no ser ya optimas debido al constante cambio en el tamaño de las tablas, la distribución de los valores, el esquema etc….

·         Gestión 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 después 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 tamaño de las tablas involucradas puede resultar conveniente hacerlo de un modo u otro. Debemos tener en cuenta que, si una vista contiene una operación de conjunto (GROUP BY, SUM, COUNT o DISTINCT), no podrá ser integrada en la consulta.

·         Considerar el uso de las bind variables: Las sentencias pueden recoger los parámetros por valor (where salario>1000) o una vez compilada la sentencia haciendo uso de Bind Variables (where salario>:b1). La ventaja de la segunda opción es que Oracle compila una única vez la sentencia y reutiliza el código compilado para cada uno de los valores para los parámetros. 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 operación), 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.

abril 23, 2009 - Posted by | Database, Oracle, Tecnologia

Aún no hay comentarios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: