Oracle 11g Tunning

8/13/2019 Oracle 11g Tunning

1/12

TUNNING ORACLE-SQLJONATHAN MOISES PALOMINO VILCA


2/12

ContenidoORACLE 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 reutil iza 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 sebeneficiaran 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 lams 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 igualque en PRODUCCION. .................... ............................................ ...........................................11


3/12


4/12

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.


5/12

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

Ahora bien, lo s iguiente 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* froma1001390A,a1001399 B

where A.COD_CIA=B.COD_CIA

ANDA.TIP_DOCUM=B.TIP_DOCUM

ANDA.COD_DOCUM=B.COD_DOCUM;

HASH JOIN

A1001390ACCESS FULL

A1001399ACCESS FULL


6/12

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* froma1001331WHERE NOM_LOCALIDAD='LIMA';


7/12

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.


8/12

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 Existenalgunas 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* FROMA2000030 WHERE COD_CIA=3ANDCOD_RAMO=702;

select* FROMA2000030 WHERE COD_CIA=3ANDTRUNC(COD_RAMO)=301;

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

El ndice no ser utilizado cuando la columna indexada es comparada con NULL. Es decir, sila consulta incluye un Where Columna_x IS NULL, no ir por el ndice, aunque dicha columnalo 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.


9/12

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* FROMA2000030 WHERE COD_CIA=3ANDNUM_POLIZA LIKE '%70%';

select* FROMA2000030 WHERE COD_CIA=3ANDNUM_POLIZA LIKE '70%';

En el primer caso, se hace uso del ndice, si solicitamos todas aquellas descripcionesque comiencenpor 70, pero si pedimos todas las descripciones que contengan70, el ndiceno 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:
http://21red.es/wp-content/uploads/2012/06/fases.png


10/12

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 AnlisisDuro(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 consu lta 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


11/12

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 aproximacinbasada 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 quesi colocamos FIRST_ROWS, meta por Costo enfocada en el tiempo de respuesta, eloptimizador se ver ms inclinado al uso de ndices pues los ndices son un recurso msque utiliza I/O (Lecturas y escrituras en el CPU).
http://21red.es/wp-content/uploads/2012/07/optimizer_goal.jpg


12/12

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 porndices 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 estepaso, 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 cuandose 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.

Documents

Oracle 11g Tunning