Indices de la base de datos, una complejidad escondible.

Desde hace unos días, una de las bases de datos SQL Sever mas grandes de nuestros clientes, está felizmente migrada a SQL Server 2005. En todas estas migraciones suceden algunos desajustes y cosas que andaban rápido pasan a demorar y otras que demoraban funcionan mucho mas rápido.

Esto me dio la oportunidad de evaluar "en serio" las herramientas de tunning que vienen con esta versión de la base de datos, y realmente me dejó muy gratamente sorprendido.

Las herramientas que existen en esta versión son mas o menos las mismas que las que existian en SQL Server 2000 aunque todas fueron re-bautizadas. Lo que si mejoró mucho fue la integración entre las mismas, y la usabilidad que tienen. Lo que antes implicaba un trabajo manual muy grande y muy propenso a errores, ahora se puede realizar mucho mas facilmente.

Por ejemplo si se tiene una determinada aplicación que esta funcionando lento, se puede capturar con el Profiler las sentencias ejecutadas, luego dicha carga se lo pasa al Engine Tunning la cual, con la base de datos y la carga, determina cuales serian los cambios a realizar en la base de datos, para lograr mejorar la performance de dicha carga. Los resultados de dicho proceso son un conjunto de directivas para la creación de indices y estadísticas que permitan mejorar el rendimiento. También tiene reportes varios, entre otros, las sentencias que mejoran su rendimiento (en % del costo) y las que empeoran el rendimiento (nada es gratis en la vida!!).
Si estoy trabajando con la base de producción, puedo elegir que me haga las recomendaciones que puedo correr online, y tiene la opción de aplicarlas y luego evaluar que tanto mejoró con esos cambios. Realmente IMPRESIONANTE.

Las estadísticas que llega a querer crear, no son para nada obvias. Hace combinaciones de atributos, que creo que ningun DBA en su sano juicio hubiese creado de primera.
También me gustó una nueva funcionalidad de los indices que permite asociarle datos a los indices, entonces por ejemplo, a pesar que crea un indice por el campo ESTADO, tambien le agrega a cada nodo el campo NroFactura. Con eso logra reducir mucho la cantidad de lecturas a disco que va a tener que realizar. No hace mas que materializar una vista de estos datos. Como las aplicaciones Genexus generalmente hacen muchos mas "selects" que "updates", se favorecen claramente.

Todo esto me lleva a pensar, que si bien hoy los indices son totalmente críticos para determinar la performance de cualquier aplicación, estamos mucho mas cerca del modelo relacional original (del cual los indices no forman parte). Va a llegar el día, en que diseñemos la base de datos, normalizada, sin siquiera preocuparnos de los indices y la empecemos a usar. Con el uso la base de datos va a crear los indices y las estadísticas/histogramas y todo lo que considere necesario para mantener la carga óptima y a medida que pase el tiempo va a ir ajustándose cada vez más. También va a tener que borrar las cosas que no sean utilizadas después de un tiempo. Es una forma de ocultar una complejidad, que con la sofisticación que están teniendo los optimizadores hoy en día, es cada día mas difícil de abarcar.