No eres tú, soy yo (solución de problemas de E/S)

Autora invitada:Monica Rathbun (@SQLEspresso)

A veces, los problemas de rendimiento del hardware, como la latencia de E/S del disco, se reducen a una carga de trabajo no optimizada en lugar de un hardware de bajo rendimiento. Muchos administradores de bases de datos, incluido yo mismo, quieren culpar inmediatamente al almacenamiento por la lentitud. Antes de ir y gastar una tonelada de dinero en hardware nuevo, siempre debe examinar su carga de trabajo en busca de E/S innecesarias.

Cosas para examinar

Índices no utilizados

Todos conocemos el poder de un índice. Tener los índices adecuados puede hacer años luz de diferencia en la velocidad de consulta. Sin embargo, ¿cuántos de nosotros mantenemos continuamente nuestros índices más allá de la reconstrucción y reorganización de índices? Es importante ejecutar regularmente un script de índice para evaluar qué índices se están utilizando realmente. Yo personalmente uso las consultas de diagnóstico de Glenn Berry para hacer esto.

Se sorprenderá al descubrir que algunos de sus índices no se han leído en absoluto. Estos índices son una carga para los recursos, especialmente en una tabla altamente transaccional. Cuando mire los resultados, preste atención a aquellos índices que tienen un alto número de escrituras combinado con un bajo número de lecturas. En este ejemplo, puede ver que estoy desperdiciando escrituras. El índice no agrupado se ha escrito 11 millones de veces, pero solo se ha leído dos veces.

Comienzo deshabilitando los índices que pertenecen a esta categoría y luego los descarto después de confirmar que no han surgido problemas. Hacer este ejercicio de forma rutinaria puede reducir en gran medida las escrituras de E/S innecesarias en su sistema, pero tenga en cuenta que las estadísticas de uso en sus índices son tan buenas como el último reinicio, así que asegúrese de haber estado recopilando datos durante un ciclo comercial completo antes de cancelar. un índice como "inútil".

Índices faltantes

Los índices faltantes son una de las cosas más fáciles de arreglar; después de todo, cuando ejecuta un plan de ejecución, le dirá si no se encontraron índices, pero eso hubiera sido útil. Pero espera, espero que no estés simplemente agregando índices arbitrariamente basados ​​en esta sugerencia. Hacer esto puede crear índices duplicados e índices que pueden tener un uso mínimo y, por lo tanto, desperdiciar E/S. Una vez más, volviendo a los scripts de Glenn, nos brinda una gran herramienta para evaluar la utilidad de un índice al proporcionar búsquedas de usuarios, impacto de usuarios y número de filas. Preste atención a aquellos con lecturas altas junto con bajo costo e impacto. Este es un excelente lugar para comenzar y lo ayudará a reducir la E/S de lectura.

Conversiones implícitas

Las conversiones implícitas a menudo ocurren cuando una consulta compara dos o más columnas con diferentes tipos de datos. En el siguiente ejemplo, el sistema tiene que realizar operaciones de E/S adicionales para comparar una columna varchar(max) con una columna nvarchar(4000), lo que conduce a una conversión implícita y, en última instancia, a una exploración en lugar de una búsqueda. Al arreglar las tablas para que tengan tipos de datos coincidentes, o simplemente al convertir este valor antes de la evaluación, puede reducir en gran medida la E/S y mejorar la cardinalidad (las filas estimadas que debe esperar el optimizador).

dbo.table1 t1 JOIN dbo.table2 t2 
  ON t1.ObjectName = t2.TableName

Jonathan Kehayias entra en muchos más detalles en esta gran publicación:"¿Qué tan caras son las conversiones implícitas del lado de la columna?"

Funciones

Una de las cosas más evitables y fáciles de solucionar con las que me he encontrado y que ahorra gastos de E/S es eliminar funciones de las cláusulas where. Un ejemplo perfecto es una comparación de fechas, como se muestra a continuación.

CONVERT(Date,FromDate) >= CONVERT(Date, dbo.f_realdate(MyField))
AND 
(CONVERT(Date,ToDate) <= CONVERT(Date, dbo.f_realdate(MyField))

Ya sea en una declaración JOIN o en una cláusula WHERE, esto hace que cada columna se convierta antes de que se evalúe. Simplemente convirtiendo estas columnas antes de la evaluación en una tabla temporal, puede eliminar un montón de E/S innecesarias.

O, mejor aún, no realice ninguna conversión (para este caso específico, Aaron Bertrand habla aquí sobre evitar funciones en la cláusula where, y tenga en cuenta que esto aún puede ser malo a pesar de que la conversión a la fecha se puede sargable).

ETL

Tómese el tiempo para examinar cómo se cargan sus datos. ¿Está truncando y recargando tablas? ¿Puede implementar la replicación, una réplica AG de solo lectura o el trasvase de registros en su lugar? ¿Se están leyendo realmente todas las tablas que se escriben? ¿Cómo estás cargando los datos? ¿Es a través de procedimientos almacenados o SSIS? Examinar cosas como esta puede reducir drásticamente la E/S.

En mi entorno, descubrí que estábamos truncando 48 tablas al día con más de 120 millones de filas cada mañana. Además de eso, cargábamos 9,6 millones de filas por hora. Puede imaginar cuántas E/S innecesarias creó. En mi caso, implementar la replicación transaccional fue mi solución preferida. Una vez implementado, tuvimos muchas menos quejas de usuarios sobre ralentizaciones durante nuestros tiempos de carga, que inicialmente se habían atribuido a la lentitud del almacenamiento.

Ordenar por y agrupar por

Pregúntese, ¿se deben devolver esos datos en orden? ¿Realmente necesitamos agrupar en el procedimiento, o podemos manejar eso en un informe o aplicación? Las operaciones Ordenar por y Agrupar por pueden hacer que las lecturas se desborden en el disco, lo que genera E/S adicionales en el disco. Si estas acciones están justificadas, asegúrese de tener índices de apoyo y estadísticas actualizadas sobre las columnas que se ordenan o agrupan. Esto ayudará al optimizador durante la creación del plan. Dado que a veces usamos Ordenar por y Agrupar por en tablas temporales. asegúrese de tener activada la creación automática de estadísticas para TEMPDB, así como sus bases de datos de usuario. Cuanto más actualizadas estén las estadísticas, mejor cardinalidad puede obtener el optimizador, lo que da como resultado mejores planes, menos derrames y menos E/S.

Ahora Group By definitivamente tiene su lugar cuando se trata de agregar datos en lugar de devolver un montón de filas. Pero la clave aquí es reducir la E/S, la adición de la agregación se suma a la E/S.

Resumen

Estas son solo la punta del iceberg de las cosas que hacer, pero son un excelente lugar para comenzar a reducir la E/S. Antes de culpar al hardware de sus problemas de latencia, eche un vistazo a lo que puede hacer para minimizar la presión del disco.

Sobre el autor