Hay muchos factores que influyen cuando se trata del rendimiento de la base de datos. Conocer las fluctuaciones normales de su instancia particular al monitorear su servidor SQL lo ayuda a identificar cuándo el comportamiento tiende a salirse de control y a anticipar los problemas antes de que ocurran.
También le ayuda a distinguir entre los dolores de crecimiento naturales causados por el aumento de la carga de trabajo o los picos estacionales que pueden requerir más recursos y los problemas de rendimiento más profundos que requieren el ajuste del código, la optimización del índice o el ajuste de la configuración.
Una vez que haya establecido una lista de servidores SQL en su entorno, querrá hacer algunas preguntas críticas:
- ¿Qué tan saludable es esta instancia?
- ¿Cuándo fue la última vez que se realizó una copia de seguridad?
- ¿Tiene suficiente CPU, memoria y almacenamiento para cumplir con su SLA?
- ¿Qué tipo de cargas de trabajo se ejecutan en esta instancia?
- ¿Qué aplicaciones y usuarios usan esta instancia?
- ¿Cuándo está más ocupada la carga de trabajo?
- ¿Existe una estrategia de conmutación por error?
- ¿Es esta una instancia de misión crítica?
- ¿Es necesario que esté disponible las 24 horas del día, los 7 días de la semana?
- ¿Qué tipo de desafíos de rendimiento tiene esta instancia?
Estas pueden parecer preguntas obvias, pero si comienza a monitorear las cargas de trabajo de su servidor SQL por primera vez, se sorprenderá y posiblemente se horrorizará un poco al ver cuántos de ellos tienen problemas fundamentales.
Establecer objetivos de rendimiento para la supervisión de SQL Server
Piense en lo que quiere lograr con sus esfuerzos de monitoreo del servidor SQL y priorice estos objetivos. Al enmarcar sus actividades en términos de indicadores clave de rendimiento, facilita la articulación del valor de la energía y las inversiones necesarias. La siguiente lista lo ayudará a comenzar.
Alta disponibilidad
¿Cuáles son sus estadísticas de disponibilidad? Recuerda que la indisponibilidad para el usuario es cuando no puede acceder al servicio. Esto puede deberse a una interrupción total o a un cuello de botella en el rendimiento que hace que el servicio no esté disponible. ¿Tiene una configuración siempre activa? Si es así, ¿conoces su estado?
Tiempo de respuesta
Desde el momento en que se informa un problema, ¿qué tan rápido puede aislar la fuente, diagnosticar los síntomas y responder a los afectados?
Tiempo de resolución
¿Qué tan rápido puede resolver el síntoma para restaurar el funcionamiento normal? La solución del “yeso pegajoso” es un comienzo importante, pero no debe representar el final del asunto. ¿Ha explorado la causa raíz del problema? ¿Puede estar seguro de que no volverá a ocurrir?
Comprensión del costo de propiedad de sus instancias de SQL Server
El costo de propiedad es un factor crítico al decidir dónde deben residir las instancias de su servidor SQL. Es importante medir los costos de inversión iniciales asociados con la infraestructura y las licencias, los costos continuos de mantenimiento y cualquier costo basado en el consumo asociado con una carga de trabajo basada en la nube.
Si está tratando de decidir cuánto costará su instancia en la nube, las métricas críticas incluyen el uso de la CPU, la actividad de lectura y escritura y el almacenamiento. Deberá medirlos durante un período prolongado para determinar los límites de su carga de trabajo y asegurarse de que cuenta con los recursos para el espectro de carga de trabajo que espera para una instancia en particular.
Familiarizarse con las características particulares de las cargas de trabajo que se ejecutan en las instancias de su servidor SQL lo colocará en un lugar mucho mejor para asegurarse de que todo siga funcionando como debería y para satisfacer las necesidades actuales y futuras de su negocio.
Estudie el rendimiento a lo largo del tiempo con SQL Server Monitoring
Las bases de datos son sistemas fluidos. Muy pocos tienen cargas de trabajo constantes, repetitivas y predecibles. Es mucho más común ver amplias variaciones a lo largo del tiempo que fluctúan según la cantidad de usuarios, trabajos automatizados, cantidad de transacciones, volumen de datos, etc.
Una base de datos de ventas estará ocupada a fin de mes. También verá un aumento en la actividad en torno a eventos de temporada o impulsado por promociones de marketing.
Clasificar su rendimiento en función de pequeñas instantáneas no es una buena política. Cuanto más historial pueda recopilar y analizar, más información podrá obtener sobre las variaciones y los límites de cada una de las características de sus cargas de trabajo.
Deberá juzgar cuánto historial es práctico conservar y si tiene los recursos para procesarlo. Hay implicaciones de costo y rendimiento a considerar.
Obtenga la imagen completa para el monitoreo de su base de datos
Cada base de datos es un sistema complejo con muchas partes móviles. Muchos criterios de configuración pueden afectar su rendimiento.
El diseño y la arquitectura de la propia base de datos influirán en los resultados. La eficiencia del código también puede hacer o deshacer el rendimiento. Las opciones de configuración determinarán cómo la instancia del servidor SQL consume los recursos disponibles.
Considere el siguiente escenario:una instancia se está deteniendo y el DBA detecta un pico en la espera de CXPACKET o CXCONSUMER. La reacción instintiva es cerrar el paralelismo. Las esperas desaparecen y el cuello de botella actual se alivia temporalmente. Ahora toda la instancia se ejecuta más lentamente, pero el DBA no quiere volver a habilitar el paralelismo. Si se hubiera realizado una investigación adicional, habría revelado que una consulta se estaba ejecutando de manera particularmente lenta y que la causa era la falta de un índice.
Supervisar muchas métricas diferentes en paralelo ayuda a identificar con precisión la causa raíz y evitar costosos diagnósticos erróneos que pueden causar una repetición o incluso una escalada del mismo problema.
