¿Qué pasaría si se tomara la molestia de implementar o actualizar a un nuevo SQL Server para una mejor experiencia para sus clientes y se quejaran de que las cosas en realidad estaban peor?
¿No se quejaría si pasara por todos esos obstáculos comerciales y técnicos para obtener un mejor rendimiento de SQL Server y luego no lo hiciera?
Tal vez debería haber realizado algunas pruebas de rendimiento de SQL Server antes de entrar en producción. Entonces sabría si su rendimiento mejoraría, se mantendría igual o, lo peor de todo, disminuiría.
Pero al menos no te habrías sorprendido desagradablemente.
El puente de rendimiento de SQL Server que todos cruzamos
Ya sea que esté cambiando de alguna otra base de datos a SQL Server o actualizando de una versión anterior de SQL Server a una más nueva, finalmente tuvo que cruzar el puente de rendimiento.
"¿Realmente va a funcionar mejor que antes?" preguntó tu jefe.
"Oh, claro", dijiste. “Con la virtualización de datos en SQL Server 2019, podemos ejecutar consultas sin mover ni replicar datos. Y hay un ajuste automático con Intelligence Query Processing para ampliar las consultas. Los datos van a VOLAR fuera de los servidores”. Tenías tanta confianza que escribiste "FLY" con mayúscula.
Entonces, ¿cómo podrías haber probado mejor tu desempeño?
4 formas de evaluar el rendimiento . . .
Brent Ozar, extraordinario experto en SQL Server, le dice cómo comprobar el rendimiento en un nuevo SQL Server:
- la manera fácil, comparando tiempos anteriores y posteriores en una copia de seguridad completa y CHECKDB
- la manera fácil pero incorrecta, con una carga de trabajo sintética y TPC-C en HammerDB
- la forma más difícil, probando consultas individuales con sp_BlitzCache, su secuencia de comandos de análisis de caché de planes
- de la manera realmente difícil, ejecutando las mismas consultas que ejecuta en producción
Pero como deja en claro Brent, monitorear el rendimiento de su servidor SQL y descubrir que ha disminuido en un X por ciento es solo el comienzo; todavía tienes que averiguar de dónde viene el golpe.
Eso significa buscar tendencias en los datos de rendimiento durante semanas y meses completos, no solo durante las últimas horas.
Cuantos más puntos de datos e historial tenga, mejor será la imagen que pueda reunir de lo que sucede dentro, debajo y alrededor de su entorno de SQL Server.
Y cuanto más cómputo pueda arrojar a todos esos datos, más rápido podrá analizarlos.
Supervisión del rendimiento de SQL Server:suena como un trabajo para la nube
Sí. Es un trabajo para la nube, el único lugar donde puede escalar lo suficiente para recopilar y analizar todos esos datos para obtener una imagen amplia y profunda de cómo SQL Server consume recursos. Y cómo ha ido consumiendo esos recursos a lo largo del tiempo. Por ejemplo:
- En determinados momentos del día o del mes, las consultas que se ejecutan con frecuencia tienen que leerse del disco en lugar de la memoria caché del búfer, que es la copia en memoria de las páginas de la base de datos usadas recientemente. ¿Necesita asignar más memoria a su caché de búfer? ¿Puedes prescindir de más memoria para ello?
- Lo mismo para la esperanza de vida de la página. Si es bajo, probablemente se deba a que SQL Server está expulsando páginas del caché del búfer con demasiada frecuencia y tiene que ejecutar búsquedas desde el almacenamiento en lugar de desde la memoria. Eso dificulta el rendimiento.
- ¿El tiempo máximo de espera de E/S es demasiado alto? ¿Cómo es tendencia? Esa es una pista de que el dispositivo de E/S puede estar saturado.
- ¿Cuánto dura la cola del procesador ahora? ¿Cuánto tiempo suele ser? Demasiados subprocesos en espera constante pueden indicar una congestión del procesador.
- ¿La CPU se ejecuta contra los límites que puede manejar su servidor? ¿Qué sucede si ya no puede escalar el servidor? Si está seguro de que sus consultas están bien ajustadas y que sus otros recursos del sistema son adecuados, es posible que deba agregar un socket para hardware físico o vCPU a sus máquinas virtuales.
- Los índices fragmentados son índices lentos, pero no sabe que son los culpables hasta que verifica los niveles de fragmentación. Ver los efectos de la reorganización y la reconstrucción a lo largo del tiempo puede ayudarlo a implementar un proceso confiable de mantenimiento de índices.
Encontrar problemas como esos en todas sus bases de datos locales y en la nube se vuelve más fácil y rápido cuando puede monitorear el rendimiento de su servidor SQL desde la nube. Lo mejor de todo es que puede monitorear desde cualquier lugar de la galaxia conocida cuando toda la computación, el almacenamiento y el análisis están en la nube y está a solo unos clics de distancia en cualquier navegador.
Empiece a probar el rendimiento de su SQL Server en la nube
En Quest, nadie necesita decirnos dos veces que nuestros clientes quieren herramientas basadas en la nube, ya sea para migración a la nube, monitoreo de rendimiento u Office 365. Estamos haciendo que más de nuestros productos estén disponibles como ofertas en la nube porque las tecnologías y los mercados los atraen allí.
Entonces, ¿cómo ejecuta las pruebas de rendimiento en sus servidores SQL nuevos o actualizados?
- Ejecuto CHECKDB.
- Yo ejecuto HammerDB.
- Uso las herramientas de Brent Ozar.
- Pruebo con cargas de trabajo de producción.
- Lanzo los dados y espero hasta que los usuarios se quejen.
- Tengo gente que hace eso por mí.
- Uso Spotlight Cloud de Quest. Tú también deberías.
