Los índices se reconstruyen para eliminar la fragmentación. Hay mil y un artículos y publicaciones de blog sobre la naturaleza de la fragmentación del índice, pero @BrentOzar recientemente publicó una explicación particularmente concisa en Stop Worrying About SQL Server Fragmentation .
Retrocedamos un segundo y pretendamos que su base de datos es una guía telefónica organizada por apellido, nombre.
A medida que las personas se mudan a su ciudad, tenemos que agregarlas a la guía telefónica. Idealmente, cada página tiene un espacio vacío, y lo gobernamos con el factor de relleno. Cuando SQL Server reconstruye índices, utiliza el factor de relleno para decidir cuánto espacio libre dejar en cada página. Si no hay suficiente espacio libre, SQL Server tiene que reorganizar, pero no puede empujar exactamente una nueva página en el medio de la guía telefónica. El libro ya está encuadernado. Tendremos que agregar más páginas en blanco al final.
Problema n. ° 1: Fragmentación interna: tenemos una página recién agregada con casi nada. Problema # 2 - Fragmentación externa: las páginas de la guía telefónica están fuera de servicio.
El reciente artículo de Brent ofrece una perspectiva actualizada sobre una de sus series anteriores, Index Fragmentation Findings . El artículo anterior destaca las estadísticas de estudios mucho más antiguos sobre los efectos dañinos de la fragmentación, el más reciente es un argumento para mitigar un gran porcentaje de las desventajas del rendimiento al garantizar que su base de datos esté completamente en caché.
Ram es ahora tan cómicamente barato que probablemente sea la solución más barata, fácil y de menor riesgo para una base de datos muy fragmentada. Especialmente si la naturaleza del diseño de la base de datos es tal que naturalmente se fragmentará a pesar de los esfuerzos de mantenimiento.
