Como bien sabe cualquiera que administre bases de datos, el ajuste del rendimiento de SQL Server es una función fundamental para garantizar un rendimiento óptimo. Dado que el rendimiento depende de varios factores, como la memoria, la configuración, el diseño de consultas y el uso de recursos, aislar la causa raíz de la degradación del rendimiento no es tarea fácil.
En lugar de esperar a que ocurran problemas de rendimiento, el ajuste proactivo de SQL Server garantizará que sus declaraciones de SQL se ejecuten de la manera más eficiente posible al ayudar a SQL a encontrar la ruta más rápida de entrada y salida para entregar los resultados de su consulta.
Si tiene problemas con el rendimiento lento, o no es de los que espera a que surjan problemas, aquí hay tres áreas clave para enfocar su ajuste de rendimiento de SQL Server para lograr un rendimiento óptimo y sistemas más saludables.
Consejo n.º 1:optimice su TempDB
TempDB configurado incorrectamente es un culpable común cuando se observa la degradación del rendimiento. Si llena con frecuencia su TempDB, es hora de echar un vistazo a lo que debe cambiar.
Primero, verifique el tamaño de TempDB. No existe una regla estricta sobre qué tan grande debe ser, pero una buena regla general es mantener TempDB en el 25 por ciento de su base de datos más grande o en el mismo tamaño que su índice más grande. Esto evita tener que aumentar TempDB durante las reconstrucciones.
Con TempDB, cuanto más rápido sea el disco, mejor. Cuando TempDB se coloca en una unidad lenta o en la misma unidad que el sistema operativo, seguramente verá problemas de rendimiento de la base de datos. Si es posible, mantenga TempDB en un SSD local dedicado. Si eso no es posible, su siguiente mejor opción es mantenerlo en su propio volumen dedicado con suficiente espacio en disco preasignado.
También es importante mantener los datos y los archivos de registro separados y establecer un valor fijo grande para el crecimiento automático de TempDB. De lo contrario, se verá afectado por una sobrecarga innecesaria cada vez que TempDB se llene.
Controlar la cantidad de archivos de datos de TempDB contribuye a la optimización de TempDB. Pero la gran pregunta es, ¿cuántos archivos de datos TempDB necesita? Idealmente, tendrá un archivo de datos TempDB para cada CPU lógica, pero no más de ocho en total (con algunas excepciones). Por ejemplo, si tiene cuatro CPU lógicas, necesita cuatro archivos de datos TempDB. Si tiene 12 CPU lógicas, puede tener ocho archivos de datos TempDB.
Consejo n.º 2:evitar cuellos de botella en el rendimiento
Hay tres tipos principales de cuellos de botella en el rendimiento de SQL Server que contribuyen a un bajo rendimiento:CPU, memoria y E/S. Las causas, los síntomas y el diagnóstico difieren según el tipo de cuello de botella, por lo que aquí hay una guía de un vistazo sobre lo que hay que tener en cuenta:
Cuellos de botella en la CPU
Causa: Recursos de hardware insuficientes
Métricas a monitorear: % de tiempo de procesador, solicitudes por lotes por segundo, compilaciones de SQL por segundo y recompilaciones de SQL por segundo
Cuellos de botella de memoria
Causa: Limitaciones en la memoria disponible y la presión de la memoria causada por SQL Server, el sistema u otra actividad de la aplicación
Síntomas: Capacidad de respuesta lenta de la aplicación, ralentización general del sistema y bloqueos de la aplicación
Métricas a monitorear: Memoria disponible (KB), Memoria total del servidor (KB), Memoria del servidor de destino (KB), Páginas/seg., Páginas de puntos de control/seg., Escrituras diferidas/seg. y Tasa de aciertos de caché de búfer
Cuellos de botella de E/S
Causa: Lectura y escritura excesivas de páginas de bases de datos desde y hacia el disco
Métricas a monitorear: Promedio de longitud de cola de disco, promedio de segundos de disco/lectura, promedio de segundos de disco/escritura, % de tiempo de disco, promedio de lecturas de disco/segundo y promedio de escrituras de disco/segundo
Consejo n.º 3:asegúrese de que los índices estén diseñados correctamente
Los índices son una excelente manera de acelerar ciertas operaciones de SQL Server, pero solo si están bien diseñados. Los índices mal diseñados tienen el efecto contrario y son una forma segura de reducir el rendimiento de SQL Server.
La configuración adecuada de estas cuatro áreas puede ayudar a garantizar que los índices estén diseñados correctamente y ayuden en lugar de perjudicar el rendimiento de SQL Server.
Tamaño de la mesa
No todas las tablas son buenas candidatas para la indexación. De hecho, si una tabla es demasiado pequeña, es mucho más eficiente para SQL Server buscar en toda la tabla en lugar de tener que buscar en los índices. Por supuesto, lo contrario es cierto para las tablas grandes, por lo que debe sopesar los posibles gastos generales al decidir qué tablas se beneficiarían de los índices.
Tipos de índice
Técnicamente, cada tabla de base de datos puede tener un índice agrupado y una cantidad infinita de índices no agrupados, pero ya sabes lo que dicen sobre "Solo porque puedes hacer algo"...
Demasiados índices no agrupados pueden ralentizar significativamente las operaciones de inserción y actualización, por lo que ceñirse a un índice agrupado y la cantidad mínima de índices no agrupados absolutamente esenciales es una opción de diseño mucho mejor.
Almacenamiento de índice
Durante la fase de diseño, la selección de los criterios de almacenamiento adecuados para los índices es fundamental para el rendimiento de E/S. Los índices agrupados particionados y los índices no agrupados se pueden almacenar en el mismo grupo de archivos que la tabla principal, o se pueden almacenar en un grupo de archivos diferente. El almacenamiento de un índice no agrupado en un grupo de archivos ubicado en una unidad de disco diferente puede mejorar el rendimiento de las consultas que lo utilizan, ya que no se ve afectado por la lectura simultánea de los datos y las páginas de índice SQL que se producen en diferentes unidades de disco.
FACTOR DE RELLENO
FILLFACTOR especifica el porcentaje de espacio que se llenará en cada página de datos al crear un índice. Los valores de FILLFACTOR pueden variar desde 0 por ciento (ninguna página de datos está llena) a 100 por ciento (la página de datos está completamente llena). Al diseñar su índice, seleccione un valor de FILLFACTOR que optimizará el uso de la página y minimizará el riesgo de una fragmentación excesiva del índice.
Hacer que el ajuste del rendimiento de SQL Server sea parte de su rutina estándar es una excelente manera de garantizar que sus bases de datos funcionen al máximo rendimiento. La incorporación de estos tres sencillos pasos en sus planes regulares de mantenimiento de SQL Server mejorará notablemente la velocidad y el rendimiento para sus usuarios.
