Incidencias

Ciclo de Vida y Niveles de Soporte de SQL Server

En el mundo de la tecnología si hay algo cierto es la constante evolución. Esto es una realidad ineludible como que si un usuario tiene permisos elevados terminará metiéndonos en un lío. Como buenos DBAs profesionales, nos enfrentamos a la tarea de mantenernos al día con las últimas versiones de SQL Server. Ya hablamos aquí de las actualizaciones de SQL Server pero, ¿qué sucede con las versiones antiguas? ¿Cómo gestionamos su ciclo de vida y los niveles de soporte?

Ciclo de Vida de SQL Server

El ciclo de vida de un producto de software se refiere a las diferentes etapas por las que pasa desde su lanzamiento hasta que deja de recibir soporte. En el caso de SQL Server, el ciclo de vida, se divide en dos fases principales: el soporte principal y el soporte extendido.

Soporte Principal

Durante la fase de soporte principal (mainstream), Microsoft ofrece actualizaciones de seguridad, correcciones de errores y nuevas características. Esta fase dura normalmente 5 años desde la fecha de lanzamiento de la versión.

Soporte Extendido

Una vez concluida la fase de soporte principal, entramos en la fase de soporte extendido. Durante este periodo, que también suele durar 5 años, Microsoft sigue ofreciendo actualizaciones de seguridad, pero ya no se añaden nuevas características ni se realizan correcciones de errores no relacionados con la seguridad. Veremos esto más en profundidad ahora con los niveles de soporte.

Niveles de Soporte para las Versiones de SQL Server

Además del ciclo de vida, es importante entender los niveles de soporte que Microsoft ofrece para las diferentes versiones de SQL Server. Los niveles de soporte se refieren al tipo y alcance del soporte técnico que se proporciona durante las diferentes fases del ciclo de vida de un producto de software. En el caso de SQL Server tenemos tres fases principales: soporte total, limitado y fin de soporte.

Soporte Total

Durante la fase de soporte principal, una versión de SQL Server tiene soporte total. Esto significa que se pueden solicitar todas las formas de soporte, incluyendo la resolución de problemas, la corrección de errores y las actualizaciones de seguridad.

Soporte Limitado (extendido)

En la fase de soporte extendido, el nivel de soporte se reduce a soporte limitado. En este nivel, Microsoft solo proporciona actualizaciones de seguridad y ya no se resuelven problemas ni se corrigen errores que no estén relacionados con incidentes de seguridad.

Fin de Soporte

Finalmente, cuando una versión de SQL Server alcanza el fin de su soporte, ya no se proporcionan actualizaciones de seguridad ni soporte técnico. Aunque es cierto que en casos muy extremos y con incidentes de seguridad de máxima gravedad Microsoft puede hacer excepciones, es crucial planificar la migración a una versión soportada antes de llegar a esta fase. Por ejemplo, me viene a la mente la famosa actualización GDR crítica del 14 de febrero de 2023 que salió para todas las versiones de SQL desde 2008 hasta 2022 aunque las versiones de 2008, 2008 R2 y 2012 estaban fuera de ciclo de vida, en fase de fin de soporte. Como digo, son casos muy excepcionales y la recomendación es no mantener servidores cuando estos han alcanzado el fin de soporte.

Actualizaciones de SQL Server

Como ya vimos en un anterior artículo, las actualizaciones de SQL Server pueden ser Service Packs (SP), Cumulative Updates (CU) o General Distribution Releases (GDR). Estas actualizaciones esenciales que Microsoft lanza para las versiones de SQL Server, aunque no alteran el ciclo de vida general de una versión de SQL Server, tienen su propio ciclo de vida y pueden extender el soporte de una versión específica. Veamos caso a caso como influyen.

Service Packs

Un Service Pack (SP) puede extender el ciclo de vida de una versión de SQL Server. Cuando se lanza un SP, este tiene su propio ciclo de vida, que se extiende más allá del ciclo de vida original de la versión principal. Por ejemplo, aunque SQL Server 2014 ha finalizado su ciclo de vida de soporte principal, el soporte extendido para SQL Server 2014 SP3 sigue activo hasta el 9 de julio de 2024. Esto significa que Microsoft continuará proporcionando actualizaciones de seguridad y soporte técnico para SQL Server 2014 SP3 incluso después de que la versión principal haya alcanzado su fin de soporte hace varios años. Aunque Microsoft dejó de publicar SPs a partir de la versión de SQL Server 2016, como sé que sois mentes intrépidas y con sed de datos, os contaré que estas actualizaciones solo se lanzaban para productos en la fase principal del ciclo de vida de un producto.

Cumulative Updates

Las Cumulative Updates (CU), por otro lado, son actualizaciones más frecuentes que incluyen correcciones de errores y mejoras de rendimiento. Microsoft cambió el modelo de SPs por el CUs, más frecuentes y con menos cambios cada una. Digamos que hasta SQL 2016, Microsoft esperaba a tener una gran actualización para liberar un nuevo SP y, ahora, lo que hace es ir liberando pequeñas actualizaciones pero de manera más frecuente. Todo muy agile, ¿verdad? Esto tiene una implicación directa para nosotros y es que, aunque una CU tiene un ciclo de soporte propio de 1 año a partir de su fecha de lanzamiento, no extiende el ciclo de vida de la versión principal de SQL Server como sí hacían los SPs. Al igual que pasaba con los SPs, las CUs solo se liberan durante la fase principal del ciclo de vida de una versión SQL.

General Distribution Releases

Las General Distribution Releases (GDR) son actualizaciones que se centran principalmente en las correcciones de seguridad. A diferencia de los SP y las CU, las GDR no añaden nuevas características ni mejoras de rendimiento. Sin embargo, son críticas para mantener la seguridad de nuestras bases de datos y, al igual que los SP y las CU, tienen su propio ciclo de vida. Con todo lo que ya hemos visto, habréis podido adivinar que las GDR se lanzan durante todo el periodo de ciclo de vida, tanto principal como extendido siendo las únicas actualizaciones de las que dispondremos fuera del ciclo de vida principal de una versión de SQL Server.

Conclusión

Como profesionales de bases de datos, es esencial que comprendamos el ciclo de vida y los niveles de soporte de las versiones de SQL Server. Esto nos permitirá planificar eficazmente las actualizaciones y garantizar que nuestras bases de datos sigan siendo seguras y eficientes. Recuerda, mantenerse al día no es solo una cuestión de aprovechar las nuevas características, sino también de garantizar la seguridad y la estabilidad de nuestros sistemas. Las actualizaciones, tanto SPs, CUs y GDRs juegan un papel crucial en la gestión del ciclo de vida de SQL Server. Es importante tener en cuenta estos detalles al planificar las actualizaciones y el mantenimiento de nuestras bases de datos. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios

Monitorización con Alertas del Agente en SQL Server

Llegan las vacaciones de semana santa y a todos nos gusta desconectar. Aun así, no debemos descuidar la vigilancia sobre nuestros servidores, sobre todo los más críticos. En el mundo de la informática en general y, de la administración de bases de datos en particular, estar al tanto de lo que sucede en nuestros sistemas es crucial. Una actuación sencilla a tiempo nos puede ahorrar una larga intervención para corregir una incidencia en un futuro. Es por esto que la monitorización nativa de SQL Server a través de las alertas del agente es un aliado fundamental de cualquier DBA. En el mercado existen multitud de herramientas que ofrecen una ventana directa al rendimiento y la salud de nuestras bases de datos pero suelen ser costosas y complejas de implementar, mientras que las alertas de SQL, sin ser la solución definitiva, nos brindan una excelente solución básica pero efectiva.

¿Qué son las Alertas del Agente?

Las alertas del agente son un conjunto de respuestas automatizadas que se activan ante eventos específicos en SQL Server. Estos eventos pueden ser desde un simple rendimiento subóptimo hasta errores críticos que requieren atención inmediata. Este sistema de monitorización vigila nuestro SQL Server en busca de los desencadenadores que hayamos definido y, gracias al correo electrónico de base de datos es capaz de hacernos llegar el aviso.

También dispondremos de una opción para ejecutar automáticamente un job que nos será muy útil en caso de tener automatizado un procedimiento de resolución automático para ciertos eventos controlados.

Monitorización con alertas de SQL Server

La monitorización nativa utiliza herramientas integradas en SQL Server para mantener un ojo vigilante sobre los procesos críticos. Esto incluye el seguimiento de bloqueos, la supervisión del rendimiento de las consultas y la detección temprana de posibles problemas. 

Configuración Óptima para DBAs

Si estamos familiarizados con o tenemos cierta experiencia en SQL Server, configurar alertas del agente es un proceso familiar y sencillo. Sin embargo, es importante ajustar bien los parámetros que las desencadenan para que las alertas sean significativas y proporcionen información valiosa sin saturarnos con falsos positivos. Un exceso de alertas puede llegar a ser igual a no tener alertas ya que corremos el riesgo de terminar perdiendo información sobre incidentes graves entre tanto aviso. 

Caso práctico de configuración de alertas

Las alertas en SQL Server se pueden configurar tanto desde la interfaz gráfica como por script. En el caso de la interfaz gráfica, lo encontraremos colgando del agente de SQL Server en nuestro Management Studio. La ventana de configuración de las alertas tiene este aspecto:

Como veis tenemos un apartado general en el que definiremos el nombre de nuestra alerta y cuál será su desencadenante. Para el tipo “SQL Server error alert”, que es el que más nos interesa, podremos decidir si afecta a una base de datos en concreto o a todas y si se activará por un número de error específico o por todos los que respondan a un nivel de gravedad. También podemos añadir un filtro extra por texto del mensaje. Existen otros tipos de alerta por condiciones de rendimiento o por eventos WMI de Windows. Disponemos también de otros dos apartados en los que configurar la respuesta a estas alertas y sus opciones.

Qué errores monitorizar con alertas

Para poder configurar alertas en base a errores de SQL Server es imprescindible conocer el significado de los niveles de gravedad. Estos niveles van desde el 0 hasta el 25 y se dividen de la siguiente manera. Del 0 al 10 representan mensajes informativos sobre el estado del servidor. Del 11 al 16 son errores que pueden ser corregidos por los usuarios como que un objeto no existe o código SQL mal escrito por ejemplo. A partir de la gravedad 17 si que requerirán nuestra intervención como DBAs y son estos los que os recomiendo monitorizar.

  • Gravedad 17 a 19: Indica errores de software que no pueden ser corregidos por el usuario. Como falta de recursos para completar una consulta.
  • Gravedad 20 a 24: Indica problemas del sistema y son errores irrecuperables, lo que significa que ya no está en ejecución la tarea del motor de base de datos que esté ejecutando una instrucción o lote.
  • Gravedad 25: Error desconocido, aquí irá todo error no controlado por el motor de base de datos.

Además de los errores basados en gravedad yo monitorizo también los códigos de error específicos 823, 824 y 825 que alertan de falta de espacio en disco y el código 1480 que indica un cambio de rol del Always On

¿Os parecen muchas cosas? No os preocupéis, os dejo aquí el script para crear directamente estas alertas:

Conclusión

Con una configuración adecuada y un uso correcto de las alertas del agente, podemos asegurar que nuestros sistemas de bases de datos operen con la máxima eficiencia. La monitorización nativa no es solo una herramienta, es una parte integral de nuestra estrategia proactiva para mantener la salud de SQL Server. Es cierto que, al usar una monitorización en local, se nos escaparán eventos más graves como la caída del propio servidor pero es un buen punto de partida y, sobre todo, es mejor que no tener nada.

Espero que este artículo te haya sido útil y que te ayude a tener mayor control sobre tus servidores SQL Server. Te animo a investigar más y definir nuevas alertas que puedan resultarte interesantes. Una vez hecho, puedes dejarlo en los comentarios y, entre todos, seguro que aprendemos algo nuevo. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 2 comentarios

VLF: Entendiendo el Log de SQL Server nivel pro

En nuestra constante búsqueda de optimización y eficiencia en el manejo de bases de datos, nos encontramos con una pieza clave en el rompecabezas de SQL Server: los Virtual Log Files (VLF). Estos componentes, aunque pequeños y a menudo pasados por alto, son fundamentales para el rendimiento y la gestión de nuestras bases de datos. Hoy, nos sumergimos en el mundo de los VLF para entender su función y cómo una gestión adecuada puede marcar la diferencia en nuestro trabajo diario como DBAs. Referenciando nuestro artículo anterior ¿Cómo funcionan los ficheros de Log de SQL Server?, podemos recordar que el log de transacciones juega un papel vital en la recuperación de datos y, los VLFs, como parte fundamental de los logs, tienen la misma importancia.

¿Qué son los VLF y por qué son importantes?

Los VLF son segmentos virtuales en los que se divide el archivo de log de transacciones de una base de datos en SQL Server. Es decir, SQL Server no trabaja con el fichero de log completo sino con pequeñas particiones del mismo. Cada vez que se crea o se expande un log, SQL Server lo divide en varios VLFs. La cantidad y el tamaño de estos VLF pueden tener un impacto significativo en el rendimiento de la base de datos, especialmente durante operaciones de recuperación y respaldo. En casos extremos, si tenemos el log muy particionado puede afectarnos también al rendimiento de nuestras transacciones. 

Gestión Efectiva de VLF

Para mantener un sistema saludable, es crucial gestionar adecuadamente los VLF. Un número excesivo de VLF pequeños puede causar lentitud en el proceso de recuperación de la base de datos, mientras que muy pocos VLF grandes pueden dificultar el proceso de respaldo. Por ello, encontrar el equilibrio correcto es esencial. Los VLF son los bloques de construcción de este log, y su gestión eficiente permite una recuperación más rápida y una mejor disponibilidad de la base de datos.

Una estrategia efectiva para la gestión de VLF implica monitorear su cantidad y tamaño regularmente. SQL Server proporciona herramientas que nos permiten visualizar y ajustar estos parámetros, como el deprecado comando DBCC LOGINFO o su nueva versión, la función sys.dm_db_log_info. Además, prácticas como el truncamiento regular del log y la expansión controlada del archivo de log ayudan a mantener un número óptimo de VLF.

Creación de VLFs

Hemos visto que el motor de SQL Server crea automáticamente los VLFs durante el crecimiento de los ficheros de logs, sin embargo, esto no significa que nosotros no podamos influir sobre ello. Simplemente tendremos que conocer qué reglas sigue SQL para crear VLFs para adaptarnos a ello. Antes de nada tenemos que especificar que las reglas de creación de VLFs han cambiado con SQL 2022 por lo que tanto para esta versión como para Azure tendremos que tenerlo en cuenta. Veamos cómo se crean los VLFs:

  • Cuando el crecimiento del archivo de log es menor a 64 Mb SQL creará 4 VLFs en versiones antiguas y solo 1 VLF en SQL 2022 y en Azure.
  • Si el crecimiento del archivo de log es igual o mayor a 64 Mb pero menor a 1 Gb se crearán 8 VLFs.
  • Si el crecimiento del archivo de log es igual o mayor a 1Gb se crearán 16 VLFs.

Cuantos VLFs tienen mis logs

Ya sabemos cómo se crean los VLFs y por qué podemos llegar a tener muchos en nuestros mecheros de logs pero, no os he dicho aún cómo comprobar en vuestras bases de datos cuantos VLFs teneis. Para ello usaremos el siguiente script. Y ahora la pregunta clave, ¿Cuántos VLF debería tener? La respuesta es depende, no hay una respuesta universal a esta pregunta. Personalmente creo que sobre 50 es una buena cifra pero dependerá en gran medida del tamaño del fichero de log. 

Hora de hacer números y corregir los VLF

Supongamos que nuestra base de datos tiene un log de 20Gb y hemos visto que por alguna mala práctica del pasado tenemos muchos VLF. Lo primero que tendremos que hacer es un shrink para reducir el log lo máximo posible. Una vez con el log en su tamaño mínimo vamos a volver a dimensionarlo a sus 20Gb originales pero siguiendo las buenas prácticas de VLF. Vamos a crear un número de VLF cercano a 50. Para ello no podemos dimensionar directamente en 20Gb porque solo nos crearía 16 VLF y serían muy grandes para ser administrados por SQL de manera óptima. Qué pasa si aumentamos 8 Gb iniciales, luego otros 8 y terminamos con un crecimiento de 4 Gb. Esto serían 3 crecimientos del fichero superiores a 1 Gb por lo que se nos crearían 16 VLF en cada “salto”, 16*3=48. Parece bastante razonable. Ahora, si el fichero puede necesitar crecer en un futuro, podría ser interesante hacer 3 crecimientos de 8 Gb lo que nos daría 24 Gb de log repartidos igualmente en 48 VLF (unos ficheros de 512 Mb cada uno, algo asumible).

Conclusión

La gestión de VLF no es solo una tarea de mantenimiento; es una oportunidad para maximizar el rendimiento de nuestras bases de datos. Al comprender la importancia de estos elementos y aplicar prácticas de gestión efectivas, podemos asegurar un sistema robusto y ágil. Los VLF son, sin duda, pequeños gigantes en el mundo de SQL Server, y su correcta administración está reservada a unos pocos DBAs expertos con gran pericia técnica, como vosotros ahora.

Espero que este artículo te haya sido útil. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
Un índice que no se usa perjudica el rendimiento de los select

Un índice que no se usa perjudica el rendimiento de los select

¿Alguna vez os han dicho que un índice que no se usa empeora el rendimiento de una consulta SELECT? Todos hemos oído que los índices penalizan la escritura y eso es cierto como que odio madrugar para trabajar pero, las lecturas no se ven afectadas, ¿verdad? ¿Estáis seguros? Recientemente recibí en mi bandeja de entrada el último boletín de la newsletter de SQLAuthority sobre un extraño comportamiento con los índices en SQL Server y me ha parecido tan interesante que he sentido la necesidad de compartirlo con vosotros. Aunque, como os digo, la idea detrás de este post no es mía y es plenamente de Pinal Dave me voy a tomar la libertad de traducirlo y compartirlo con vosotros.

Introducción

Este email que activó mi sentido arácnido:

Hi there,
Have you ever seen that Index which is not used for the query reduces the performance of the SELECT statement?
If yes, good, you can stop reading this email here.
If no, here is the video you MUST WATCH 
That’s it! Have a good day.
~ Pinal from SQL Authority

Cuando lo he leído no me lo podía creer, ¿cómo un índice que no se usa puede empeorar el rendimiento de una consulta de lectura? Sabemos que los índices empeoran los procesos de escritura pero, es justamente porque se usan y se escribe en ellos además de en la tabla. Pero en las lecturas no, eso no es lo que dicen los libros de SQL. Sin embargo, de Pinal me fio completamente (ha demostrado sobradamente saber mucho de esto) así que he ido al video y en efecto, en él demuestra empíricamente lo que dice en el correo.

Tan atónito estaba al terminar los doce minutos de demo de Pinal que he ido raudo a comprobarlo en mi propio servidor de pruebas. En el video, Pinal usa la base de datos AdventureWorks2014 y en las respuestas a los comentarios dice haberlo probado tanto con modo de compatibilidad 2017 como 2019. En mi laboratorio de pruebas yo tengo un 2022 así que perfecto vamos a ver que pasa.

Consulta sin índice

Ejecutamos la consulta sobre la tabla, sin haber creado ningún índice vemos que hace un escaneo de la PK que supone el 42% de la consulta. En cuanto a lecturas, si miramos los mensajes de las estadísticas de E/S vemos que se está leyendo 1238 páginas de disco de 8 Kb, lo que son aproximadamente 10 Mb de datos. Sin embargo para leer esos 10Mb de datos, necesita una tabla auxiliar de la que lee 368.495 páginas o lo que es lo mismo 2,8 Gb de información.

Creemos un índice

Obviamente este rendimiento no es el esperado, leer casi 3 Gb de información para devolver 10 Mb, no sé a vosotros, pero a mi no me parece correcto. Así que creemos un índice llamado IX_1 tal como aprendimos en este otro post y probemos. Vale, tenemos dos lecturas de la tabla y eso no es lo mejor, pero tampoco es un problema. Mirad las estadísticas, tenemos simplemente 610 páginas leídas o lo que es lo mismo, 5Mb de información. 

Creando otro índice

Un caso de uso normal sería ahora crear otro índice invirtiendo el orden de los campos clave para verificar si el rendimiento mejora o no. Sin embargo, al hacerlo, nos vamos a encontrar con la sorpresa que da título a este post. No solo la consulta sigue usando el primero de los índices sino que han vuelto los Table Spool y aunque las páginas leidas de la tabla han bajado a la mitad que antes, tenemos otra vez esos casi 3 Gb de lecturas de la tabla de trabajo. 

Otras pruebas

No os voy a aburrir con más capturas de pantalla, creo que ya lo habéis pillado. Deciros que lo he probado en todos los niveles de compatibilidad posibles de una base de datos desde SQL 2014 hasta 2022 y el resultado ha sido idéntico. 

También he probado con actualizaciones de las estadísticas de la tabla, borrando la caché de planes de ejecución entre las pruebas, con el hint de index para forzarle el uso del índice en las dos ejecuciones y con un hint de RECOMPILE. Todo con el mismo resultado. Para terminar he cambiado la consulta y he usado un join en vez de la subquery pero nada, en todos los casos aparecían esas lecturas al tener el segundo índice creado aunque en el plan de ejecución no aparezca en uso por ningún lado y al borrarlo volvía a los dos escaneos sin lecturas de tablas auxiliares. 

Os diré más, en este punto con ya el artículo escrito se me ha ocurrido una cosa, he borrado el índice 2, he ejecutado la consulta que se ha ejecutado con el plan correcto, he ido a Query Store y he forzado ese plan, luego he creado el índice y, ¿sabéis que? LO HA VUELTO A HACER MAL. Si amigos, incluso forzando en Query Store el plan correcto, SQL me ha sacado el dedo y ha hecho lo peor para él, como un hijo adolescente que no entiende que miras por su bien.

Conclusiones

¿Y ahora que digo yo? ¿Qué conclusión sacamos de esto? Que lo que pone en los libros no es correcto? Igual es que SQL Server hace cosas sin sentido o que visto esto debería pasarme a Oracle? Lo cierto es que no he conseguido encontrar una explicación a lo que está pasando pero ahí está. En su video, Pinal llega al mismo punto, no entiende lo que pasa y obviamente no tiene sentido. Parece un bug del motor de base de datos sin resolver desde hace un montón de tiempo. Por mi parte seguiré probando esto en cada nueva versión de SQL Server y si veo que se resuelve espero poder avisaros por aquí. De momento, no nos queda otra, revisemos los índices de nuestras bases de datos y borremos los que no estén en uso por si nos están penalizando.

Espero que este artículo te haya sido útil y que te ayude a optimizar el rendimiento de tus consultas en SQL Server. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

PD.: Si alguno queréis ir a la fuente original os dejo el vídeo por aquí.

Publicado por Roberto Carrancio en Índices, Rendimiento, SQL Server, 0 comentarios

Controlando el balanceo de nuestro AlwaysOn

En este artículo vamos a hablar de dos configuraciones importantes para el funcionamiento óptimo de un grupo de disponibilidad AlwaysOn en SQL Server: el session timeout y el health check. Estas configuraciones nos permiten controlar cómo y cuándo se produce un balanceo (failover) automático entre los nodos del grupo, y cómo se determina el estado de salud de cada réplica. Si quieres saber más sobre qué es un AlwaysOn y cómo configurarlo, te recomendamos que leas nuestro artículo sobre ello aquí.

Consideraciones de salud de nuestro AlwaysOn

SQL Server pone a nuestra disposición distintas configuraciones sobre el balanceo de nuestro AlwaysOn. Por un lado podemos definir el tiempo que una transacción puede tardar en replicarse antes de considerar que hay un problema con esa réplica y por otro podremos definir el tiempo que tiene que pasar una réplica en un estado crítico para sacarla del grupo de disponibilidad y balancear o detener la replicación. Además podremos definir varios niveles de criticidad admisibles para considerar este escenario.

¿Qué es el session timeout de AlwaysOn?

El session timeout o tiempo de espera de sesión es el tiempo máximo que una sesión puede estar inactiva antes de que nuestro AlwaysOn determine que esa réplica no está accesible. Esto puede ocurrir cuando hay una interrupción en la comunicación entre el cliente y el servidor, o cuando el servidor está muy ocupado y no puede atender las solicitudes del cliente. Esta propiedad se define por cada réplica y representa el tiempo que puede esperar un ping entre ella misma y el nodo principal del clúster.

El valor por defecto del session timeout para un AlwaysOn es de 10 segundos, pero se puede modificar mediante la propiedad “Connection Timeout” de la cadena de conexión, o mediante la propiedad “SessionTimeout” del grupo de disponibilidad (Availability Group) en PowerShell. El valor mínimo es de 5 segundos, y el máximo es de 65535 segundos. Microsoft no recomienda un tiempo inferior a 10 segundos ya que podríamos sufrir falsos positivos cuando un sistema saturado no devuelva el ping a tiempo. Por otra parte, un tiempo muy alto puede provocarnos errores de inconsistencia de datos ya que aunque la réplica secundaria no esté respondiendo, si estamos dentro de ese umbral definido, SQL no va a actuar como si hubiera un error y va a seguir intentando insertar datos.

¿Qué es el health check de AlwaysOn?

El health check es el proceso por el cual el WSFC comprueba el estado de salud de cada réplica del grupo de disponibilidad. El health check se basa en una serie de criterios que evalúan el rendimiento y la disponibilidad de cada réplica, tales como:

  • El tiempo de respuesta del servidor
  • El tiempo de recuperación de la base de datos
  • El número de errores graves
  • El tamaño del registro de transacciones
  • El tiempo de sincronización entre las réplicas

Cada criterio tiene un umbral asociado que determina si la réplica está en un estado saludable, advertencia o crítico. Si una réplica primaria pasa a un estado crítico, se produce un failover automático a la réplica secundaria con mayor prioridad. Si una réplica secundaria pasa a un estado crítico, se excluye del grupo de disponibilidad hasta que se recupere.

Mecanismo Is-Alive

Por defecto se hará un chequeo de la salud de las réplicas cada 5 segundos. Sin embargo, el health check tiene un timeout de 15 segundos por defecto. Esto es porque durante ese tiempo se realizan 3 comprobaciones y si no se obtiene una respuesta positiva antes de 3 erróneas se considera a esa réplica en estado crítico. Nosotros, podremos modificar el tiempo máximo de timeout mediante la propiedad “HealthCheckTimeout” del grupo de disponibilidad (Availability Group) en PowerShell. El valor mínimo es de 3 segundos, y el máximo es de 9999 segundos. Durante este tiempo se harán varios chequeos de salud de las réplicas y solo se notificará el error si no se recupera antes del tiempo de espera establecido.

Niveles de error admisibles

Como hemos comentado al principio, WSFC contempla hasta 5 niveles de error que podemos configurar siendo uno el más permisivo y 5 el más “paranoico”. En nuestro caso, nuestro AlwaysOn solo considerará una réplica en fallo si cumple con los criterios del nivel establecido o los de los niveles anteriores. 

  1. OnServerDown: El nivel uno de error solo considera una réplica en fallo en caso de caída del sistema operativo. No se comprueba nada más.
  2. OnServerUnresponsive: Este segundo nivel, considera un estado crítico en caso de que no se produzca una respuesta al procedimiento de chequeo de salud sp_server_diagnostics.
  3. OnCriticalServerError: Este tercer nivel es el por defecto cuando creamos un clúster y considera un estado crítico, además de los dos anteriores, si uno de los componentes del servidor está reportando un error. Por ejemplo un error de sector defectuoso en un disco.
  4. OnModerateServerError: Este nivel considera una réplica en estado crítico si uno de los componentes de registro del servidor tiene un error. Por ejemplo varios DUMP de memoria consecutivos.
  5. OnAnyQualifiedFailureConitions: Este es el nivel más paranoico y considera una réplica en estado crítico ante cualquier error de SQL Server como podría ser un deadlock. 

Conclusión

En este artículo hemos visto qué son el session timeout y el health check, y cómo influyen en el comportamiento de un grupo de disponibilidad AlwaysOn en SQL Server. Hemos aprendido cómo modificar estas configuraciones según nuestras necesidades, y cómo afectan al failover automático y a la continuidad del servicio. Esperamos que te haya resultado útil e interesante, y te invitamos a que nos sigas leyendo en nuestro blog www.soydba.es, donde encontrarás más artículos sobre SQL Server y otros temas relacionados con la administración de bases de datos.

Espero que este artículo te haya sido útil. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios

Descubriendo qué llena la TempDB con xEvents

Hace un par de semanas, os preparé un artículo sobre la TempDB en el que pudimos ver, qué es, para qué sirve, por qué se llena y cómo optimizarla. Sin embargo, nos dejamos una cosa en el tintero y es algo que muchos me habéis señalado. Aunque hablamos también de cómo vaciar la TempDB no profundizamos en cómo saber qué consultas son las causantes del llenado de la TempDB. Hoy vamos a ver justo eso, y para ello nos vamos a apoyar en una herramienta de la que también os he hablado, los eventos extendidos de SQL Server.

Un pequeño repaso de la TempDB

No es el objetivo de este artículo profundizar en la teoría de la TempDB, para eso tenemos el artículo del pasado 13/02/2024. Pero, si que tenemos que repasar algunos de esos conceptos para no perdernos ahora. La TempDB es la base de datos de sistema con ID número 2 que se crea cada vez que se inicia el servicio de SQL Server y se elimina al pararlo. 

En esta base de datos se almacenan datos de intercambio de las consultas en curso ya sean datos de paginación de memoria para ordenar u operar con registros como datos almacenados por petición de los usuarios en tablas temporales (de una sesión o globales). Estas funcionalidades son las que hacen esta base de datos susceptible de crecer muy rápido e incluso de terminar llenándose completamente. Como comprenderás, llenar completamente una base de datos que se usa para prácticamente todo puede tener consecuencias fatales, llegando a dejar inoperativo nuestro servidor.

Otro pequeño repaso a xEevents

Como ya vimos hace un par de días, los eventos extendidos son una poderosa herramienta de SQL Server para los DBAs. No solo nos van a ayudar, como hoy, a detectar errores en la TempDB, sino también a monitorizar completamente el estado de nuestro servidor. Sin ir más lejos, ayer pudimos ver como usar xEvents para localizar consultas con mucho consumo de CPU.

Errores de TempDB 

Para nuestro ejercicio de hoy vamos a partir de la base de los errores de falta de espacio en el archivo de datos de SQL Server y vamos a crear una sesión de xEvents que nos almacene la consulta que los ha provocado cuando se den en la base de datos TempDB. Estos errores son el 1101 y el 1105

Como podéis ver, ambos errores son muy parecidos y la solución para ambos es la misma: revisar que el crecimiento sea el correcto, añadir espacio para que pueda crecer el fichero o liberar espacio en el fichero.

Sesión de xEvents

Nosotros nos vamos a centrar hoy en detectar las consultas causantes del problema para poder trabajar sobre ellas y no necesitar tanto espacio en TempDB. Para ello, vamos a hacer uso de una sesión de xEvents.

No me lio más, vamos a ponernos manos a la obra. Para nuestra sesión de XE vamos a capturar los eventos sqlserver.error_reported. Cómo vimos en el artículo de los eventos extendidos, vamos a poder usar las acciones para capturar información extra. En este caso vamos a capturar la base de datos y toda la información relevante sobre la consulta que ha disparado el error. Con esto, estaríamos capturando todas las consultas que generen un error en SQL Server pero como lo que nosotros queremos son solo los errores de espacio en TempDB vamos a hacer uso de los filtros. En concreto vamos a crear 3 filtros, el primero será que la base de datos sea la de id número 2 que ya hemos visto que es la que nos interesa, crearemos también un filtro por los errores 1101 y 1105 que nos interesan y terminaremos con un filtro por id de sesión superior a 50 para quitarnos las consultas del sistema de la captura. El resto de configuraciones son las genéricas que ya vimos.

Este sería el script de nuestra sesión de xEvents:

Revisando los resultados de xEvents:

Una vez creada e inicializada nuestra sesión podremos ver los datos en tiempo real desde la interfaz gráfica de nuestro SSMS:

Otra opción será consultar el fichero de la sesión con una consulta T-SQL.

En cualquiera de los casos podremos ver todas las consultas que han dado error por falta de espacio en TempDB y cómo lo vamos a ver ordenado por fecha solo nos tendremos que ir a la primera para descubrir al causante de la incidencia y poder reeducarle (siempre respetando los derechos humanos, ya sabéis).

Conclusión

Enfrentarse a un problema de consumo de TempDB puede ser un verdadero dolor de cabeza (por no decir otra parte de la anatomía masculina) pero, con las herramientas adecuadas podremos afrontarlo de manera sencilla. Para luego es tarde, no esperes a tener un problema en TempDB y echar de menos esta sesión de xEvents, ponla en tu servidor de pruebas (puedes jugar con el tamaño máximo del fichero de TempDB para reproducir el error) y, si te convence, aplicalo en tus servidores más críticos.

Esperamos que este artículo os haya sido útil y os animamos a seguir aprendiendo sobre SQL Server con nosotros. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario

SQL consume mucha CPU. Solución a problemas de procesador

La semana pasada hablamos sobre el uso excesivo de RAM en SQL Server. Hoy, vamos a abordar otro problema común que puede afectar el rendimiento de nuestros servidores: el consumo elevado de CPU. El consumo excesivo de CPU en SQL Server puede afectar significativamente el rendimiento y la estabilidad del sistema. En este artículo, compartiremos estrategias efectivas para identificar y abordar las causas subyacentes de este problema.

Identificando el problema

Como resumía Don Castelino en uno de los mejores artículos que existen sobre este tipo de incidentes, lo primero que debemos determinar es de donde viene el problema. Si recordáis, en el caso de la RAM, teníamos una cantidad de memoria reservada para SQL y sobre eso, podíamos ver el consumo. En el caso de la CPU la cosa se complica porque la CPU es compartida con el sistema operativo y todos los demás procesos que haya en el servidor. Por este motivo, tendremos muchas más variables que analizar. La siguiente imagen resume la lista de comprobaciones que debemos realizar.

Vamos a ponernos en situación: Estamos ante un problema de rendimiento, nos dirigimos al administrador de tareas de Windows en nuestro servidor y vemos un consumo de CPU del 100% o cercano a esa cifra de manera continuada. Lo primero que debemos hacer será, en el mismo administrador de tareas, determinar si el mayor consumo de CPU viene de SQL Server o de otros procesos. En caso de que el consumo de SQL Server no supere, de manera constante, el 70% del total deberemos ver con los administradores de sistemas que otras cosas están causando el incidente en nuestro servidor. 

Como eso sería muy fácil, y ya habriamos terminado aquí el artículo, vamos a suponer que vemos que el problema de CPU sí que viene de SQL Server. Analicemos los siguientes pasos.

Batch Request por segundo

Una de las medidas que debemos tomar junto con el consumo de CPU es la cantidad de procesos batch por segundo que está ejecutando nuestro servidor SQL Server. Podemos encontrar este dato de forma sencilla en el monitor de rendimiento de nuestro SSMS o en el Performance Monitor de Windows. De esta manera veremos, de forma clara si nuestro SQL está ejecutando muchos procesos de manera simultánea o si, por el contrario, con pocos procesos generamos ese alto consumo de CPU. 

Debemos conocer y familiarizarnos con esta medición pues, no hay un valor estándar para todos los SQL Server. Depende mucho del procesador que tengamos, sus núcleos y su velocidad así como de los procesos que normalmente se ejecutan. Yo he visto, desde servidores donde un valor cercano a 1000 batch por segundo suponían un problema, como servidores con 15 o 20 veces ese valor que funcionaban perfectamente. 

Vista sys.dm_exec_query_stats

Una de las vistas de administración dinámica de SQL Server que nos va a ayudar a solucionar problemas de rendimiento de CPU es sys.dm_exec_query_stats. En ella vamos a poder ver las consultas con mayor consumo de CPU que tenemos en SQL Server. Si además la combinamos con la función sys.dm_exec_sql_text podremos ver el texto de las consultas. Volviendo a la vista, esta nos va a aportar gran cantidad de información entre la que nos vamos a quedar con el conteo de ejecuciones, y los tiempos de ejecución máximo, mínimo y total. Además, os recomiendo ordenar por este último, pues el problema puede ser la ejecución repetida de una consulta ligera y no tanto la ejecución única de una consulta pesada.

Eventos Extendidos

La vista que hemos visto antes, nos puede dar las consultas recientes más pesadas, sin embargo, no nos será de ayuda ante un problema de consumo de CPU que no sea reciente. Para esto podemos usar otra de las formas de monitorización más potentes que incluye SQL Server, los eventos extendidos. Vamos a usar el evento query_post_execution_showplan que aunque ya dijimos que es pesado es lo más potente para este tipo de situaciones. Además vamos a capturar algunas acciones extra como el identificador del proceso, la base de datos, el usuario y el texto de la consulta. Para terminar, yo he añadido un filtro para solo capturar las consultas de más de 20 segundos de duración (recordad que el valor se muestra siempre en microsegundos). Este sería el script de mi sesión de xEvents:

Conclusión

Espero que a partir de ahora estéis más pereparados para afrontar problemas de rendimiento de CPU. Las herramientas que os he facilitado pueden ser de gran utilidad pero no son las únicas. En este sentido, QueryStore también puede ser un gran aliado, aunque aún no lo hayamos visto en este blog (espero solucionar esto pronto) os recomiendo que busquéis información y probéis la herramienta. 

Los más entendidos, habréis notado que no hemos mencionado en ningún momento las configuraciones de paralelismo de la instancia SQL Server. Esto es porque en este artículo hemos partido de la base de solucionar un problema de rendimiento en un servidor correctamente configurado. Le dedicaremos un artículo a estas configuraciones más adelante.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 3 comentarios