Optimizacion Select Oracle

Universidad de Crdoba
DESARROLLO DE APLICACIONES
Manual de Optimizacin Revisin 1.0
Servicio de Informtica Area de Sistemas Julio 1993
1.
Introduccin.
En este Manual se ha recopilado informacin relativa a la optimizacin de aplicaciones desarrolladas con ORACLE, desde el punto de vista del diseador y del programador. Aunque la referencia fundamental es Database Administrators Guide Version 6.0, incluimos ideas de otras fuentes (Manuales, Boletines Tcnicos, publicaciones independientes,...) detalladas en el Apndice A. Por otra parte, la experiencia adquirida en el desarrollo y explotacin de aplicaciones ORACLE ha sido clave para la confeccin de este Manual. Se supone un conocimiento medio de SQL. Referencias complementarias para el lector interesado en la implementacin que ORACLE ofrece de dicho lenguaje pueden encontrarse en la documentacin tcnica correspondiente. Hacemos notar que este Manual hace referencia a la versin 6.0 del gestor RDBMS de ORACLE. En la actualidad estamos evaluando la versin 7.0 de dicho gestor en el cual se han introducido numerosas modificaciones por lo que es de esperar una proxima revisin de este Manual.
Servicio de Informtica - Area de Sistemas

2.
Consideraciones generales.
1.
Introduccin.
Uno de los aspectos fundamentales a tener presente en buena parte de las etapas de diseo y desarrollo de un aplicacin es el del rendimiento futuro de la misma. Desde el momento mismo en que se elige una configuracin hardware y unas herramientas software para el desarrollo, los impactos sobre el rendimiento deben evaluarse cada vez que se tome una decisin de diseo y, en ltima instancia, durante toda la fase de codificacin. Una escasa planificacin en este terreno nos puede proporcionar una aplicacin poco eficiente lo que, con toda probabilidad, conducir a tomar medidas ad hoc muy costosas y de dudosa efectividad. En nuestro entorno se dispone de una herramienta, ORACLE, altamente parametrizable, lo que permite mejorar el rendimiento global de las aplicaciones. En menor medida, el sistema operativo UNIX permite al administrador adaptar su comportamiento a las necesidades especficas de un entorno de explotacin concreto. Un desajuste en cualquiera de estos dos aspectos repercutir, de inmediato, en el rendimiento de todas las aplicaciones. La monitorizacin y ajuste del gestor ORACLE y del sistema operativo es un tema muy complejo y no es nuestra intencin abordarlo en estas pginas dado su escaso inters general. Sin embargo, la optimizacin de aplicaciones, sobre todo en fases tempranas de desarrollo, es un tema de vital importancia para todos aquellos involucrados en la puesta a punto de una aplicacin. Este Manual intenta dar una visin amplia sobre los recursos disponibles para mejorar el rendimiento de las aplicaciones desde el punto de vista del diseador y, sobre todo, del programador. Algunas sern afirmaciones obvias fcilmente extrapolables a otros entornos. Sin embargo, la forma, a veces aparentemente caprichosa, de actuar que muestra el gestor ORACLE hace necesario que los desarrolladores dispongan de un conjunto claro de reglas que les permitan tomar decisiones fundadas.

Captulo
2 Consideraciones generales.
Por ltimo, y para animar al lector a evaluar en su justa medida la importancia del tema aqu tratado, diremos que ORACLE reconoce que en la optimizacin de un sistema construido con su gestor de bases de datos, aproximadamente el 70% de las mejoras de rendimiento se obtendrn actuando a nivel de aplicacin. Esperamos que estas pginas sean de utilidad a todos aquellos que estn embarcados en el desarrollo de una nueva aplicacin o en el mantenimiento de una existente.
1.
Diseo.
Las primeras apreciaciones sobre el rendimiento comienzan a discutirse en la fase de diseo. Es imprescindible conocer a fondo los datos antes de decidir la estructura fsica de la base de datos o de modificar una ya existente. La flexibilidad del modelo relacional hace que las posibilidades de implementar una idea sean virtualmente ilimitadas. Considerando los previsibles problemas de rendimiento, este nmero de soluciones posibles se limita de forma apreciable. En general, siguiendo las reglas usuales de normalizacin asociadas a la teora relacional, es posible obtener una base de datos con una estructura aceptable. Acogerse a una tcnica probada de anlisis ayuda a respetar unos criterios estrictos que usualmente conducen a un buen modelo de datos. En particular, ORACLE recomienda el modelo Entidad/Relacin. Una realizacin prctica de este modelo es el CASE*Method. ORACLE es categrica en sus afirmaciones respecto al cuidado necesario en la fase de anlisis: una buena codificacin no puede contrarrestar los efectos negativos de una base de datos pobremente diseada. En la fase final del anlisis debe estudiarse la posibilidad de desnormalizar algunas tablas de modo que se evite el uso excesivo de joins. En particular debe prestarse atencin a las tablas auxiliares que describen cdigos: muchas veces los cdigos no significan nada para el usuario final y puede ser ms rentable almacenar la descripcin completa para evitar el join, sobre todo si el rendimiento prima sobre consideraciones de espacio. En cualquier caso, hay que cuidar el nmero de campos definidos en cada tabla. Las tablas cargadas de descripciones (los campos numricos y tipo fecha no ocupan demasiado espacio) pueden

Captulo
influir negativamente en el rendimiento de la aplicacin. Aunque slo se deseen recuperar algunos de los campos, la lectura de una de estas tablas implica recuperar muchos bloques de disco dado que stos slo pueden acomodar unas pocas filas de datos. Otro aspecto fundamental al que a veces no se presta la suficiente atencin es el de la separacin de los entornos online y batch. En ORACLE: Building High Performance Online Systems (ver Apndice A), el autor define el concepto de transaccin no diseada (undesigned transaction) como aquella que realiza ms de 8 10 operaciones de entrada/salida. Muestra, adems, el efecto negativo que sobre el rendimiento de todo un sistema puede tener mezclar transacciones diseadas y no diseadas. Una norma bsica en cualquier sistema en explotacin es definir un entorno batch con un horario de ejecucin fuera de horas de oficina en el que se incluirn el mayor nmero posible de las transacciones no diseadas que tengan que implementarse. El anlisis debe identificar claramente tales transacciones para que el usuario final no pueda desencadenarlas libremente sino por solicitud previa.
2.
Codificacin.
Independientemente de la herramienta utilizada, al final, cualquier programa queda reducido a sentencias SQL. Dado que este lenguaje es muy flexible, es posible alcanzar los mismos resultados escribiendo la sentencia de distintas formas. ORACLE incorpora un optimizador que decide el camino a seguir para recuperar o modificar los datos. Este optimizador est basado en reglas independientes de factores de explotacin tales como el nmero de filas de una tabla, la cardinalidad de un ndice o la distribucin en disco. Esto hace que la forma de escribir una sentencia sea el nico modo de obligar al optimizador a elegir un camino de bsqueda determinado. En consecuencia, gran parte de este Manual estar dedicado a evaluar el efecto de la sintaxis sobre el rendimiento de las aplicaciones. Una norma bsica es utilizar la herramienta adecuada en cada situacin. ORACLE dispone de varias herramientas pensadas cada una para un tipo de trabajo. Una eleccin adecuada de la herramienta puede mejorar el rendimiento de la aplicacin.

Captulo
SQL*Loader es una herramienta diseada para insertar datos masivamente en una tabla. Esto exige elaborar un fichero de control y disponer de los datos sobre un fichero secuencial. Este trabajo adicional puede llevar a pensar que una operacin del tipo INSERT-SELECT, mucho ms fcil de implementar, puede sustituir con ventaja a una carga con SQL*Loader. Hemos probado la carga de mil registros utilizando SQL*Loader, por un lado, y el comando INSERT, por otro. Los resultados se muestran en la Tabla I.
Herramienta SQL*Loader INSERT
Tiempo de cpu 0.43 s 20.00 s
Tabla I: Carga masiva de datos.
Como se puede observar, la diferencia es muy apreciable.
La cualificacin de los campos con el alias de cada tabla en los joins, facilita el trabajo de parse al gestor. De lo contrario, ste deber acceder a la definicin de todas las tablas que intervienen para determinar a cual de ellas pertenece cada campo. En este sentido, y para evitar adems dependencias del cdigo con respecto al diseo de la base de datos, deben evitarse tambin sentencias del tipo:
SELECT * FROM TAB
Por ltimo, decir que es necesario que el programador se familiarice con las funciones que incorpora SQL (SUBSTR, DECODE,...). En general es preferible emplear dichas funciones a utilizar las propias del lenguaje husped (C, COBOL,...).

Captulo
Hemos comparado el consumo de cpu de dos procesos implementados en Pro*C que calculan la media de un campo numrico. El primero utiliza la funcin AVG proporcionada por SQL. El segundo utiliza directamente el lenguaje C para acumular y dividir por el nmero de datos. Los resultados se recogen en la Tabla II.
Mtodo Utilizando SQL Utilizando C
Tabla II: Uso de funciones incorporadas.
Como vemos, la mejora de rendimiento puede llegar a ser de varios rdenes de magnitud.
En cualquier caso, hay que cuidar el uso de funciones en SQL: cuando una operacin no dependa de los valores recuperados no debe incluirse en la sentencia. Por ejemplo, es frecuente implementar la funcionalidad de un IF con instrucciones DECODE dentro de una sentencia SQL, lo cual perjudica notablemente al rendimiento de la misma. En tales situaciones, PL/SQL permite extraer el IF de la sentencia y ejecutarlo una sola vez, en lugar de hacerlo por cada fila recuperada.

3.
Indices.
1.
Introduccin.
Los ndices son estructuras opcionales asociadas a las tablas que permiten incrementar notablemente la velocidad de ejecucin de las sentencias. ORACLE emplea rboles de tipo B para balancear el tiempo de acceso a cualquier fila. Estos rboles constituyen una estructura independiente con sus propios parmetros de almacenamiento. Si sobre una columna se ha definido un ndice, ORACLE accede a ste para obtener la direccin (ROWID) de los datos evitando el gran nmero de operaciones de E/S a disco que requiere una bsqueda secuencial en una tabla.
2.
Impacto sobre las aplicaciones.

En principio, las aplicaciones son independientes de los ndices: es posible crearlos y borrarlos sin necesidad de reescribir el cdigo y es el gestor el encargado del mantenimiento de los mismos. No obstante, atendiendo a consideraciones de rendimiento, es imprescindible conocer los ndices definidos en cada tabla para escribir el cdigo que haga un uso ms eficiente de los mismos. La creacin de un ndice mejora sensiblemente la operaciones de recuperacin de datos que puedan beneficiarse de la existencia del mismo. Sin embargo, las operaciones de actualizacin e insercin de datos se vern penalizadas por el hecho de tener que actualizar tambin el ndice. Es por ello que se recomienda valorar cuidadosamente los posibles beneficios frente a los efectos negativos que implica la existencia del ndice. En general, una tabla no debera tener ms de dos o tres ndices.
Sobre una tabla con unas 300.000 filas se ejecuta una sentencia de actualizacin de una columna que forma parte de sucesivos

Captulo
3 Indices.
ndices. La actualizacin afecta a algo ms de 17.000 filas y los resultados se muestran en la Tabla III.
Nmero de ndices Ninguno 1 2 3
Tiempo de cpu 1 m 19 s 2 m 15 s 5 m 59 s 7 m 53 s
Tabla III: Impacto del uso de ndices.
Como reflejan los datos, cada ndice que se aade a una tabla puede hacer que la actualizaciones de la misma requieran el doble de tiempo o ms. Observamos que la actualizacin sobre la tabla con tres ndices consume seis veces ms tiempo que sobre la misma tabla en ausencia de ndices.
3.
Eleccin de ndices.
Los ndices pueden crearse sobre un slo campo o sobre varios, en cuyo caso se habla de ndices concatenados. Ambos pueden o no ser nicos. Un ndice nico hace que el gestor no permita duplicidades de campo (o de la combinacin de campos en los concatenados). Sobre una misma tabla pueden crearse ms de un ndice.

Captulo
3 Indices.
La eleccin de los ndices es una de las decisiones ms comprometidas del diseo tcnico. Una columna ser una buena candidata a ser indexada si: No existe duplicidad de valores (el mejor caso). Por ejemplo, el D.N.I. El campo toma un amplio rango de valores. Por ejemplo el cdigo de cliente en una tabla de pedidos. Una mala eleccin sera el campo sexo que slo toma dos valores. El campo es usualmente nulo y con frecuencia se seleccionan aquellas filas que tienen un valor.
Si el ndice es concatenado, independientemente del orden de los campos en la tabla, la primera columna del ndice ser el campo ms usado o el ms selectivo. Las siguientes secciones explican en detalle las reglas dadas aqu anteriormente.
4.
Uso eficiente de ndices.

ORACLE puede acceder a las tablas de dos modos: Secuencialmente (FULL SCAN). Usando ndices.
El diseador crea los ndices en funcin del uso ms frecuente de los datos, pero es el programador el que decide, en ltimo trmino, si en la sentencia en que est trabajando har que el gestor RDBMS emplee los ndices o haga un acceso secuencial. En general, el acceso por ndice es preferible. Sin embargo, si se preve que un alto porcentaje de los datos ser consultado (digamos ms de un 25%) un acceso secuencial puede ser ms rpido.
Sobre una tabla de 4.253 filas hemos ejecutado una sentencia que recupera 3.265 (~75%), otra que recupera 988 (~25%) y, por ltimo, otra que recupera 218 (~5%). Los resultados, empleando

Captulo
3 Indices.
ndices y accediendo secuencialmente, se muestran en la Tabla IV.
Nmero de filas
Modo
Tiempo de cpu 1.20 s 3.10 s 1.02 s 1.12 s 1.16 s 0.12 s
Nmero de bloques 881 6.532 765 1.977 726 437
Secuencial 75 % Indexado Secuencial 25 % Indexado Secuencial 5% Indexado
Tabla IV: Comparacin de accesos sencuencial e indexado.
Los resultados confirman que el 25 % es una buena estimacin del nmero de filas por encima del cual resulta ms rentable hacer una bsqueda secuencial.
ORACLE puede leer varios bloques de datos en una sola operacin. Si el acceso es secuencial, el gestor aprovecha esta situacin para leer todas las filas recuperadas en una lectura sin accesos adicionales al disco. Por el contrario, cuando el acceso es indexado, el gestor acude al ndice y, con la direccin dada por ste, lee el correspondiente bloque de datos del disco. Aunque el siguiente dato a recuperar estuviese en el mismo bloque, dado que el acceso no es secuencial, ORACLE vuelve a repetir la lectura del mismo. La situacun se agrava si se tiene en cuenta que cada vez que el gestor accede al disco recupera varios bloques de datos. No obstante, esta descripcin simplifica mucho el proceso. En realidad ORACLE utiliza una compleja gestin de memoria (siguiendo algoritmos del tipo LRU) que minimizan el acceso a disco.

10
Captulo
3 Indices.
Este comportamiento del gestor, lleva a ORACLE a recomendar que, para tablas pequeas, no se utilicen ndices, aunque sto no parece corroborarlo la experiencia.
Hemos realizado pruebas sobre dos tablas pequeas (menos de 100K) tomando tiempos de ejecucin para la recuperacin de una nica fila utilizando el ndice y buscndola secuencialmente. Los resultados se muestran en la Tabla V.
Tamao de tabla
Modo Secuencial
Tiempo de cpu 0.04 s 0.02 s 0.00 s 0.01 s
Nmero de bloques 14 3 1 2
244 filas (70K) Indexado Secuencial 17 filas (10K) Indexado

Tabla V: Indices sobre tablas pequeas.
Los datos de tiempo son poco significativos para poder apreciar la diferencia, por lo que se ha incluido el nmero de bloques (de 2K) que ha necesitado recuperar el gestor para resolver la consulta. Se observa que no utilizar ndices puede ser mas rpido para tablas realmente pequeas, pero para dichas tablas la mejora de rendimiento puede ser insignificante. Creemos que esta mejora no compensa el esfuerzo extra de programacin necesario para anular un ndice cuando este deba ser creado (por ejemplo, para garantizar que no haya duplicidades).
5.
Condiciones para el uso de ndices.

En las discusiones que siguen haremos uso frecuente del concepto de predicado. Definimos un predicado como el criterio

11
Captulo
3 Indices.
de seleccin de una sentencia DML, esto es, las condiciones definidas por la clusula WHERE. Por ejemplo, en la sentencia
SELECT FROM WHERE AND X,Y,Z TAB X > 1 Z LIKE C%
el predicado sera:
WHERE X> 1 AND Z LIKE C%
El gestor RDBMS podr usar un ndice slo si se cumplen estas dos condiciones:
C1: La columna es referenciada en un predicado. C2: La columna indexada no est modificada por ninguna
funcin u operador aritmtico. Que se cumplan ambas condiciones no implica necesariamente que el ndice sea usado. El optimizador de ORACLE decidir si es apropiado o no emplearlo. Las siguientes secciones estn dedicadas a profundizar en las condiciones antes indicadas y a dar algunas de las reglas que emplea el optimizador (no todas estn bajo el control del programador).
5.1
Columnas referenciadas explcitamente en predicados .

A veces puede interesar suprimir el uso de algn ndice, por ejemplo, para asegurarnos que el optimizador elige otro que consideremos ms adecuado. Sin embargo, esto no es frecuente y, lamentablemente, resulta habitual escribir sentencias que suprimen el uso de ndices simplemente por error. Conviene, por tanto, matizar el significado de las condiciones dadas en la seccin anterior. La condicin C1 implica que una sentencia del tipo:
SELECT X, Y FROM TAB

12
Captulo
3 Indices.
no emplear ndices por carecer de predicado y har un acceso secuencial (lo cual es generalmente preferible dado que se accede a toda la tabla). El que aparezca la columna X como una de las seleccionadas, no hace que se emplee un hipottico ndice sobre dicha columna dado que no aparece en ningn predicado. Supuesto un ndice sobre la columna X, las sentencias:
SELECT X,Y FROM TAB WHERE X = 1
y
SELECT X,Y FROM TAB WHERE X > 0
s emplearan el ndice sobre la columna X. En el caso de ndices concatenados, la condicin C1 se aplica a la primera columna del ndice. As, suponiendo un ndice concatenado sobre la columnas (X,Y,Z), en este orden, el predicado:
WHERE AND AND X = 1 Y = A Z = C
emplear el ndice eficientemente. Sin embargo, los predicados:

WHERE AND X = 1 Y = A
y
WHERE AND X = 1 Z = C
slo emplearn el ndice parcialmente ya que el predicado no es suficientemente selectivo y habr que hacer lecturas secuenciales (RANGE SCAN). Lo ms importante a destacar es que un predicado como:
WHERE Y = A AND Z = C
no podr usar el ndice dado que la primera columna del mismo (X) no aparece en la clusula WHERE. En esta ltima situacin es posible obligar al optimizador a emplear el ndice. Suponiendo que el campo X toma siempre valores positivos, sera suficiente con reescribir la clusula del siguiente modo:

13
Captulo
3 Indices.
WHERE Y = A AND Z = C AND X > 0
Es importante resaltar que el orden de los campos en un predicado no es significativo para la utilizacin o no de un ndice. Conociendo esta forma de actuar del optimizador de ORACLE, se deducen dos reglas para la creacin de ndices concatenados: Ordenar las columnas por su selectividad, eligiendo como primera columna la ms selectiva para limitar el impacto de los usos parciales del ndice (RANGE SCAN) Elegir como primera columna la ms frecuente en los predicados.
Un compromiso entre ambas reglas determinar la creacin del ndice. La primera suele ser prioritaria dado que ya hemos visto que reescribiendo la sentencias adecuadamente es posible, en general, suprimir los efectos de la segunda regla. Mencionar, por ltimo, que una caracterstica importante de los ndices concatenados es que permiten satisfacer consultas con slo acceder al ndice. En efecto, a veces, todos los campos requeridos pertenecen al ndice concatenado y la consulta es resuelta sin acceder a la tabla.
5.2
Columnas modificadas por funciones u operadores.

La segunda condicin hace que, en el supuesto de que un ndice existiese sobre la columna X y otro sobre la Y, los siguientes predicados:
WHERE WHERE WHERE X + 1 = 3 SUBSTR (Y,1,1) = A Y||Z = ACDR
no permitiran el uso de los correspondientes ndices, dado que las columnas han sido modificadas por funciones u operadores. As, una misma sentencia puede escribirse para que use o no el ndice segn convenga. Siguiendo el ejemplo anterior, en las consultas:

14
Captulo
3 Indices.
WHERE WHERE
X = 2 Z = A
es posible anular el empleode ndices reescribiendo las sentencias del siguiente modo:
WHERE WHERE X+0 = 2 Z|| = A
Una situacin frecuente se produce en la conversin de fechas. Supuesto que FECHA es un campo tipo DATE, el predicado:
WHERE FECHA = TO_DATE (14-ENE-80)
emplear un ndice que se defina sobre el campo FECHA, mientras que el predicado:
WHERE TO_CHAR (FECHA) = 14-ENE-80
no podr usar dicho ndice. El siguiente predicado tambin empleara ndices:

WHERE FECHA = 14-ENE-80
5.3
Excepciones.
Una excepcin importante a estas reglas es la optimizacin especial empleada con las funciones MAX y MIN, que devuelven un slo valor y, por ello, siempre emplean ndices.As, una sentencia select que contenga la expresin:
{ MAX | MIN } ( col {+|-} constante )
y ninguna otra columna, como en

SELECT 2 * MAX (X+1) FROM TAB
emplear el ndice sobre la columna X aunque no cumpla ninguna de las condiciones necesarias. Recordemos que esta consulta puede satisfacerse accediendo slo al ndice, sin necesidad de recuperar los datos de la tabla.

15
Captulo
3 Indices.
6.
Indices y valores nulos.

Siempre que sea posible, es preferible definir las columnas como NOT NULL (incluso buscando un valor como cero o espacio para substituir el significado del nulo). Esto permite el uso de ndices en un mayor nmero de sentencias. En efecto, ORACLE no emplear ndices si el predicado contiene las clusulas:
IS NULL IS NOT NULL
Esto se debe a que el gestor no almacena los valores nulos en el ndice. En general, como hemos comentado con anterioridad, un ndice no contendr columnas que admitan valores nulos. Cuando la bsqueda se realiza sobre uno de estos ndices, aunque el predicado sea de igualdad e identifique completamente la fila deseada, el gestor accede parcialmente en modo secuencial (RANGE SCAN). An cuando se haya definido un ndice sobre una columna que admite nulos, es posible, en algunos casos, obligar al optimizador a usar parcialmente los ndices. Por ejemplo, suponiendo X una columna indexada y con valores nulos, si estamos interesados en aquellas filas que tienen un valor no nulo de X, la sentencia:
SELECT X,Y, Z FROM TAB WHERE X IS NOT NULL
no emplear el ndice, mientras que lasentencia:

SELECT X,Y,Z FROM TAB WHERE X > 0
s emplear el ndice y el resultado ser el mismo, asumiendo que X tome siempre valores positivos. Si, por el contrario, estamos interesados en las filas cuyo valor sea nulo, no hay forma de evitar la lectura secuencial.

16
Captulo
3 Indices.
7.
Tablas con mltiples ndices.

Si se ha definido ms de un ndice en una tabla, el gestor podr usarlos simultneamente si: Los ndices noson nicos. Los predicados son de igualdad.
La primera condicin es obvia: si uno de los ndices es nico (devuelve una nica fila) no es necesario recurrir a ndices adicionales. Por ejemplo, suponiendo un ndice nico sobre X y uno no nico sobre Y, en la sentencia:
SELECT FROM WHERE AND X,Y,Z TAB X = 1 Y = A
ORACLE usar el ndice sobre X para recuperar la fila correspondiente a X=1 y, a continuacin, comprobar si Y=A en funcin de lo cual entregar o no la fila al programa que hizo la consulta. La segunda condicin es una limitacin del optimizadorque debe tenerse en cuenta cuando se trate de evaluar cuales sern los ndices empleados. Si el optimizador decide usar ms de un ndice, selecciona las filas segn cada criterio y luego combina (merge) los resultados en un slo conjunto de datos eliminando duplicidades. En cualquier caso, ORACLE no usar ms de cinco ndices. Si en una sentencia existiesen predicados que involucrasen a ms de cinco ndices, sera interesante suprimir el uso de los menos efectivos con las tcnicas descritas anteriormente.
8.
Optimizando joins
El empleo de ndices en los joins resulta crtico para el rendimiento global de toda la aplicacin. Siempre que se necesite utilizar un join, el programadordebe cuidar la forma de codificarlo de modo que se aprovechen eficientemente los ndices.

17
Captulo
3 Indices.
La regla fundamental consiste sencillamente en asegurar que las columnas claves del join, aquellas que relacionan los datos de cada par de tablas, estn indexadas. Adems, debe escribirse la sentencia de forma que las funciones y operadores no anulen el uso de ndices. Para realizar la consulta generada por un join, el gestor elige una de las tablas como conductora (driver) del join. ORACLE lee cada fila de esta tabla que cumpla las condiciones dadas y, para cada una de estas filas busca en las dems tablas las filas que cumplan las condiciones adicionales especificadas en el join. El acceso a la tabla conductora es siempre secuencial. Por el contrario, el acceso al resto de tablas que participan en el join puede realizarse por medio de ndices, siempre que esto sea posible. As pues, el objetivo del programador ser conseguir que la tabla conductora sea aquella que presente, a priori, un camino de acceso ms lento (sin ndices, ndices no nicos o con menor nmero de filas). El optimizador de ORACLE selecciona la tabla conductora en funcin de los ndices definidos y de sus propias reglas de optimizacin. En las siguientes secciones detallaremos estas reglas.
8.1
Joins no indexados.
Los joins implican siempre una condicin de igualdad (equijoins) sobre uno o varios campos de las tablas que participan en el mismo. A dichos campos, que relacionan las filas recuperadas de las diferentes tablas, le llamaremos campos clave del join. Siempre en un join el optimizador intentar utilizar los ndices definidos sobre los campos clave del mismo. Si no es posible usar ndices (por ejemplo, porque no existan), ORACLE debe realizar una ordenacin de todas las tablas y una combinacin posterior de las mismas (sort-merge join). Concretamente, el gestor seleccionar los datos de cada tabla aplicando las condiciones dadas para los campos que no son claves del join. Los subconjuntos obtenidos a partir de cada tabla, son ordenados por separado. Los resultados se combinan en una nueva relacin basndose en las condiciones clave del join.

18
Captulo
3 Indices.
Las condiciones adicionalesms selectivas (aquellas que no son claves) deben situarse al final del predicado. Esto disminuir el nmero de comprobaciones durante la primera fase de la operacin anteriormente descrita. En un join no indexado,por tanto, ninguna de las tablas es la conductora.
8.2
Joins indexados.
Este tipo de consulta obliga al optimizador a realizar un complejo trabajo para decidir la tabla conductora. En el join de dos tablas, si slo existen ndices usables para una de ellas, el optimizador elegir laotra tabla para conducirlo. De esta forma, realizar un barrido secuencial sobre la tabla no indexada y, por cada fila, acceder por ndice a la otra. La situacin inversa obligara a una lectura secuencial de toda la tabla no indexada por cada fila leida en la tabla indexada. Por ejemplo, si la columna X est indexada en la tabla TAB_1 pero no lo est en la tabla TAB_2, en ambas consultas:
SELECT T1.X, T2.Y FROM TAB_1 T1, TAB_2 T2 WHERE T1.X = T2.X SELECT T1.X, T2.Y, FROM TAB_1 T1, TAB_2 T2 WHERE T2.X = T1.X
la tabla conductora ser TAB_2. Una excepcin a esta regla se da cuando uno de los predicados sobre la tabla no indexada garantiza que se va a recuperar una sola fila (por ejemplo, buscando por ROWID). Si hay ms de un ndice usable, tanto en las columnas claves del join como en el resto de predicados, ORACLE ordena todos los caminos de acceso que encuentre segn los criterios mostrados en la Tabla VI, eligiendo como tabla conductora la que tenga mayor puntuacin (es decir, el camino de acceso ms lento).

19
Captulo
3 Indices.
Puntuacin 1 2 3 4 5 6 7 8 9 10 ROWID = constante
Camino
Columna con ndice nico = constante Indice nico concatenado entero = constante Indice cluster entero = ndice correspondiente a otra tabla dentro del mismo cluster. Indice cluster entero = constante Indice no nico concatenado entero = constante Indice no nico = constante Indice concatenado entero = rango inferior cerrado Indice concatenado especificado parcialmente Columna con ndice nico en una clusula BETWEEN o con la condicin LIKE A% (rangos cerrados) Columna con ndice no nico en una clusula BETWEEN o con la condicin LIKE A% (rangos cerrados) Columna con ndice nico o constante (rangos abiertos) Columna con ndice no nico o constante (rangos abiertos) Joins no indexados (sort-merge) MAX o MIN sobre una sla columna indexada ORDER BY sobre columnas que pertenecen a un ndice Acceso secuencial a una tabla (FULL SCAN) Columna no indexada = constante o columna IS NULL o columna LIKE %A%
Tabla VI: Reglas del optimizador.
11
12 13 14 15 16 17 18
Si ORACLE no encuentra una clara opcin para seleccionar la tabla conductora, elegir la ltima especificada en la clusula FROM. Esto es importante tenerlo en cuenta si se preve un posible empate en cuanto a la velocidad de acceso. En esta situacin ser

20
Captulo
3 Indices.
rentable situar la tabla con mayor nmero de filas al final de la clusula FROM. Hacemos notar, por ltimo, que la Tabla VI sirve tambin como referencia al programador sobre las reglas internas que emplea el optimizador ORACLE. Conociendo estas reglas, es posible codificar las sentencias de modo que el acceso sea lo ms rpido posible no solamente en los joins sino en cualquier sentencia SQL. No obstante, la Tabla VI debe tomarse como una ayuda a la hora de proceder a codificar una sentencia SQL. No es necesario comprender a fondo todos los mecanismos de optimizacin de ORACLE y, por tanto, se conceder a dicha tabla una importancia relativa. Adems, debe tenerse en cuenta, que las reglas de optimizacin tienen un caracter heurstico y, por ello, podrn variar en futuras versiones del gestor.

21
4.
Optimizacin de sentencias.
1.
Introduccin.
En este captulo recogemos informacin sobre la optimizacin de distintas sentencias SQL as como de otros aspectos no contemplandos en captulos anteriores.
2.
Optimizando el uso del operador NOT.

Siempre que aparece la negacin de una igualdad (!= o NOT=), ORACLE no emplea ndices. As, aunque un ndice se haya definido para la columna X, la sentencia:
SELECT X,Y,Z FROM TAB WHERE X != 0
no emplear dicho ndice. Este comportamiento se justifica porque es de suponer que la consulta anterior recupere la mayor parte de las filas de la tabla; en estos casos, suele ser ms rpida una bsqueda secuencial. En la situacin anterior, si adems suponemos que se ha definido un ndice sobre la columna Y, la sentencia:
SELECT FROM WHERE AND X,Y,Z TAB X != 0 Y = A
podra emplear el ndice sobre la columna Y a pesar de la negacin sobre la columna X.
3.
Optimizando el uso del operador OR.

Las sentencias que incluyen el operador OR pueden usar ndices si estos se han definido sobre todas lascolumnas que intervienen.

22
Captulo
4 Optimizacin de sentencias.
Si alguna de las columnas no est indexada, es posible que el optimizador decida no emplear ndices. Esta ltima circunstancia queda fuera del control del programador (suele darse en sentencias que incluyen un CONECT BY y en joins externos). Cuando todas las columnas estn indexadas, ORACLE puede usar los ndices eficientemente. Por ejemplo, si se han definido ndices sobre las columnas X e Y, la sentencia:
SELECT FROM WHERE OR X,Y,Z TAB X = 1 Y = A
es transformada en algo similar a la unin de las dos consultas siguientes:

SELECT X,Y,Z FROM TAB WHERE X = 1 SELECT FROM WHERE AND X,Y,Z TAB Y = A X != 1
Conociendo este comportamiento, es mejor situar al principio la condicin mas selectiva.
Sobre una tabla de una 300.000 filas hemos realizado una consulta secuencial cuyo predicado incluye dos condiciones enlazadas por un OR. Una condicin la cumple solamente el 0.26% de las filas (es muy selectiva). La otra aproximadamente el 38%. La diferencias de tiempos que resultan de cambiar el orden de las condiciones se muestran en la Tabla VII.
Condicin ms selectiva al principio al final
Tiempo de cpu 7s 52 s
Tabla VII: Optimizacin de ORs.

23
Captulo
Se observa una mejora sustancial en el rendimiento. La ganancia puede ser mas notable an si las diferencias de selectividad de las condiciones son ms pronunciadas.
La optimizacin sobre los ORs se aplica, en igual medida, a la clusula IN, dado que el predicado:
WHERE Y IN (A,B,C)
es equivalente a:
WHERE OR OR Y = A Y = B Y = C
4.
Optimizando el uso del operador AND.

Cuando en un predicado intervienen varias condiciones unidas por el operador AND, puede obtenerse un ligeroaumento de rendimiento situando la condicin ms selectiva al principio. Esto se debe al orden en que el parser de ORACLE analiza las sentencias: las condiciones unidas por el operador AND dejan de evaluarse cuando cualquiera de ellas no es cierta.
Bajo las mismas condiciones de las pruebas comentadas para el operador OR, hemos realizado dos consultas situando la condicin ms selectiva al principio y al final. Las diferencias de tiempo de

24
Captulo
cpu no son apreciables por lo que se incluyen los bloques leidos en la Tabla VIII.
Condicin ms selectiva al principio al final
Nmero de bloques 7 9
Tabla VIII: Optimizacin de ANDs.
Como se pueder ver, las diferencias son mnimas aunque tampoco supone un esfuerzo excesivo cuidar la situacin de las condiciones cuando estas van unidas por el operador AND.
5.
Ordenacin.
El gestor de ORACLE dispone de unas rutinas de ordenacin y combinacin de datos (SORT/MERGE) altamente especializadas que optimizan el rendimiento de aquellas operaciones donde se requiere una ordenacin previa: CREATE INDEX, SELECT DISTINCT, ORDER BY, GROUP BY y ciertos tipos de joins. De forma simplificada podemos decir que el gestor ordena los datos en pequeos grupos (runs) los cuales combina (merge) para obtener un resultado final. Existen varios parmetros que permiten al DBA influir sobre las rutinas deordenacin de ORACLE de forma que un alto porcentaje (ms del 98%) de las ordenaciones se realicen en memoria. Es importante conocer que la nica forma de garantizar el orden de recuperacin de un conjunto de datos es con la clusula ORDER BY. Segn la definicin de ndices asociada a las tablas consultadas puede obtenerse un orden adecuado sin especificar la clusula ORDER BY; sin embargo, ORACLE no garantiza que en futuras versiones se mantenga este orden.

25
Captulo
Cuando se realiza una consulta que contiene un GROUP BY, el gestor debe ordenar los datos antes de agruparlos, por lo que es mucho ms eficiente imponer todas los criterios de seleccin como un predicado WHERE (antes de la ordenacin) que con la clusula HAVING. Esta ltima debe reservarse para cuando las condiciones se desean imponer sobre criterios de grupo. Por ejemplo, la consulta:
SELECT FROM WHERE GROUP Y, AVG(X) TAB Y LIKE A% BY Y
es preferible a:
SELECT Y, AVG(X) FROM TAB GROUP BY Y HAVING Y LIKE A%
6.
Creacin y llenado de tablas.

En la ejecucin de tareas batch, es frecuente utilizar tablas temporales de trabajo. Realizar un borrado completo (DELETE) de las mismas es una operacin muy costosa que, adems, tiene efectos colaterales muy perjudiciales (fragmentacin). Por tanto, y hasta que la sentencia TRUNCATE no est disponible, lo normal suele ser borrar la tabla (DROP) y crearla de nuevo. En este proceso se plantean dos alternativas: Crear la tabla, llenarla y crear los ndices. Crear la tabla, crear los ndices y llenarla.
En principio, ORACLE recomienda llenar las tablas sin ndices y crear estos posteriormente. Una vez creada la tabla, parece menos costoso ordenar todas sus filas para crear el ndice correspondiente. Adems se evita el procesamiento que conlleva la bsqueda del lugar adecuado a cada nueva entrada del ndice (recordemos que son estructuras en arbol de tipo B y que el gestor debe balancear las entradas para igualar la profundidad de todas ellas). No obstante, un buen dimensionamiento del ndice antes de crearlo puede ahorrar mucho trabajo al gestor si se opta por crearlo antes de llenar la tabla.

26
Captulo
Hemos probado a llenar una tabla con mil filas creando el ndice previamente y dejando la creacin del mismo para despus de insertar las filas. Los resultados se muestran en la Tabla IX.
Creacin del ndice
Nmero de bloques 7.069 11.145
Despus de insertar Antes de insertar
Tabla IX: Creacin y llenado de tablas.
Las diferencias en tiempo de cpu (utilizado para llenar la tabla y crear el ndice) no son apreciables. Sin embargo, se observa que creando el ndice despes de llenar la tabla el gestor necesita procesar muchos menos bloques. Es de esperar que para tablas mayores, las diferecias de cpu adquieran importancia y se decanten a favor de insertar las filas antes de crear el ndice.
7.
Subqueries vs. joins.

ORACLE afirma que su gestor de bases de datos est especialmente diseado para resolver eficientemente los joins. Por ello recomienda usarlos en lugar de otras posibilidades que ofrece SQL. En concreto, es posible utilizar queries anidadas o subqueries como alternativa al join. Una subquery crea una tabla temporal para almacenar las filas recuperadas de la tabla hija y, posteriormente, realiza un join con la tabla padre. Por tanto, adems de no eliminar la operacin de join, una subquery se apoya en tablas temporales que carecen de ndices y sobre cuya parametrizacin (dimensionamiento) no se puede influir directamente.

27
Captulo
Esta discusin, hace pensar que un join es mucho ms eficiente que una subquery, pero la experiencia no parece corroborarlo.
Como prueba hemos recuperado 1000 filas a partir de dos tablas, ambas indexadas, una con 300.000 filas y otra con slo 100. En la prueba se ha buscado que la tabla conductora del join sea la mayor, al igual que en la subquery el SELECT padre se realiza sobre dicha tabla. Los resultados se muestran en la Tabla X.
Operacin Join Subquery
Tabla X: Comparacin entre join y subquery.
Aunque las diferencias de tiempo no son significativas, no hemos incluido datos sobre el nmero de bloques utilizados por que dicho nmero coincide en ambos mtodos. Por tanto, podemos concluir que no existe una clara ventaja de un mtodo de acceso sobre el otro. No obstante, y dado que los argumentos tericos en favor del join estn justificados, es preferible emplear ste siempre que sea posible. Quizs, en otro tipo de prueba, las diferencias sean ms relevantes.

28
5.
Herramientas.
8.
Introduccin.
Existen diversas herramientas que ayudan a localizar problemas de rendimiento en las aplicaciones. Estn pensadas fundamentalmente para ser utilizadas por el DBA y no vamos a describirlas en este Manual. No obstante, es importante que los equipos de desarrollo sepan de su existencia para que as puedan pedir la colaboracin del Area de Sistemas a la hora de diagnosticar un problema de rendimiento. Aparte de la herramientas propias del DBA (MONITOR, TKPROF,...) existen una utilidad que puede ayudar a los programadores a decidir entre diferentes alternativas. Se trata de la sentencia EXPLAIN PLAN que nos muestra las decisiones que tomar el optimizador cuando ejecute una sentencia determinada. Este captulo explica en detalle la utilizacin de esta utilidad.
9.
La sentencia EXPLAIN PLAN.

La sentencia EXPLAIN PLAN muestra el plan de ejecucin elegido por el gestor ORACLE para optimizacin de sentencias DML. Un plan de ejecucin es un conjunto de operaciones elementales y un orden en el que el gestor ejecuta dichas operaciones. Antes de poder utilizar la sentencia EXPLAIN PLAN es necesario crear una tabla de trabajo llamada PLAN_TABLE. Para ello se ejecuta el procedimiento:
SQL> @?/rdbms/admin/xplainpl
Una vez creada la tabla de trabajo es posible utilizar la sentencia EXPLAIN PLAN, la cual almacena el plan de ejecucin resultante en esta tabla de trabajo. La sintaxis de dicha sentencia es:
EXPLAIN PLAN [SET STAMENT_ID = descripcin] [INTO tabla] FOR sentencia_sql

29
Captulo
5 Herramientas.
en donde: descripcin es una identificacin opcional de hasta 30 caracteres que permite diferenciar los distintos planes de ejecucin almacenados en la tabla de trabajo. Usualmente, la tabla de trabajo no contendr ms de uno o dos planes de ejecucin. tabla es el nombre de la tabla de trabajo. Si no se especifica, se utiliza la tabla PLAN_TABLE.
10. Descripcin de la tabla de trabajo.

La tabla de trabajo, PLAN_TABLE, en la cual la sentencia EXPLAIN PLAN almacen el plan de ejecucin, tiene los siguientes campos:
STATEMENT_ID TIMESTAMP REMARKS
Identificador opcional del plan de ejecucin. Fecha del anlisis Comentarios adicionales (hasta 80 caracteres). Nombre de la operacin elemental. Descripcin adicional sobre la operacin a realizar. Database link. No suele interesar. Propietario de la tabla o ndice utilizado en la operacin. Nombre de la tabla o ndice utilizado en la operacin. Un nmero indicando la posicin del objeto en la sentencia: numerados de izquierda a derecha. No suele interesar. Un modificador que da ms informacin sobre el objeto. Por ejemplo NON-UNIQUE para ndices. No usado actualmente.
OPERATION OPTIONS
OBJECT_NODE OBJECT_OWNER
OBJECT_NAME
OBJECT_INSTANCE
OBJECT_TYPE
SEARCH_COLUMNS

30
Captulo
5 Herramientas.
ID
Un nmero asignado a cada operacin elemental del plan de ejecucin. El ID de la siguiente operacion elemental. Ms adelante se ver la relacin entre ambos campos. Orden de procesamiento para aquella operaciones que tienen el mismo PARENT_ID. Informacin adicional (por ejemplo, proceso distribuido) que que no suele ser de inters general.
PARENT_ID
POSITION
OTHER
11. Utilizacin de la sentencia EXPLAIN PLAN.

Para mostrar el uso de la sentencia EXPLAIN PLAN, empleamos las tablas DEPT y EMP que tradicionalmente usa ORACLE en todos sus ejemplos. Dada la sentencia:
SELECT E.ENAME, E.JOB, E.SAL, D.DNAME FROM EMP E, DEPT D WHERE E.DEPNO = D.DEPNO AND NOT EXISTS (SELECT TRUE FROM SALGRADE WHERE E.SAL BETWEEN LOSAL AND HISAL)
podemos obtener el plan de ejecucin con la sentencia:

EXPLAIN PLAN SET STATEMENT_ID = Prueba 1 FOR SELECT E.ENAME, E.JOB, E.SAL, D.DNAME FROM EMP E, DEPT D WHERE E.DEPNO = D.DEPNO AND NOT EXISTS (SELECT TRUE FROM SALGRADE WHERE E.SAL BETWEEN LOSAL AND HISAL)

31
Captulo
5 Herramientas.
El plan de ejecucin ha sido almacenado en la tabla de trabajo. Una forma de obtener un listado identado correctamente es con la sentencia:
SELECT LPAD( ,2*LEVEL)||OPERATION|| || OPTIONS|| ||OBJECT_NAME PLAN_DE_EJECUCION FROM PLAN_TABLE WHERE STATEMENT_ID = Prueba 1 CONNECT BY PRIOR ID = PARENT_ID AND STATEMENT_ID = Prueba 1 START WHIT ID = 1
que muestra el siguiente resultado:

PLAN_DE_EJECUCION FILTER MERGE JOIN SORT JOIN TABLE ACCESS FULL DEPT SORT JOIN TABLE ACCESS FULL EMP TABLE ACCESS FULL SALGRADE
Como se ve, el optimizador ha decidido realizar un merge-join de las tablas EMP y DEPT, dado que no hay ndices definidos sobre ninguna de las tablas empleadas en la sentencia. El filtro del nivel superior, provoca una bsqueda secuencial en la table SALGRADE por cada fila entregada por la operacin previa (merge-join). La Tabla XI describe todas las operaciones elementales que puede mostrar un plan de ejecucin as como sus diferentes opciones. La interpretacin completa de un plan es compleja y no creemos necesario profundizar en ello. El Area de Sistemas podr ayudar en la interpretacin de dichos planes cuando stos sean excesivamente complicados.

32
Captulo
5 Herramientas.
Operacin
AND-EQUAL
Opciones
Descripcin Recuperacin utilizando la interseccin de ROWIDs obtenidos por bsqueda en ndices. Esta operacin se utiliza en predicados de igualdad que unen condiciones con el operador AND. Se utiliza para implementar un CONECT BY. Recuperacin a partir de un grupo de tablas. Es una operacin de UNION ALL de las tablas originales. Cuenta el nmero de filas recuperadas de una tabla. Aplica una restriccin sobre las filas a recuperar. Recupera slo la primera fila del resultado de una consulta. Genera un row lock sobre las filas seleccionadas.
CONNECT BY
CONCATENATION
COUNTING
FILTER
FIRST ROW
FOR UPDATE
INDEX
UNIQUE SCAN RANGE SCAN
Bsqueda por ndice para localizar un nico valor. Bsqueda por ndice para localizar un rango de valores. Recupera las filas comunes de dos tablas. Previamente stas son ordenadas. Un join obtenido por la combinacin (merge) de dos conjuntos ordenados de tablas.
INTERSECTION
MERGE JOIN
OUTER MINUS
El join es externo. Recuperacin de filas que estn en una tabla pero no en otra. Un join realizado sobre dos operaciones hijas. Para cada fila recuperada por la primera operacin, se realiza la segunda operacin.
NESTED LOOPS
OUTER
El join es externo.
Tabla XI: Operaciones presentes en un Plan de Ejecucin.

33
Captulo
5 Herramientas.
Operacin
PROJECTION
Opciones
Descripcin Recuperacin de un subconjunto de columnas de una tabla. Recuperacin sobre una Base de Datos diferente a la actual. Una operacin que involucra a un generador de secuencias.
REMOTE
SEQUENCE
SORT
UNIQUE
Recuperacin ordenada de filas para producir valores nicos. Recuperacin ordenada de filas destinadas a realizar agrupaciones. Recuperacin ordenada de filas para la realizacin de un join. Recuperacin ordenada de filas provocada por la clusula ORDER BY. Acceso a una tabla por ROWID, normalmente obtenido de la lectura previa de un ndice. Acceso secuencial a una tabla (FULL SCAN). Acceso a una tabla en cluster. Recuperacin de filas de dos tablas eliminando duplicidades. Recuperacin de filas utilizando una vista.
GROUP BY JOIN
ORDER BY TABLE ACCESS BY ROWID
FULL
CLUSTER UNION
VIEW
Tabla XI: Operaciones presentes en un Plan de Ejecucin.

34
A. Referencias.
W.H. Inmon. ORACLE: Building High Performance Online Systems. QED Information Sciencies, Inc. 1989.
U. Rodgers.
ORACLE: A Database developers guide. Yourdon Press. 1991.
S. Dimmick et al
ORACLE RDBMS. Database Administratiors Guide. Version 6.0. 1990.
B. Linden et al.
ORACLE RDBMS. Performance Tuning Guide. Version 6.0. 1990.
VV.AA.
ORACLE UK. Technical Bulletin. March 1991.
E. Armstring et al. ORACLE7 Server. Application Developers Guide. 1992

35

Optimizacion Select Oracle

Cargado por

Copyright:

Formatos disponibles

Optimizacion Select Oracle

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Optimizacion Select Oracle

Cargado por

Copyright:

Formatos disponibles

Universidad de Crdoba

Servicio de Informtica Area de Sistemas Julio 1993

Servicio de Informtica - Area de Sistemas

Servicio de Informtica - Area de Sistemas

Servicio de Informtica - Area de Sistemas

Servicio de Informtica - Area de Sistemas

Herramienta SQL*Loader INSERT

Tiempo de cpu 0.43 s 20.00 s

Tabla I: Carga masiva de datos.

Como se puede observar, la diferencia es muy apreciable.

Servicio de Informtica - Area de Sistemas

Mtodo Utilizando SQL Utilizando C

Tiempo de cpu 0.1 s 594.9 s

Tabla II: Uso de funciones incorporadas.

Servicio de Informtica - Area de Sistemas

Impacto sobre las aplicaciones.

Servicio de Informtica - Area de Sistemas

Nmero de ndices Ninguno 1 2 3

Tabla III: Impacto del uso de ndices.

Servicio de Informtica - Area de Sistemas

Uso eficiente de ndices.

Servicio de Informtica - Area de Sistemas

ndices y accediendo secuencialmente, se muestran en la Tabla IV.

Tiempo de cpu 1.20 s 3.10 s 1.02 s 1.12 s 1.16 s 0.12 s

Nmero de bloques 881 6.532 765 1.977 726 437

Secuencial 75 % Indexado Secuencial 25 % Indexado Secuencial 5% Indexado

Tabla IV: Comparacin de accesos sencuencial e indexado.

Servicio de Informtica - Area de Sistemas

Tiempo de cpu 0.04 s 0.02 s 0.00 s 0.01 s

244 filas (70K) Indexado Secuencial 17 filas (10K) Indexado

Condiciones para el uso de ndices.

Servicio de Informtica - Area de Sistemas

Columnas referenciadas explcitamente en predicados .

Servicio de Informtica - Area de Sistemas

emplear el ndice eficientemente. Sin embargo, los predicados:

Servicio de Informtica - Area de Sistemas

WHERE Y = A AND Z = C AND X > 0

Columnas modificadas por funciones u operadores.

Servicio de Informtica - Area de Sistemas

no podr usar dicho ndice. El siguiente predicado tambin empleara ndices:

y ninguna otra columna, como en

Servicio de Informtica - Area de Sistemas

Indices y valores nulos.

no emplear el ndice, mientras que lasentencia:

Servicio de Informtica - Area de Sistemas

Tablas con mltiples ndices.

Servicio de Informtica - Area de Sistemas

Servicio de Informtica - Area de Sistemas

Servicio de Informtica - Area de Sistemas

Puntuacin 1 2 3 4 5 6 7 8 9 10 ROWID = constante

Servicio de Informtica - Area de Sistemas

Servicio de Informtica - Area de Sistemas

Optimizando el uso del operador NOT.

podra emplear el ndice sobre la columna Y a pesar de la negacin sobre la columna X.

Optimizando el uso del operador OR.

Servicio de Informtica - Area de Sistemas

es transformada en algo similar a la unin de las dos consultas siguientes:

Conociendo este comportamiento, es mejor situar al principio la condicin mas selectiva.

Condicin ms selectiva al principio al final

Tabla VII: Optimizacin de ORs.