jump to navigation

Oracle – Detalles para la optimización

 Fuente: http://www.ixora.com.au/tips/not_null.htm

Declarar NOT NULL las Restricciones

La gente a veces no se toma la molestia de definir columnas como NOT NULL en el diccionario de datos, aunque estas columnas no deberían contener nulls, y, de hecho, nunca contienen nulls porque la aplicación se asegura de que siempre es un valor suministrado. Usted puede pensar que se trata de una cuestión de indiferencia, pero no lo es. El optimizador a veces necesita saber que una columna no es NOT NULL, y sin este conocimiento, se limita a elegir un plan de ejecución inferior al óptimo.

Un índice en una columna nullable no puede ser utilizado para conducir el acceso a la tabla a menos que la consulta contenga uno o más predicados contra esta columna que excluya valores nulos. Por supuesto, no es normalmente conveniente utilizar un índice basado en la ruta de acceso a menos que la consulta contenga tales predicados, pero hay excepciones importantes. Por ejemplo, si una tabla completa de exploración fuese requerida contra la tabla y la consulta pueda ser satisfecha por la rapidez de escaneo completo contra el índice, entonces este último plan resultará más eficiente.

Otro caso importante es clasificar la eliminación. Si el mejor plan de ejecución provisional requiere de una operación de ese tipo que podría ser eliminada por la elección de un rango de exploración de un índice posiblemente descalificado anterior al plan de ejecución, entonces el optimizador aceptará esta alternativa y tomará una decisión basada en el costo total de ejecución de la consulta, a pesar de que el rango de exploración de índices pueda ser una ruta de acceso a la única tabla relativamente costosa. Esta forma de clasificar la eliminación es especialmente atractiva para el optimizador si el tamaño de bloque de la base de datos es grande (aquí está la razón/causa). Pero, por supuesto, no está disponible para el optimizador a menos que se sepa que no filas con valores nulos no indexados puedan ser perdidas por el rango de exploración de índices.

Las subconsultas NOT IN no pueden ser desencajadas como anti-uniones a menos que haya limitaciones NOT NULL en las columnas unidas, o predicados equivalentes en la consulta. Esta restricción es necesaria porque si los datos contuvieran nulls, la semántica de una subconsulta NOT IN sería diferente de las de una anti-unión. Para una anti-unión la subconsulta es desencajada e instantánea una vez en un intervalo temporáneo, y luego unida al bloque de consulta padre con la semántica de unión inversa. Esto es, las filas provenientes del bloque de consulta padre se devuelven si y sólo si no hay alguna fila de la subconsulta instantánea que pueda ser equi-unión. Si la subconsulta instantánea puede contener llaves de unión nulas, luego las filas padres que no pueden ser equi-unidas a cualquiera de los valores conocidos serían devueltas, mientras que la semántica de un predicado NOT IN es que debe tener el valor verdadero DESCONOCIDO para tales filas, y que deberían, por lo tanto, no ser devueltas.

Las limitaciones NOT NULL también sirven para garantizar que ciertas uniones de opinión materializadas son a pérdida, y por lo tanto, para validar la compatibilidad de unión cuando se considera el uso de una opinión materializada para reescribir las consultas que no incluyen esa unión.
El optimizador está siendo mejorado con cada versión de Oracle, y es altamente probable que haya aún más trucos de optimizador en futuras versiones que serán activados o desactivados por la presencia de restricciones NOT NULL. Por lo tanto, es aconsejable hacer ahora restricciones NOT NULL explícitas en el diccionario de datos, incluso si no se prevé ningún beneficio inmediato sobre el rendimiento de ejecución de la consulta debido a los tres factores anteriormente mencionados.


Comentarios ( Abril 2008 )

Bocca  Gabriel              Mat: 3301-2020
Holubika Guido              Mat: 3101-1731
Máspero Silvia               Mat: 3101-1576
Mazzalai Rubén            Mat: 1328-0238
Paccioretti  Claudio            Mat: 3301-1608

Este articulo nos demuestra que una cosa tan simple como declarar NOT NULL las restricciones en el diccionario de datos, puede repercutir en el rendimiento y como son  cosas que un Administrador de Base de Datos puede pensar que el optimizador de consultas lo puede arreglar o  dar por sentado, nos permite demostrar que es una equivocación que se comete y que pagaremos a la hora de realizar consultas en una base de datos Oracle. ¿Como se pagara? Es muy simple en rendimiento y en el costo de las consultas aumentando seguramente los tiempos de respuesta.


 

A %d blogueros les gusta esto: