Para buscar qué estadísticas o índices están duplicados, nos basamos en el primer campo. Esto es debido a que a/ las estadísticas automáticas son sobre un campo; b/ las estadísticas de usuario pueden ir sobre varios campos, pero es el primero el que puede indicarnos duplicados; y c/ en el caso de los índices, si dos empiezan por el mismo campo, debemos analizarlos para ver si uno cubre al otro o si los dos son necesarios. Por lo tanto no vamos a buscar coincidencias exactas, sino indicadores de que pueden existir estadísticas o índices de más, y que, por tanto, mejorará el rendimiento eliminarlos.
Para ello, por cada base de datos buscamos en todas las tablas (sys.tables y sys.schemas) todas las estadísticas (sys.stats) y el primer campo según el orden de la estadística (sys.stats_columns), además del nombre y ancho de dicha columna (sys.columns).
El ancho es algo informativo, pues otra cosa que podemos hacer es eliminar estadísticas de campos muy anchos pues generalmente no se usan en las consultas. Es decir, en un campo grande se suele usar LIKE para buscar en cualquier parte de dicho campo, y las estadísticas generalmente no ayudan en este caso.
Si agrupamos por el identificador del objeto y el de la columna, vamos a tener aquellas estadísticas que podríamos analizar.
Si la instancia del Servidor SQL Server tiene muchas bases de datos o las bases de datos llevan tiempo sin revisarse, nos pueden devolver muchas estadísticas duplicadas. Dado que no suelen afectar al rendimiento, nos podemos centrar en las más importantes, bien sea por su tamaño, bien sea por el número de filas.
Ahora bien, esto lo podemos enfocar de varias maneras. En mi caso me interesaba saber el tamaño de la primera columna tanto en MB como en récords. Es decir, como no me interesaban exclusivamente las estadísticas, sino también los índices, no busqué el número de filas revisadas para hacer la estadística ni el tamaño de dicha estadística, sino de la columna. Por lo tanto, una vez conseguidas qué estadísticas aparecían como duplicadas, le añadí estos datos para luego filtrar las más importantes.
Generalmente es porque se empezó a trabajar con una tabla, estaba habilitada la creación automática de estadísticas, SQL Server crea estadísticas automáticas de columna para analizar consultas, y luego se crean índices. Es fácil encontrar tablas que tienen estadísticas en todas sus columnas aunque en los aplicativos no se usen dichas columnas en búsquedas o uniones. Es el efecto de las pruebas en producción donde a veces se analizan las columnas y SQL Server crea estadísticas para consultas que se ejecutan una sola vez. Dichas estadísticas son idénticas si se actualizaron al mismo tiempo. De otra manera, los duplicados pueden generar estadísticas diferentes para los mismos datos, que, sin el mantenimiento adecuado, pueden hacer que el optimador de consultas genere un plan incorrecto.
Veamos un ejemplo. Estas son las estadísticas automática y de índice:
Si nos fijamos, al haberse actualizado a la vez, son idénticas. Por lo tanto, podríamos quitar la automática y tendrías un recorrido menos que hacer durante el mantenimiento. Un análisis de este tipo puede evitar que se tengan que escanear inútilmente millones de líneas en el mantenimiento de las bases de datos.
Las anteriores las vemos en el Explorador de objetos:
Fijémonos que la consulta nos da tanto el nombre, como el identificador del campo en decimal y hexadecimal. Para las estadísticas automáticas, dicho identificador hexadecimal está en el nombre de la estadística y así la podemos localizar rápidamente. En el ejemplo, el campo IDTASK es el segundo y encontramos el duplicado enseguida.
En otras ocasiones hay que ir analizando cada una de las estadísticas para encontrar el duplicado. Por ejemplo en el caso de índices «duplicados»:
En este caso tenemos que hay tres estadísticas que empiezan por el campo ATTRIBUTE_ID, lo que nos indica una utilidad adicional de este tipo de análisis: ¿alguno de los índices es redundante? Para ello recurriremos al análisis estándar de uso de índices y eliminaremos aquellos índices –lo que hace desaparecer su estadística– que se actualizan mucho y se usan poco. Pero en otras ocasiones veremos que, aunque hay una posible redundancia, inclusive que un índice cubra a otro, todos se están usando para acelerar consultas específicas y por lo tanto son necesarios. En este caso es mejor dejarlos.
Si nos fijamos, el orden de las columnas en la vista de la estadística (stats_column_id) es muy distinto al real que nos indica la vista del índice (key_ordinal). Por lo tanto, esta consulta debería ser mejorada para que, si es una estadística de índice, buscase el primer campo del índice en vez de el de la estadística. Pero esta complicación la dejamos como tarea.
Aunque no sea muy necesario el análisis de las estadísticas duplicadas, si usamos los filtros adecuados nos pueden indicar las que mejorarían el mantenimiento así como índices que podemos eliminar.
Dejar un comentario
¿Quieres unirte a la conversación?¡Siéntete libre de contribuir!