Browse Month: febrero 2012

Indexing Guidelines

Para cuando nos preguntemos en qué casos debería crear un índice, por qué debería crearlo o por qué no, presentaré un pequeño checklist que nos puede ayudar a decidirnos que hacer:

Guideline Razón
Crear tantos índices como necesites, pero intentando mantener un número mínimo. Añade índices de forma juiciosa. Comprueba primero para tener medidas por las que guiarte. Los índices incrementan el performance, pero también consumen espacio en disco y recursos (CPU, memoria, I/O). No añadas índices innecesariamente.
El performance requerido de una query sobre una tabla debe ser la base de la estrategia de indexaxión. Indexar columnas usadas en queries SQL ayudarán al performance de dicha query.
Considerar usar SQL Tuning Advisor o SQL Access Advisor para recomendaciones de índices. Estas herramientas ofrecen recomendaciones y una importante ayuda en tu decisión de indexación.
Crea PK (Primary Key) constraints para todas las tablas. Esto automáticamente creará un índice B-Tree (si las columnas en la PK no están previamente indexadas).
Crea unique key constraints donde sea apropiado. Esto automáticamente creará un índice B-Tree (si las columnas en la PK no están previamente indexadas).
Crea índices en las columnas que tengan una FK (Foreign Key). Las columnas con FK son habitualmente incluidas en cláusulas WHERE con JOIN de tablas y esto mejorará el performance de sentencias SQL SELECT. Creando un índice B-Tree en la columna FK también reducirá bloqueos cuando actualices e insertes en las tablas hijas.
Seleccionar con cuidado y probar los índices en tablas pequeñas. Incluso en tablas pequeñas un índice puede mejorar el performance de la SQL.
Uso correcto del tipo de índices. Seleccionar el tipo de índice correcto para cada caso puede mejorar el performance.
Usar un índice B-Tree si no se tiene un aumento de performance verificado con un tipo diferente de índice. Los índices B-Tree son adecuados para muchas aplicaciones donde se tiene una alta cardinalidad en los valores de columnas.
Considerar usar índices Bitmap en entornos Data Warehouse. Este tipo de índices son ideales para columnas con baja cardinalidad donde los valores no son actualizados a menudo. Índices Bitmap trabajan bien en columnas con FK donde tú a menudo ejecutas queries con condiciones JOIN usando AND y OR.
Considerar usar tablespace separados para índices (separarlos de las tablas) Los datos de tablas e índices deben tener diferente almacenamiento. Usando diferentes tablespace la administración de los índices se hará de forma separada a la de tablas.
Que el índice herede sus propiedades de almacenamiento desde el tablespace. Esto hará más sencillo de administrar el índice.
Uso de nombres estándar y consistentes. Esto hará el mantenimiento y la resolución de problemas más sencilla.
No haga rebuild de índices a menos que tengas una sólida razón para ello. Realizar un rebuild de índice es habitualmente innecesario salvo que un índice esté corrupto o tú quieras mover el índice a diferente tablespace.
Monitorizar los índices y borrar los que no se utilizan. Esta operación libera espacio y mejora el performance de las operaciones DML.
Antes de borrar un índice, considera marcarlo como unusable o invisible. Esto permitirá determinar la mejora si el no hay pérdida de rendimiento al borrar el índice. Podrás volver a rehacer o realizar rebuild del índice sin requerir ejecutar sentencia DDL para la creación del índice.

Referencias: “Expert Indexing in Oracle Database 11g”