Mantener instancias de SQL Server de alto rendimiento es una gran parte de las responsabilidades laborales de un DBA. La falta de detección y corrección de actividades inusuales puede afectar las operaciones internas y dañar los resultados de la empresa.
Si nota cambios en la actividad máxima o anomalías en una instancia de SQL Server, aquí hay tres lugares para comenzar su búsqueda de respuestas.
Esperanza de vida de la página
La esperanza de vida de la página (PLE) de una instancia debe mantener un rango de valores bastante consistente. Si ese valor cae y permanece bajo, es una señal de que el grupo de búfer está experimentando una mayor demanda.
Antes de agotar y aumentar la memoria, eche un vistazo a la actividad de la carga de trabajo. Si la carga de trabajo ha aumentado, eso explicaría la presión adicional sobre el grupo de búfer. Pero si la carga de trabajo no ha cambiado, deberá mirar más de cerca para identificar qué está usando la memoria adicional.
Las posibles razones de una caída en PLE incluyen trabajos de mantenimiento en ejecución activa, reconstrucciones de índices o actualizaciones de estadísticas, operaciones DBCC y cambios en el plan de consulta.
Si nota una caída en el PLE que no está asociada con un aumento en la carga de trabajo, hay algunas cosas que puede intentar para mejorar el PLE de una instancia:
- Eliminar índices no utilizados
- Fusionar índices duplicados
- Cuidado con las consultas importantes
- Desfragmentar
- Purgar datos
Tiempo de espera de REGISTRO DE ESCRITURA
Cuando el tiempo de espera de WRITELOG es una proporción demasiado grande del tiempo de espera total, probablemente tenga un cuello de botella en su instancia de SQL Server. Es probable que el cuello de botella se deba a un problema en el disco donde se almacena el registro de transacciones o a que los datos se hayan confirmado de manera ineficiente.
Para determinar con qué tipo de cuello de botella está lidiando, comience analizando la cantidad de declaraciones SQL que esperan el evento WRITELOG. Si hay muchas declaraciones en espera, tiene un cuello de botella en el disco. Si solo hay unas pocas instrucciones en espera, es probable que los datos se confirmen con demasiada frecuencia.
Hay varias formas de resolver el tiempo de espera alto de WRITELOG una vez que haya averiguado si su cuello de botella está relacionado con el disco o con la confirmación:
- Agregue ancho de banda de E/S al disco donde se almacena el registro de transacciones
- Mover la E/S del registro que no es de transacciones desde el disco
- Mueva el registro de transacciones a un disco menos ocupado
- Reducir el tamaño del registro de transacciones
- Asegúrese de que la instrucción COMMIT esté incluida en el código para que los datos no se confirmen con demasiada frecuencia
TempDB
TempDB es un espacio de trabajo temporal en SQL Server que contiene objetos temporales. Debido a que los objetos contenidos en TempDB son transitorios, una instancia de SQL Server recrea TempDB cada vez que se reinicia. Esto hace que la optimización de TempDB sea fundamental para mantener el rendimiento y evitar cuellos de botella operativos.
La contención de TempDB es uno de los principales culpables de la degradación del rendimiento. La contención ocurre cuando múltiples recursos necesitan acceso a TempDB pero solo hay un archivo de datos de TempDB. Esto provoca un cuello de botella porque los procesos no pueden acceder a TempDB lo suficientemente rápido, lo que provoca que se agote el tiempo de espera de las conexiones y que se desasignen los procesos.
Afortunadamente, los cuellos de botella de TempDB se pueden resolver con bastante facilidad ajustando la cantidad y el tamaño de los archivos de TempDB. Tras la instalación, el valor predeterminado de SQL Server es un archivo de datos TempDB. Si nota que se produce una contención, se recomienda que agregue ocho nuevos archivos de datos y determine si eso soluciona el problema. Si el problema no se resuelve, intente agregar archivos de datos adicionales en múltiplos de cuatro hasta que se restablezca el rendimiento.
Si bien es bueno saber dónde comenzar a buscar cuando experimenta problemas de rendimiento, cada uno de los problemas anteriores y los cuellos de botella resultantes podrían mitigarse o evitarse por completo al implementar una regla estricta y rápida:monitorear las métricas de rendimiento no es opcional. Estos son algunos ejemplos de métricas clave para realizar un seguimiento:
Esperanza de vida de la página:haga un seguimiento de PLE con monitoreo continuo y sea proactivo cuando caiga y permanezca por debajo del valor típico para una instancia de SQL Server en particular.
Tiempos de espera de WRITELOG:controle métricas como el crecimiento del registro, la reducción del registro, el porcentaje de registro utilizado y las esperas por segundo para vaciar el registro.
Ineficiencia de TempDB:Supervise lo que se asigna a los objetos de usuario, el almacén de versiones o los objetos internos. Realice un seguimiento de su tendencia a lo largo del tiempo, luego determine qué sesiones consumen TempDB y cuánto.
Existen en el mercado algunas excelentes herramientas de supervisión del rendimiento de SQL Server asequibles y ricas en funciones que pueden ayudarlo a mantenerse al frente de los problemas que degradan el rendimiento. Conviértase en el DBA MVP de la empresa mediante la investigación proactiva de soluciones que mantengan tanto las operaciones internas como los servicios comerciales externos funcionando al máximo rendimiento.
