"Doc, me preocupa el rendimiento de mi SQL Server".
No era el tipo de cosas que escuchas de la mayoría de los pacientes. Pero claro, como profesional remunerado, he sido capacitado para manejarlo todo, incluso los momentos difíciles de ser administrador de una base de datos.
"¿En realidad? Exploremos eso, ¿de acuerdo?”
“Claro, doctora. Quiero decir, a veces se siente tan abrumador. Pensé que todo se solucionaría por sí solo una vez que me comprometiera. Pero antes de darme cuenta, comencé a tener problemas de rendimiento en SQL Server 2012, luego en 2014 y luego en 2017. Ni siquiera quiero pensar en SQL Server 2019”.
"Ya veo. Bueno, una buena relación con SQL Server no sucede por sí sola. Tienes que trabajar en eso. Dígame, ¿ha trabajado en sus técnicas de ajuste de rendimiento de SQL Server?”
“Eh, no, doctor. Realmente no conozco ninguna de esas técnicas”.
"No te preocupes. Podemos trabajar en ellos. Su SQL Server probablemente se sienta descuidado. Tienes que vigilarlo para asegurarte de estar a la vanguardia del juego. Eso requiere la supervisión de SQL Server”.
"¿Vigilancia? ¿Cómo haces eso?”
“Tienes que demostrarle a SQL Server que te importa. Hay que prestar atención a ciertas métricas. También podemos trabajar en eso”.
“Está bien, doctor. Lo que digas. Estoy dispuesto a intentar cualquier cosa en este punto. Las cosas no podrían empeorar mucho más de lo que están ahora”.
"Bien entonces. Vamos a empezar."
Métricas de rendimiento de SQL Server:muchas partes móviles
El paciente tenía razón:monitorear el rendimiento de SQL Server puede resultar abrumador. No puedes dejar de prestarle atención una vez que está en funcionamiento. Tienes que seguir mostrándole que te importa.
SQL Server tiene muchas partes móviles que generan métricas constantemente. Saber cuáles ver y luego tomarse el tiempo de su ajetreado día para monitorearlos puede ser mucho trabajo para un DBA.
Así que analicé algunas de las áreas principales de las métricas de rendimiento de SQL Server con el paciente.
Índices
Uno de los primeros lugares en los que buscar cuando tiene problemas de rendimiento con SQL Server son los índices. Sus datos siempre crecen, por lo que sus índices también crecen constantemente. Pero están sujetos a condiciones como la fragmentación y las divisiones de página que pueden ralentizar la respuesta a las consultas.
¿Qué sucede en una base de datos día tras día? Los usuarios están creando, editando y eliminando registros. Los índices siguen donde están todas las partes de los registros, pero con el tiempo, la fragmentación del índice dificulta el rendimiento.
Luego está el factor de relleno del índice, un parámetro que puede configurar en SQL Server para controlar la cantidad de divisiones de página y aumentar la eficiencia de las consultas. Pero el equilibrio entre más y menos divisiones de página afecta el rendimiento de otras formas.
Ver métricas en factor de relleno , E/S y fragmentación es una buena manera de mantener sus dedos en el pulso de la salud del índice de SQL Server.
Caché de búfer
Hagamos esto simple:Disco, lento; caché de búfer, rápido. La memoria caché del búfer es una copia en memoria de las páginas de la base de datos usadas recientemente. Si SQL Server no encuentra lo que está buscando allí, entonces tiene que ir al disco para buscarlo, lo que ralentiza el rendimiento.
SQL Server le permite especificar la cantidad de memoria del sistema para asignar a la memoria caché del búfer, pero la compensa con la memoria restante para otras tareas. Su objetivo es asignar todo lo que pueda sin obstaculizar el rendimiento de SQL Server en otras áreas.
También es importante la esperanza de vida de la página, la cantidad de tiempo que una página de información de la base de datos pasa en el búfer sin que se vuelva a acceder a ella. SQL Server expulsa continuamente páginas de la memoria caché del búfer para dejar espacio para las utilizadas más recientemente. Pero cuantas menos páginas útiles encuentre allí, más tendrá que leer del disco, lo que ralentiza el rendimiento.
Métricas como esperanza de vida de la página y proporción de aciertos exitosos en la memoria caché del búfer ayudarlo a tomar decisiones sobre desalojar páginas con menos frecuencia o aumentar el tamaño del caché.
T-SQL
SQL Server utiliza un lenguaje de consulta llamado T-SQL. En lugar de ejecutar sentencias SQL ad hoc, SQL Server intenta mejorar el rendimiento al procesarlas por lotes, compilarlas como un plan de ejecución y almacenarlas en caché. También intenta minimizar la frecuencia de compilación y reutilizar los planes de ejecución con la mayor frecuencia posible. Si no puede reutilizar el plan de ejecución, por ejemplo, porque la base de datos ha cambiado demasiado, volverá a compilar el plan. Es mejor mantener el número de recompilaciones de instrucciones SQL lo más bajo posible, ya que el proceso puede consumir grandes cantidades de CPU y degradar el rendimiento.
La necesidad de compilar y volver a compilar es una función de las buenas prácticas de codificación, como el uso de procedimientos almacenados y la parametrización de consultas. DBA que supervisan métricas como la tasa de compilaciones de SQL y recompilaciones de SQL puede modificar las sugerencias de consulta de SQL Server para mejorar el rendimiento.
Bloqueos, esperas y procesos bloqueados
Es frustrante descubrir que alguien más está modificando algo al mismo tiempo que tú. Por lo tanto, las bases de datos bloquean automáticamente cosas como filas y tablas para mantener a varios cocineros fuera de la cocina. La compensación por esa protección, por supuesto, es que todos los demás usuarios deben esperar hasta que se desbloquee el recurso. Y es difícil asegurarse de que el bloqueo se lleve a cabo solo en el nivel necesario.
Con métricas que muestran con qué frecuencia y en qué medida los bloqueos afectan a otras operaciones, los administradores de bases de datos pueden determinar la necesidad de más recursos físicos del sistema para procesar las transacciones con mayor rapidez. También puede ser que SQL Server se bloquee a un nivel innecesariamente bajo. La frecuencia de las esperas de bloqueo y, más ampliamente, el número de procesos bloqueados puede ayudar a localizar cuellos de botella.
Elimine los cuellos de botella con el ajuste del rendimiento de SQL
“Dios, Doc, tiene razón sobre todas las partes móviles. Ahora veo cómo no puedo simplemente instalar SQL Server, configurarlo y olvidarlo. Necesito nutrir la relación. Pero todo esto todavía se siente abrumador. ¿Cómo voy a mantener en orden tantas cosas diferentes y mantenerme a la vanguardia?”
"Esa es la mejor parte. Existen herramientas que pueden ayudarlo con el rendimiento de SQL Server. No tienes que hacerlo solo”.
"¡Uf! Eso es tranquilizador. No sabía nada de eso.”
"Así es. Las herramientas monitorean el rendimiento de su servidor SQL e informan todas estas métricas para que pueda aplicar sus técnicas de ajuste y eliminar los cuellos de botella”.
"¿En serio?"
"Por supuesto. Y podemos trabajar en eso bien, oh, no tenemos tiempo para esta semana. Haga una cita con mi recepcionista y lo recogeremos la semana que viene”.
“¡Vaya, esas cuatro horas pasaron rápido, doc! Seguro que el tiempo vuela cuando está resolviendo problemas de rendimiento relacionados con la fragmentación y el uso de recursos. y proporción de aciertos de caché de búfer , ¿no?”
"Sí, y estoy seguro de que una vez que se comunique abiertamente sobre esos problemas con su servidor SQL, todos sus problemas de rendimiento serán historia".
Animado por nuestra sesión, el paciente se fue. La próxima vez, trabajaremos en la supervisión de los cuellos de botella en el rendimiento de SQL Server. Publicaré un blog al respecto, así que estén atentos.
Mientras tanto, confía en mí. Soy un profesional pagado y lo animo a probar estas cosas en su propia relación con su base de datos. Haga que su servidor SQL se sienta deseado. Presta atención a sus métricas de rendimiento.
Nunca es demasiado tarde para intentarlo.
