Uncategorized

“Los índices son buenos para el rendimiento” En términos generales, los DBA y los desarrolladores pasan una buena cantidad de su tiempo de rendimiento tratando de encontrar qué índices agregar a una base de datos para mejorar el rendimiento. Si una consulta específica tiene problemas de rendimiento, una de las herramientas más sólidas para solucionar el problema es la indexación. Esta es una verdad indiscutible, casi dogmática. Universalmente conocida, como el hundimiento de la Armada Invencible. “Los índices son malos para el rendimiento” Sin embargo, ¡Sorpresa!  los índices no son del todo buenos. Dejando a un lado el hecho de que algunos índices, particularmente los índices con baja cardinalidad pueden dañar el rendimiento, los índices se almacenan físicamente en el disco. Esto significa que no sólo ocupan espacio en el disco, sino que también perjudican el rendimiento de las operaciones que insertan, actualizan o eliminan datos. Cada índice adicional representa un lugar más en el disco y Db2 tiene que insertar, actualizar o eliminar los mismos datos que están almacenados en la tabla. Los índices también deben mantenerse a través de reorganizaciones y estadísticas de ejecución y deben respaldarse con el resto de la base de datos. Esta parte ya no es tan universalmente conocida, como la derrota de la contraarmada inglesa primero en La Coruña y luego en Lisboa y Azores. Teniendo esto en cuenta, hay que establecer nuestras prioridades de rendimiento a la hora de calcular cuántos índices hay que agregar. Estas prioridades pueden ser diferentes de una tabla a otra dentro de la misma base de datos. Muchos consultores de Db2 cuentan historias de terror como entrar en un cliente y encontrar 30 o más índices en una tabla que es fundamental para el rendimiento de OLTP. Al menos un consultor que conozco afirma haber costeado la universidad de sus hijas y sus respectivas bodas eliminando índices. ¿Cuántos índices hay que crear, entonces? No hay un número mágico para el número correcto de índices en una tabla. Para Db2, a menudo un buen índice que ayuda a múltiples consultas es mejor que un índice perfecto para cada consulta. A menudo, es probable que las bases de datos en el extremo del espectro de análisis / BI / Data Warehouse tengan más índices que los del extremo del espectro OLTP / procesamiento de transacciones / comercio electrónico. Esto se debe a que la prioridad en las bases de datos analíticos son las consultas, mientras que la prioridad en las bases de datos de procesamiento de transacciones a menudo son las pequeñas actualizaciones, inserciones y eliminaciones de una sola fila que los índices adicionales pueden ralentizar. Identificación de índices no utilizados Con Db2 9.7, IBM introdujo una columna en varias vistas del sistema, incluido SYSCAT.INDEXES, que registra la última vez que se utilizó un objeto. Esta columna, llamada LASTUSED, no se actualiza inmediatamente después del uso de un objeto para evitar el impacto en el rendimiento, pero generalmente es precisa. Hubo algunos problemas con los primeros fixpacks de 9.7 (allá por 2010), por lo que los números realmente