TUNNING ORACLE-SQL

JONATHAN MOISES PALOMINO VILCA

Contenido
ORACLE 11G TUNNING .............................................................................................................. 2 TIP 1: Siempre devolver SLO aquellas columnas que se requieren. ......................................... 4 TIP 2: Evitar operaciones matemticas si se puede utilizar una constante. ................................ 5 TIP 3: Evitar utilizar el LIKE sin % si se puede usar un = .................................................... 5 TIP 4: Evitar utilizar el IN para constantes............................................................................. 5 TIP 5: Utiliza los ndices sabiamente!. .................................................................................. 7 TIP 6: Evitar, en lo posible, utilizar expresiones o funciones sobre columnas indexadas ............. 7 TIP 7:Verificar la utilizacin de comparaciones con NULL en columnas indexadas...................... 7 TIP 8:Verificar la utilizacin de comparaciones con NOT , != LIKE en columnas indexadas........... 8 TIP 9: Cuando utilices OR, verifica que todos vayan por ndice, o ninguno lo har. ..................... 8 Tip 10: que Oracle reutiliza las consultas anteriores que estn almacenadas en el Shared Pool haciendo las consultas siguientes mucho ms rpidas.............................................................. 9 Tip 11: El orden se determina luego de retornar los registros. .................................................. 9 TIP 12: Verifica el parmetro OPTIMIZER_GOAL de tu sistema. Sistemas de ejecucin Batch utilizaran una aproximacin basada en Tasa de Transferencia, mientras que sistemas onLine se beneficiaran de una aproximacin basada en Mejor Tiempo de Respuesta. ............................11 TIP 13: Dependiendo de la meta del Optimizador, el plan de ejecucin se ir por ndices o por accesos completos a las tablas (Los ndices son ms rpidos, pero requieren ms recursos)......11 Tip 14: Pues no, no importa el orden, Oracle toma en cuenta las diferentes opciones y toma la ms ptima. .........................................................................................................................11 Tip 15: Para los ndices compuestos tampoco importa el orden de las condiciones del Where, siempre y cuando se utilice AND............................................................................................11 Tip 16: El plan de ejecucin depende en gran medida de la cantidad de registros que retorna la consulta, con lo cual, no esperes que el plan de ejecucion en DESARROLLO se comporte igual que en PRODUCCION. ...........................................................................................................11

ORACLE 11G TUNNING

Puntos a tomar en cuenta: 1) Realizar consultas sobre todas las columnas de una tabla, aunque slo utilizaremos una. 2) No utilizar los ndices de las tablas, o utilizarlos incorrectamente. (Un ndice es una estructura para mejorar el rendimiento de las bsquedas, al igual que un ndice de un libro te ayuda a encontrar un tema ms rpido.) 3) Mala utilizacin de sentencias como LIKE, BETWEEN, etc. Plan de ejecucin: Empecemos definiendo Qu es un Plan de Ejecucin?. El Plan de Ejecucin es la forma con la cual Oracle accede a los datos para resolver una consulta. (Si utilizamos PL/SQL Developer, accedemos al Plan de Ejecucin pulsando F5, en caso de toad necesitan darle al botn de la ambulancia)

Ahora bien, qu son esos nmeros Cost: es el costo relativo de la etapa de ejecucin de la sentencia. Las sentencias ms complejas se ejecutan por etapas. Cardinality: Es el nmero de Filas que espera obtener Oracle. Bytes: Es el tamao en Bytes de cada fila devuelta. Supongamos que, en realidad, no se requiere toda la tabla, sino el nmero de la poliza. De esta manera, si retornamos slo una columna (pliza), logramos rebajar el peso en Bytes de 31356 a 2457. Usar 13 veces menos memoria ya es un avance.

TIP 1: Siempre devolver SLO aquellas columnas que se requieren.

Ahora bien, lo siguiente que debemos evitar es retornar toda la tabla, en otras palabras, debemos definir cules registros, que cumplan cules condiciones son los que debemos retornar. Hay muchas cosas que tener en cuenta sobre lo que colocamos en la clausula WHERE de nuestra sentencia. Pero lo principal es entender cmo Oracle ejecuta una sentencia. Como ya mencionamos, cuando ejecutamos una sentencia, Oracle crea un Plan de Ejecucin para determinar sus pasos a seguir en la ejecucin. Un plan de ejecucin se debera leer de abajo hacia arriba y de derecha a izquierda. Si tomamos por ejemplo la siguiente sentencia y su plan de ejecucin:
select * from a1001390 A,a1001399 B where A.COD_CIA=B.COD_CIA AND A.TIP_DOCUM=B.TIP_DOCUM AND A.COD_DOCUM=B.COD_DOCUM;

HASH JOIN A1001390 ACCESS FULL A1001399 ACCESS FULL

Adems de esto, Oracle tiene un Optimizador que transforma algunas sentencias en cosas ms simples para ejecutar. Por ejemplo: - Constantes: Si tenemos expresiones del tipo: importe>50000-24000/12 Oracle lo debe transformar en importe>48000

TIP 2: Evitar operaciones matemticas si se puede utilizar una constante.

- LIKE: Si tenemos una consulta que utiliza LIKE, pero no le colocamos %: full_name LIKE Lucas, Oracle lo sustituye por full_name=Lucas

TIP 3: Evitar utilizar el LIKE sin % si se puede usar un =

- IN: Si tenemos una consulta con IN de constantes, Oracle lo transforma en OR. Por ejemplo: full_name IN (Luz , Lucas, Mara) se transforma en full_name=Luz OR full_name=Lucas OR full_name=Mara

TIP 4: Evitar utilizar el IN para constantes.

Las modificaciones con IN desaprovechan el ndice y no ayuda en nada en la optimizacin. Evita usarlos si es posible. Tomemos este ejemplo:
select * from a1001331 WHERE NOM_LOCALIDAD='LIMA';

Tenemos una consulta bastante sencilla y de acuerdo al plan de ejecucin vemos que est realizando un TABLE ACCESS FULL para obtener el resultado, es decir, que est mirando directamente en todos los registros de la tabla para encontrar lo que le pedimos. La idea es evitar los TABLE ACCESS FULL. Si este campo tuviera ndices seria como se muestra.

No podemos abusar de los ndices. Al fin y al cabo un ndice es una estructura ms y no podemos colocar un ndice a todas las columnas o estaramos empeorando el rendimiento. Otra cosa a tener en cuenta al usar indices es que un ndice se actualiza al hacer un Insert, con lo cual, si tienes un proceso que realiza 20mil inserts en una tabla, se prudente y desactiva los indices antes y actvalos o regenralo al terminar. Ten siempre en una balanza lo que un ndice te puede ahorrar en un SELECT versus lo que te penaliza en los INSERTS, UPDATES y DELETES.

TIP 5: Utiliza los ndices sabiamente!.

Sin entrar en teora fastidiosa sobre cmo se crean los ndices, qu segmentos de memoria ocupan o si usar un B-tree o no Existen algunas consideraciones ms prcticas acerca de los ndices:

Cuando la columna indexada est dentro de una expresin o funcin, el ndice no se utiliza. Es decir, si tenemos un ndice sobre COD_RAMO se presentar esta diferencia al utilizar la columna con una funcin trunc:
select * FROM A2000030 WHERE COD_CIA=3 AND COD_RAMO=702;

select * FROM A2000030 WHERE COD_CIA=3 AND TRUNC(COD_RAMO)=301;

TIP 6: Evitar, en lo posible, utilizar expresiones o funciones sobre columnas indexadas

El ndice no ser utilizado cuando la columna indexada es comparada con NULL. Es decir, si la consulta incluye un Where Columna_x IS NULL, no ir por el ndice, aunque dicha columna lo tenga definido.

TIP 7:Verificar la utilizacin de comparaciones con NULL en columnas indexadas.

El ndice no ser utilizado si la columna indexada es comparada por diferencia (NOT o !=). Al igual que pasa con la comparacin a NULL, si usamos != o NOT tampoco ir por ndice.

TIP 8:Verificar la utilizacin de comparaciones con NOT , != LIKE en columnas indexadas.

El ndice slo se utiliza en un LIKE si el primer caracter es distinto de %. Veamos el siguiente ejemplo
select * FROM A2000030 WHERE COD_CIA=3 AND NUM_POLIZA LIKE '%70%';

select * FROM A2000030 WHERE COD_CIA=3 AND NUM_POLIZA LIKE '70%';

En el primer caso, se hace uso del ndice, si solicitamos todas aquellas descripciones que comiencen por 70, pero si pedimos todas las descripciones que contengan 70, el ndice no es tan eficiente

TIP 9: Cuando utilices OR, verifica que todos vayan por ndice, o ninguno lo har.
Espero que estos prcticos Tips os ayuden a identificar qu puede estar fallando en las consultas demasiado pesadas y puedan optimizar vuestros sistemas. Fases de la ejecucin de una consulta en Oracle:

Intentar hacer un resumen del proceso:

Parse: En esta primera fase de Parse o Anlisis Oracle verifica la sintaxis y la semntica de la consulta adems de los privilegios, es decir, verifica si hemos escrito bien la consulta y si los objetos son accesibles y existen. Luego de ello empieza un proceso bastante interesante. Oracle verifica si ha habido un Anlisis anterior de esta consulta. En este punto se manejan dos trminos Anlisis Suave (Soft Parsing) y Anlisis Duro (Hard Parsing). El primero se refiere a cuando Oracle encuentra una versin anterior del Anlisis y el segundo trmino se refiere a que no la ha encontrado y la debe construir. En esta fase se construye el plan de ejecucin de la consulta.

Tip 10: que Oracle reutiliza las consultas anteriores que estn almacenadas en el Shared Pool haciendo las consultas siguientes mucho ms rpidas.
Bind: En la fase de Enlace o Bind Oracle busca en la consulta referencias para enlazar a variables y asigna, o reasigna el valor a cada variable. Execute: Durante la fase de Ejecucin se identifican los pasos que el servidor debe seguir e identifica los registros de data requeridos del buffer de data. Si todo va bien y no se reporta ningn error, se devuelve el set de datos. Durante esta fase tambin se maneja un posible commit o rollback, pero no nos meteremos en ello ahora. Fetch: Durante esta fase, Oracle retorna los valores, los ordena si se necesita y los hace accesibles para nuestro cliente.

Tip 11: El orden se determina luego de retornar los registros.

Una vez que hemos visto muy por encima las fases de ejecucin, hay un par de cosas que deberamos saber del optimizador de Oracle. El Optimizador hace todo su trabajo durante la fase de Anlisis (Parse). Evala la expresin y condiciones Transformacin de la declaracin Eleccin de la aproximacin para el optimizador Eleccin de las rutas de acceso Eleccin del orden de los Joins Eleccin del mtodo de los Joins

Los primeros dos pasos los hemos visto en los anteriores, el optimizador transforma sentencias complejas en cosas ms simples (operaciones matemticas que transforma en constantes, IN que transforma en OR, etc). En el tercer y cuarto paso, el Optimizador puede seleccionar irse por una aproximacin basada en Costo o una basada en Reglas para llegar a una Meta establecida. Esta eleccin depende del parmetro OPTIMIZER_GOAL que se encuentra en el fichero de inicializacin de Oracle (init.ora).

Por ejemplo: Si hemos establecido una meta por Costo enfocada en uso de recursos (parmetro ALL_ROWS), el optimizador utilizar FULL ACCESS TABLES, mientras que si colocamos FIRST_ROWS, meta por Costo enfocada en el tiempo de respuesta, el optimizador se ver ms inclinado al uso de ndices pues los ndices son un recurso ms que utiliza I/O (Lecturas y escrituras en el CPU).

TIP 12: Verifica el parmetro OPTIMIZER_GOAL de tu sistema. Sistemas de ejecucin Batch utilizaran una aproximacin basada en Tasa de Transferencia, mientras que sistemas onLine se beneficiaran de una aproximacin basada en Mejor Tiempo de Respuesta. TIP 13: Dependiendo de la meta del Optimizador, el plan de ejecucin se ir por ndices o por accesos completos a las tablas (Los ndices son ms rpidos, pero requieren ms recursos)
Volviendo a las Fases del Optimizador, el 5to lugar tenemos Eleccin del orden de los Joins. Para una sentencia que utilice varios Joins entre varias tablas, el optimizador selecciona cules tablas une primero y luego cuales une a ese resultado, etc. El orden lo determina realizando varios planes de ejecucin con varios ordenes y quedndose con el ms ptimo. En un post anterior qued abierta la duda de si importaba o no el orden en que hacemos los joins:

Tip 14: Pues no, no importa el orden, Oracle toma en cuenta las diferentes opciones y toma la ms ptima. Tip 15: Para los ndices compuestos tampoco importa el orden de las condiciones del Where, siempre y cuando se utilice AND.
Por ltimo el Optimizador pasa a la fase de Eleccin del mtodo de los Joins. En este paso, el optimizador estima el costo de cada mtodo y se inclina por el de menor coste. Se consideran estos tres factores:

Un nested loop join es ineficiente cuando trae una gran cantidad de filas (ms de 10000) as que puede inclinarse a rechazar este mtodo. Si estamos usando un mtodo basado en Costo, un hash join es ms efectivo cuando se trata de grandes cantidades de filas. Si estamos usando un mtodo basado en Reglas, un merge join es ms efectivo cuando se trata de grandes cantidades de filas.

Tip 16: El plan de ejecucin depende en gran medida de la cantidad de registros que retorna la consulta, con lo cual, no esperes que el plan de ejecucion en DESARROLLO se comporte igual que en PRODUCCION.