SQL Server

Aquí encontraras todos nuestros post relacionados con SQL Server desde cero hasta un nivel avanzado. Desde infraestructura hasta modelado de datos.

Accelerated Database Recovery

En este artículo vamos a hablar de una de las novedades más interesantes que trajo SQL Server 2019: el Accelerated Database Recovery (ADR). Se trata de una característica que mejora el rendimiento y la disponibilidad de las bases de datos al reducir el tiempo de recuperación ante fallos o transacciones largas. ¿Quieres saber cómo funciona y cómo activarlo? ¡Sigue leyendo!

¿Qué es el Accelerated Database Recovery?

El Accelerated Database Recovery (ADR) es una funcionalidad que cambia la forma en que SQL Server gestiona el registro de transacciones y el proceso de recuperación. Con ADR, SQL Server utiliza una estructura de datos llamada Persistent Version Store (PVS) que almacena las versiones de las filas modificadas por las transacciones en curso. De esta forma, cuando se produce un rollback o un fallo del sistema, SQL Server no tiene que deshacer las modificaciones una por una, sino que simplemente recupera las versiones anteriores de las filas desde el PVS. Esto hace que el tiempo de recuperación sea mucho más rápido y predecible, independientemente del tamaño o la duración de las transacciones.

Además, el ADR también elimina el problema de los bloqueos por transacciones activas que consumen todo el espacio del log. Con ADR, SQL Server puede truncar el log sin esperar a que se completen las transacciones activas, ya que las versiones de las filas están en el PVS y no en el log. Esto evita que el log se llene y cause problemas de rendimiento o disponibilidad.

¿Qué ventajas tiene el Accelerated Database Recovery?

El Accelerated Database Recovery tiene varias ventajas para los administradores y desarrolladores de bases de datos:

  • Reduce el tiempo de recuperación ante fallos o cancelaciones de transacciones. Con ADR, el tiempo de recuperación es constante y no depende del número o tamaño de las transacciones. Esto mejora la disponibilidad y la continuidad del negocio.
  • Reduce el consumo de espacio del log. Con ADR, SQL Server puede truncar el log más frecuentemente y liberar espacio para nuevas transacciones. Esto reduce la necesidad de ampliar el log o hacer backups frecuentes.
  • Reduce los bloqueos por transacciones activas. Con ADR, SQL Server no tiene que esperar a que se terminen las transacciones activas para truncar el log. Esto evita los bloqueos por falta de espacio en el log y mejora el rendimiento y la concurrencia.
  • Facilita la gestión de transacciones largas o complejas. Con ADR, los desarrolladores pueden usar transacciones largas o complejas sin temor a que afecten al rendimiento o la disponibilidad de la base de datos. Esto permite implementar procesos de negocio más sofisticados y flexibles.

Una cosa más que debes saber sobre el ADR es que también afecta al funcionamiento de los checkpoints. Los checkpoints son procesos que escriben las páginas modificadas en memoria al disco para facilitar la recuperación. Con ADR, los checkpoints son más rápidos y eficientes, ya que solo escriben las páginas que han sido modificadas desde el último checkpoint y no dependen del estado de las transacciones. Esto también reduce la carga de E/S y mejora el rendimiento de la base de datos.

¿Cómo activar el Accelerated Database Recovery?

El Accelerated Database Recovery se activa a nivel de base de datos con el siguiente comando:

Es importante tener en cuenta que para activar el ADR, la base de datos debe estar en modo de compatibilidad 150 o superior (SQL Server 2019 o Azure SQL Database). Además, se recomienda tener suficiente espacio libre en el disco donde se almacena el PVS, ya que este puede crecer según la actividad de las transacciones. PVS se almacena en TempDB

Práctica

En la teoría todo es muy bonito, ahora vamos a verlo en la práctica a ver si es cierto. Para ello crearemos dos bases de datos, una con ADR activado y otra sin ello. Vamos a ejecutar sobre ellas unas consultas pesadas que se inicien justo a la vez y antes de que terminen vamos a forzar un apagado del servicio de SQL Server. Para terminar levantaremos de nuevo el servicio y veremos en el Log de SQL Server cuánto han tardado en estar disponibles:

Para crear las bases de datos he usado este script:

Lugo he ejecutado estos scripts en dos ventanas separadas (fijaos que se inician exactamente a la misma hora):

WAITFOR TIME '19:30:30';
USE NOADR;
GO
DROP TABLE IF EXISTS dbo.t1, dbo.t2, dbo.t3;
SELECT o1.* INTO dbo.t1 FROM sys.all_columns c1 CROSS JOIN sys.all_objects o1
SELECT o2.* INTO dbo.t2 FROM sys.all_columns c2 CROSS JOIN sys.all_objects o2
SELECT o3.* INTO dbo.t3 FROM sys.all_columns c3 CROSS JOIN sys.all_objects o3

En una tercera ventana he ejecutado este script para detener el servicio justo 5 minutos después de iniciar los anteriores:

Este que podéis ver ha sido el resultado, el rollback y por tanto la recuperación de la base de datos baja de 70 segundos sin ADR a 8 segundos con ADR activado: 

Esto creo que sobra decirlo pero, POR LO QUE MÁS QUERÁIS, NO HAGÁIS ESTA PRUEBA EN PRODUCCIÓN. Estamos probando a detener el servicio de SQL Server de manera forzada.

Conclusión

El Accelerated Database Recovery es una característica muy útil que mejora el rendimiento y la disponibilidad de las bases de datos en SQL Server 2019. Con ADR, se reduce el tiempo de recuperación ante fallos o cancelaciones de transacciones, se reduce el consumo de espacio del log, se reducen los bloqueos por transacciones activas y se facilita la gestión de transacciones largas o complejas. Si quieres aprovechar estas ventajas, te animamos a probar el ADR en tus bases de datos y a compartir tus experiencias con nosotros.

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, 4 comentarios

Bloqueos y Deadlocks en SQL Server

Entender la concurrencia de nuestros procesos es muy importante para los DBAs que queremos optimizar el rendimiento de nuestras bases de datos. En este sentido, muchas veces hemos nombrado en el blog los bloqueos. Sin embargo, en este artículo vamos a profundizar en el tema y vamos a tratar de llevar nuestros conocimientos sobre el tema al siguiente nivel.

 ¿Qué es un bloqueo y por qué se produce?

Un bloqueo es un mecanismo que SQL Server utiliza para garantizar la integridad de los datos cuando hay transacciones concurrentes que acceden a los mismos recursos. Un recurso puede ser una fila, una página, una tabla, una base de datos o cualquier otro objeto de SQL Server. Una transacción es una secuencia de operaciones que se ejecutan como una unidad lógica y que deben cumplir las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad). Cuando una transacción accede a un recurso, solicita un bloqueo sobre él, que puede ser de varios tipos y modos, dependiendo de la operación que realiza y del nivel de aislamiento que tiene.

Por ejemplo, una transacción que lee un recurso solicita un bloqueo compartido (S), que permite que otras transacciones también puedan leer el mismo recurso, pero no modificarlo. Una transacción que modifica un recurso solicita un bloqueo exclusivo (X), que impide que otras transacciones puedan acceder al mismo recurso, ya sea para leerlo o modificarlo.

Tipos de bloqueos

Acabamos de nombrar los bloqueos compartidos (S) y los exclusivos (X) pero, estos no son los únicos tipos de bloqueos en SQL Server. Además de los bloqueos compartidos (S) y los exclusivos (X) nos podemos encontrar con bloqueos de actualización (U) que, son parecidos a los exclusivos pero más flexibles. En estos casos si un recurso tiene un bloqueo compartido el bloqueo de actualización generará otro bloqueo compartido hasta que pueda generar el bloqueo exclusivo. 

Para terminar tenemos los llamados bloqueos de intención o propósito (I), estos se dan cuando SQL Server sabe que va a necesitar uno de los bloqueos anteriores. De esta manera, SQL se garantiza poder obtenerlo cuando lo necesite. Nos podemos encontrar con 3 tipos de bloqueos de intenciones generales: IS, IX o IU en función de si el bloqueo que va a necesitar es compartido, exclusivo o de actualización.
Para terminar con los bloqueos de intención tenemos los bloqueos de intención de conversión y también tenemos 3 tipos. El primero de ellos es el bloqueo SIX que se da cuando SQL va a necesitar un bloqueo compartido (S) sobre una serie de recursos que va a leer y posteriormente tiene intención (I) de generar un bloqueo exclusivo (X) sobre unos pocos de esos recursos que va a actualizar. Del mismo modo tenemos los bloqueos SIU si un bloqueo compartido (S) se va a convertir en uno de actualización (U) y los UIX cuando un bloqueo de actualización (U) se va a convertir en un bloqueo exclusivo (X).

Otros tipos de bloqueos

Por otro lado, SQL Server implementa también bloqueos a nivel de esquema Sch-M y Sch-S. El primero se da cuando ejecutamos una operación DDL que modifica el esquema y es exclusivo mientras que el segundo es compartido y lo veremos cuando una consulta dependa de un esquema. 

Para terminar tenemos los bloqueos BU de carga masiva que se producen al cargar una tabla con Bulk Insert y la opción TABLOCK. Estas cargas no permitirán el acceso a la tabla mientras estén en curso.

Jerarquía de los bloqueos.

Otro aspecto que debemos tener en cuenta es el nivel de granularidad de los bloqueos, es decir, el tamaño de las unidades de datos que se bloquean. SQL Server puede utilizar cuatro niveles de granularidad: base de datos, tabla, página o fila. El primero de ellos nos garantiza por ejemplo que una base de datos no se puede eliminar o restaurar mientras está en uso por alguna consulta. Cualquier operación sobre un objeto de base de datos genera un bloqueo compartido en la propia base de datos.

Los otros tres nos los podremos encontrar en nuestras consultas. El nivel de granularidad afecta al rendimiento y a la contención. Por un lado, un nivel más fino (fila) reduce la probabilidad de que dos transacciones accedan al mismo recurso, pero aumenta el número de bloqueos y el consumo de memoria. Por otro lado, un nivel más grueso (tabla) reduce el número de bloqueos y el consumo de memoria, pero aumenta la probabilidad de contención y tiempo de espera. SQL Server utiliza un algoritmo dinámico para elegir el nivel de granularidad más adecuado para cada caso, pero también podemos influir en esta decisión mediante las opciones de índice o las sugerencias de tabla.

Cómo funcionan los bloqueos

Si habéis llegado hasta este punto con el cerebro como un yogurt es normal. Esto no es fácil de entender, vamos a verlo con un ejemplo simple para entenderlo. Supongamos que en nuestra base de datos Animalitos tenemos un esquema MascotasAdorables y en ella una tabla Gatetes. Cuando nosotros queramos leer una fila de nuestra tabla, SQL Server generará un bloqueo compartido (S) sobre la fila de la tabla que vamos a leer, pero a la vez generará un intento de bloqueo compartido (IS) sobre la página que contiene esa fila y sobre la tabla MascotasAdorables y otro bloqueo (S) sobre la base de datos Animalitos.

Los dos bloqueos compartidos (S) están claros, como hemos dicho SQL siempre genera un bloqueo sobre la base de datos y al ser un select genera otro sobre la fila que estamos leyendo. Los bloqueos de intención compartidos (IS) nos garantizan que se podrán escalar a un bloqueo compartido (S) si alguien intenta borrar o modificar nuestra tabla o la página mientras estamos leyendo. 

Compatibilidad de los bloqueos

Como hemos visto, un recurso puede tener varios bloqueos compartidos simultáneos y sin embargo solo uno exclusivo (por eso sus nombres, tampoco se mataron pensando aquí). Ahora vamos a ver como de compatibles son los bloqueos entre ellos.

Deadlocks

Los deadlocks, en español interbloqueos o bloqueos permanentes, se producen cuando dos o más transacciones se bloquean mutuamente, impidiendo que ninguna de ellas pueda avanzar. 

Imagina que tenemos dos transacciones la A y la B. Nuestro proceso A ha leído una fila de la tabla gatetes y quiere escribirla en la tabla felinos. Es decir ha generado un bloqueo compartido (S) en la tabla gatetes y tiene que generar un bloqueo exclusivo (X) en la tabla felinos. Cuando va a generar este bloqueo se encuentra con que el proceso B ya ha leído de la tabla felinos y tiene sobre ella un bloqueo compartido (S) por lo que se tiene que esperar a que termine (según la tabla anterior S y X no son compatibles). Sin embargo el proceso B no va a terminar nunca porque está esperando a escribir en la tabla gatetes lo que ha leído. Esa escritura es un bloqueo compartido (X) que no puede hacerse porque ya hay un bloqueo compartido sobre esa tabla. 

SQL Server detecta estos escenarios y elige una de las transacciones como víctima, matándola y liberando los recursos que tenía bloqueados. Esto puede causar errores y pérdidas de datos en las aplicaciones que no están preparadas para manejar estos casos. 

¿Cómo podemos evitar o reducir los bloqueos e interbloqueos en SQL Server? 

Hay varias estrategias que podemos aplicar, dependiendo del contexto y el tipo de operaciones que realizamos. Algunas de estas estrategias son:

  • Diseñar índices adecuados que permitan acceder a los datos con el menor número de lecturas y escrituras posibles.
  • Utilizar transacciones cortas y simples que minimicen el tiempo que mantienen los bloqueos sobre los recursos.
  • Elegir el nivel de aislamiento apropiado para cada transacción, teniendo en cuenta el equilibrio entre la consistencia de los datos y el rendimiento. En anteriores artículos hemos hablado de los diferentes niveles de aislamiento que ofrece SQL Server y cómo afectan a los bloqueos y a la visibilidad de los datos.
  • Evitar el uso indiscriminado de la opción NOLOCK, que puede provocar lecturas sucias, perdidas o duplicadas. En este artículo explicamos los problemas del uso de NOLOCK.
  • Monitorizar los bloqueos e interbloqueos que se producen en nuestras bases de datos, utilizando las herramientas y vistas que SQL Server nos proporciona. De esta forma podremos identificar las causas y las soluciones más adecuadas para cada caso.

¿Cómo podemos identificar los bloqueos e interbloqueos que se producen en nuestras bases de datos?

SQL Server nos ofrece varias herramientas y vistas para monitorizar y analizar estos fenómenos. Algunas de estas herramientas y vistas son:

  • El Monitor de actividad, que nos permite ver en tiempo real las sesiones, procesos, bloqueos e interbloqueos que se están produciendo en nuestra instancia.
  • La vista sys.dm_tran_locks, que nos muestra información detallada sobre los bloqueos actuales, como el tipo, el modo, el recurso, la sesión y la transacción asociados.
  • La vista sys.dm_exec_requests, que nos muestra información sobre las solicitudes en ejecución, como el estado, el tiempo transcurrido, el tiempo esperado y la causa del tiempo de espera.
  • La vista sys.dm_os_waiting_tasks, que nos muestra información sobre las tareas en espera, como la sesión, la solicitud, la duración y el tipo del tiempo de espera.
  • El evento extendido deadlock graph, que nos muestra información sobre los interbloqueos ocurridos, como las transacciones involucradas, los recursos implicados y la víctima elegida.

Conclusión

Los bloqueos e interbloqueos son aspectos inevitables en cualquier sistema de gestión de bases de datos relacionales, pero no por ello debemos resignarnos a sufrir sus consecuencias negativas. Con un buen diseño, una correcta elección del nivel de aislamiento y una constante monitorización podremos mejorar el rendimiento y la fiabilidad de nuestras bases de datos. Esperamos que este artículo os haya sido útil y os animamos a compartir vuestras experiencias y dudas con nosotros en los comentarios.

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

Optimizando el rendimiento de nuestras consultas SQL Server

En este artículo vamos a hablar de las causas más comunes de mal rendimiento en consultas de SQL Server y cómo optimizarlas. Sabemos que el rendimiento es un aspecto crítico para cualquier aplicación que utilice una base de datos, y que SQL Server es uno de los sistemas de gestión de bases de datos relacionales más populares y potentes del mercado. Sin embargo, también sabemos que no basta con instalar SQL Server y esperar que todo funcione a la perfección. Hay que tener en cuenta una serie de factores que pueden afectar al rendimiento de las consultas, tanto a nivel de diseño como de implementación y mantenimiento.

Problemas de rendimiento por malas consultas

La forma en la que obtenemos los datos marca directamente el rendimiento de nuestros procesos, dos consultas pueden devolver exactamente el mismo resultado pero una con menos consumo de recursos que la otra. A esto es a lo que vamos a llamar optimizar una consulta. Reescribiremos la consulta evitando las siguientes prácticas en la medida de lo posible: 

Funciones 

Las funciones son un objeto de base de datos que nos permite encapsular código en un objeto para utilizarlo después simplemente llamando a ese objeto. Sin embargo, de cara al rendimiento pueden generarnos problemas. 

Por un lado tenemos las funciones escalares, estas son las más inofensivas en cuanto a rendimiento pero cuidado con usarlas dentro de un filtro del WHERE. Estas funciones impiden que el optimizador de consultas utilice índices y obligan a realizar escaneos completos de las tablas, lo que consume más recursos y tiempo.

El otro tipo de funciones que tenemos en SQL son las funciones de tabla. Las funciones de tabla son objetos que devuelven un conjunto de filas como resultado de una consulta o una expresión. Aunque pueden ser útiles para resolver ciertos problemas complejos o integrar datos heterogéneos, también pueden afectar al rendimiento si no se usan correctamente. Por ejemplo, una función de tabla puede generar una estimación errónea del número de filas devueltas. Además, necesitan ser cargadas completamente en memoria antes de poderse ejecutar. Esto nos puede provocar un plan subóptimo o un desbordamiento de memoria. Y, aun en el caso de que la función se pueda cargar en memoria, la consulta deberá esperar a que se resuelva completamente la consulta antes de seguir con otros componentes.

Cursores o bucles para procesar datos. 

Estas técnicas son propias de la programación estructurada y no aprovechan la naturaleza en bloques de SQL Server. Además, generan un mayor número de accesos a disco y bloqueos, lo que reduce el rendimiento y la concurrencia. Para evitarlo, se recomienda utilizar consultas que operen sobre conjuntos de datos en lugar de sobre filas individuales.

Subconsultas

El uso de subconsultas en ocasiones es imprescindible, sin embargo, usarlas en el SELECT o en el WHERE tienen un impacto negativo en el rendimiento. Las subconsultas son consultas anidadas dentro de otras consultas, que pueden devolver uno o varios valores. Aunque pueden ser útiles para resolver ciertos problemas complejos, también pueden afectar al rendimiento si no se usan correctamente. Por ejemplo, una subconsulta correlacionada es aquella que depende del valor devuelto por la consulta principal, lo que implica que se tenga que ejecutar tantas veces como filas devuelva la consulta principal. Esto puede generar un gran consumo de recursos y tiempo. Para evitarlo, se recomienda reescribir la consulta para utilizar JOINs.

Servidores vinculados 

Los servidores vinculados son objetos que permiten acceder a datos almacenados en otros servidores mediante consultas distribuidas. Un servidor vinculado puede generar una latencia adicional al tener que comunicarse con otro servidor, lo que puede ralentizar la ejecución de la consulta. Además, nuestro SQL Server desconocerá la estimación de resultados que van a llegarnos del servidor remoto por lo que podemos tener los mismos problemas de memoria que hemos visto con las funciones de tabla. Se recomienda utilizar servidores vinculados únicamente cuando sea necesario y con criterios restrictivos para minimizar el volumen de datos transferidos.

Problemas de rendimiento por diseño y arquitectura

En ocasiones aunque nuestra consulta esté optimizada sigue rindiendo mal, y esto puede ser debido, entre otras cosas, a un mal diseño de las soluciones de bases de datos. Veamos ahora los principales problemas de diseño:

Consultas dinámicas o ad hoc

Estas consultas se construyen en tiempo de ejecución y no se almacenan en el caché del plan de ejecución, lo que implica que el optimizador tenga que generar un nuevo plan cada vez que se ejecutan. Esto consume más recursos y tiempo, y puede provocar planes subóptimos. Para evitarlo, se recomienda utilizar procedimientos almacenados o consultas parametrizadas, que se almacenan en el caché y se reutilizan cuando se ejecutan con los mismos parámetros. A este tema le dedicamos ya un artículo hace unos días. 

Problemas de rendimiento de índices

Los índices son estructuras que facilitan la localización y el acceso a los datos, y son esenciales para mejorar el rendimiento de las consultas. Sin embargo, hay que tener cuidado con el tipo, el número y la definición de los índices, ya que pueden tener efectos negativos si no se usan correctamente. Por ejemplo, un índice demasiado grande o con muchas columnas puede ralentizar las operaciones de inserción, actualización o borrado, o consumir demasiado espacio en disco. Un índice mal diseñado o no utilizado puede generar escaneos innecesarios o planes ineficientes. Un índice faltante puede obligar a realizar escaneos completos o búsquedas secuenciales.
Para evitarlo, se recomienda analizar las consultas más frecuentes o críticas y crear índices adecuados para ellas, teniendo en cuenta las columnas usadas en los predicados WHERE, JOIN, ORDER BY y GROUP BY, así como la cardinalidad y la selectividad de los datos. En este blog le hemos dedicado a los índices más de media docena de artículos que os recomiendo leer.

Estadísticas desactualizadas

Las estadísticas son objetos que almacenan información sobre la distribución y la frecuencia de los valores en las columnas de las tablas e índices. El optimizador de consultas utiliza esta información para estimar el coste y elegir el mejor plan de ejecución posible. Sin embargo, si las estadísticas no reflejan la realidad de los datos, el optimizador puede generar planes subóptimos o erróneos, lo que afecta al rendimiento. Para evitarlo, se recomienda mantener las estadísticas actualizadas mediante trabajos programados como los que vimos aquí

Problemas de rendimiento por tipos de datos inadecuados

Los tipos de datos son los que definen el formato, el tamaño y el rango de los valores que se almacenan en las columnas de las tablas e índices. Elegir el tipo de dato adecuado para cada columna es fundamental para optimizar el rendimiento de las consultas, ya que influye en el espacio ocupado, la velocidad de acceso, la precisión y la compatibilidad. Por ejemplo, un tipo de dato demasiado grande o con una precisión innecesaria puede consumir más espacio en disco y memoria, lo que ralentiza las operaciones y aumenta el riesgo de desbordamiento. Un tipo de dato incompatible con el valor esperado puede generar errores o conversiones implícitas, lo que afecta a la calidad y la eficiencia de los datos.
Para evitarlo, se recomienda elegir el tipo de dato más apropiado para cada columna, teniendo en cuenta el valor máximo, mínimo y medio que se espera almacenar, así como el uso que se le va a dar. 

Es importante usar el mismo tipo de datos a la hora de escribir la consulta que el que hay en las tablas ya que una conversión obligará a SQL Server escanear completamente las tablas e índices y no poder beneficiarse de las características de árbol B.

Problemas de rendimiento por el servidor

Para terminar, vamos a ver el último factor posible en la degradación del rendimiento, el servidor. En ocasiones nos vamos a encontrar con diseños de bases de datos y consultas optimizadas y sin embargo un mal rendimiento. La principal causa de problemas con el rendimiento del servidor está relacionada con el consumo de recursos. Y es que cuando esto pasa, normalmente tendremos otro proceso ajeno al nuestro consumiendo todos los recursos del servidor. Aunque es cierto que optimizando nuestras consultas y modelos de datos necesitaremos nosotros menos recursos y seremos más resilientes ante este tipo de escenarios, en ocasiones no será suficiente y veremos como la ruedecita de abajo a la izquierda de nuestra pantalla no deja de dar vueltas y nuestra consulta no termina.

En estas ocasiones yo tiro de recursos como los procedimientos sp_who3 y sp_whoisactive para ver qué más hay en ejecución en SQL Server y ver si lo puedo detener o tengo que ir a dar una colleja a alguien. 

Bloqueos

Otro posible problema que detecto con esos procedimientos son los bloqueos. Los bloqueos son mecanismos que garantizan la integridad y la consistencia de los datos cuando se realizan operaciones concurrentes sobre la base de datos. Sin embargo, también pueden afectar al rendimiento si no se gestionan correctamente. Por ejemplo, un bloqueo excesivo o innecesario puede impedir o retrasar el acceso a los datos por parte de otras transacciones, lo que reduce la concurrencia y genera esperas. Un bloqueo insuficiente o incorrecto puede provocar problemas de integridad o consistencia, como lecturas sucias o pérdidas. Para evitarlo, se recomienda utilizar el nivel de aislamiento adecuado para cada transacción, teniendo en cuenta el grado de consistencia y concurrencia que se requiere. Hablamos de niveles de aislamiento aquí.

Problemas ajenos a SQL

Si esto no devuelve nada esclarecedor es posible que el proceso que esté consumiendo los recursos sea ajeno a SQL Server y tendremos que mirar los procesos en ejecución del sistema operativo. En una ocasión me he encontrado con un caso peor, la cabina de discos estaba saturada y aunque mi servidor estaba rascándose el ombligo no había manera de que terminaran las consultas. Esto si que es un verdadero expediente X difícil de encontrar y ojalá no tengáis que lidiar nunca con una situación tan compleja. 

Conclusión

Estas son solo algunas de las causas más comunes de mal rendimiento en consultas de SQL Server, pero hay muchas más que pueden influir en el comportamiento del sistema. Te invitamos a revisar los artículos que he enlazado a este si quieres profundizar más en estos temas.

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, 0 comentarios

Administración de Instancias SQL en Azure

Ayer hablamos en profundidad sobre las instancias administradas de SQL Server en Azure y os prometí dedicar el post de hoy a temas de administración. Vamos a empezar hablando de los modos de licenciamiento y lo que nos ofrece cada uno de ellos y, a continuación, ya entraremos en materia con la administración.

Licenciamiento de instancias administradas en Azure

Como DBAs es probable que recaiga sobre nosotros la elección de la arquitectura SQL y por tanto su licenciamiento. En el caso de las instancias administradas de SQL Server en Azure el modelo de compra se basa en núcleos virtuales. Esto quiere decir que recursos como la RAM dependerán de la cantidad de núcleos de CPU que seleccionemos y no podremos ampliar un recurso sin el resto. Además de los núcleos tenemos otras opciones, por un lado podremos elegir el tipo de hardware y el nivel de servicio. Sé que es un poco lioso así, no os preocupéis que vamos a verlo con detalle.

En base al hardware, tenemos tres planes disponibles: el Gen5, el Premium y el Premium optimizados para memoria. La diferencia entre el Gen5 y el Premium es el tipo de procesador y, por tanto, su velocidad. Además el plan Premium nos da algo más de RAM por cada núcleo que contratemos. El Premium y Premium optimizado para memoria solo se diferencian en que este segundo da aún más RAM por cada núcleo. 

Además, como hemos comentado, cualquiera de estos tres planes se puede contratar en dos niveles de servicio: estándar o crítico para la empresa. El nivel estándar nos proporcionará 16Tb de Azure Blob Storage de alto rendimiento y alta disponibilidad basada en Azure Blob Storage y Azure Service Factory. El nivel crítico para la empresa cambia la opción de almacenamiento por un SSD local extremadamente rápido que reduce la latencia de E/S. El tamaño del SSD variará en función del plan de hardware. Otras ventajas del nivel de servicio crítico es la alta disponibilidad Always On y una réplica de solo lectura adicional. Por último, este nivel, añade OLTP en memoria para usarse en cargas con necesidades de rendimiento muy altas.

La siguiente tabla resume todo lo que hemos comentado, para precios Microsoft ha puesto a nuestra disposición esta calculadora.

Operaciones de administración

Ahora que ya sabemos que opción contratar es momento de crear nuestra primera instancia. Para crear instancias, igual que para cambiar su configuración o eliminarlas, podremos hacerlo desde Azure Portal, usando PowerShell o la CLI (Command Line Interface) de Azure. Al crear una instancia tenemos que elegir el nombre, la ubicación, la versión y la edición de SQL Server, el tamaño del almacenamiento y la configuración del firewall. En cuanto a la configuración, podremos cambiar algunos parámetros como el número de núcleos virtuales (vCores), la cantidad de memoria RAM o el tamaño del almacenamiento. También podemos habilitar o deshabilitar algunas características como el Always On Availability Groups o el Transparent Data Encryption.

Copias de seguridad y restauraciones en instancias en Azure

Antes de empezar con este tema, vamos a hablar de una cosa que todos estáis pensando y que no es para menos. Con la presentación de SQL Server 2022 se nos mostró una funcionalidad llamada “Vínculo para Azure Managed Instance” que, haciendo uso de grupos de disponibilidad distribuidos, nos permitiría mantener sincronizados nuestro entorno On Premise con Azure. Sin embargo, aunque SQL Server 2022 salió al mercado en diciembre de 2022, a día de hoy (Enero de 2024) sigue siendo una versión preliminar que no está disponible para todo el mundo. Sé lo que estáis pensando, es una CHAPUZA que, habiendo pasado más de un año siga sin estar disponible esta característica. No olvidemos que es una de las principales novedades que justificaría la migración a esta versión de SQL Server. Yo tampoco lo entiendo.

Vale, pasemos página y dejemos atrás lo malo (aunque no lo olvidemos) y hablemos de las copias de seguridad en las instancias de Azure. Las copias de seguridad principales, son automáticas y no vamos a poder configurar nada. Las instancias administradas realizan copias de seguridad automáticas cada 5-10 minutos (dependiendo del tamaño de las bases de datos) y las almacenan en un almacenamiento redundante. Podemos restaurar nuestras bases de datos desde estas copias usando Azure Portal o PowerShell. 

Sin embargo, nosotros también podemos realizar copias de seguridad manuales por nuestra cuenta usando T-SQL o PowerShell y almacenarlas en un almacenamiento externo como Azure Blob Storage o un recurso compartido SMB. Estas copias siempre serán Copy-Only para no interferir en la cadena principal de copias automáticas. 

En cuanto a restauración de copias manuales, podremos usar T-SQL o PowerShell para restaurar nuestras copias en la instancia de Azure. Nuestra instancia administrada admitirá copias de otras bases de datos de Azure y de cualquier SQL Server superior a 2008. En el otro sentido, solo podremos restaurar copias de seguridad de Azure en SQL Server 2022.

Actualizaciones de instancias administradas en Azure

Las instancias administradas se actualizan solas con los últimos parches y mejoras de SQL Server sin necesidad de intervención manual. Sin embargo, sí tendremos que elegir entre dos modos de actualización: automático o manual. En el modo automático, las actualizaciones se aplican tan pronto como están disponibles mientras que en modo manual, podemos elegir cuándo aplicarlas. Os recomiendo este último modo para actualizar siempre dentro de una ventana de mantenimiento.

Monitorización de instancias administradas en Azure

Podemos monitorizar y diagnosticar nuestras instancias administradas usando las herramientas habituales que ya conocemos como SQL Server Management Studio o Extended Events. También podemos usar los servicios integrados de Azure como Azure Monitor o Azure SQL Analytics para obtener métricas e insights sobre el rendimiento, la disponibilidad y la salud de nuestras instancias.

Conclusión

Como hemos visto en este artículo y en el anterior, las instancias SQL Server administradas de Azure son una gran solución PAAS en el cloud de Microsoft. Nos ofrecen prácticamente todas las características de un SQL Server local sin necesidad de tenerlo en nuestra infraestructura. Además, Azure se encarga de las copias de seguridad por nosotros y nos garantiza una disponibilidad con un SLA cercano al 100%. Por contra, perdemos flexibilidad a la hora de gestionar ciertos temas de configuración de recursos y nos limita a 16 Tb de espacio en disco. ¿Qué opináis? ¿Trabajáis con esta solución?¿Os planteáis migrar a este servicio? Os leo en comentarios. También podéis dejar vuestro feedback en nuestro Twitter o en nuestro nuevo grupo de LinkedIn.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios

Instancias Administradas en Azure (Introducción)

En este artículo vamos a hablar de las instancias administradas de SQL Server en Azure, un servicio que nos permite tener una experiencia casi idéntica a la de un servidor SQL Server tradicional, pero con las ventajas de la nube. Las instancias administradas de SQL Server en Azure son una opción ideal para migrar nuestras bases de datos SQL Server existentes a Azure sin tener que modificar mucho el código ni la configuración. Además, nos ofrecen todas las ventajas de la nube como un alto nivel de rendimiento, seguridad, escalabilidad y disponibilidad.

¿Qué son las instancias administradas de SQL Server en Azure?

Las instancias administradas de SQL Server en Azure son un tipo de servicio PaaS (Platform as a Service) que nos permite crear y administrar instancias de SQL Server en la nube. Estas instancias tienen casi las mismas características y funcionalidades que un servidor SQL Server tradicional. También soportan las mismas versiones y ediciones de SQL Server, desde la 2008 hasta la 2022, y se actualizan automáticamente con los últimos parches y mejoras.

Las instancias administradas de SQL Server en Azure se diferencian de otros servicios de bases de datos SQL en Azure en que nos permiten tener un mayor control sobre la instancia, como el acceso al sistema operativo, la configuración del firewall, la administración de usuarios y roles, la auditoría y el seguimiento, etc. Además, nos permiten usar características avanzadas de SQL Server que no están disponibles en otros servicios, como el Always On Availability Groups, el Transparent Data Encryption, el Change Data Capture, el Service Broker, etc.

¿Cómo se administran?

La administración de las instancias administradas de SQL Server en Azure es muy similar a la de un servidor SQL Server tradicional. Podemos usar las mismas herramientas y métodos que estamos acostumbrados a usar, como el SQL Server Management Studio, PowerShell o T-SQL. También podemos usar los servicios integrados de Azure para facilitar algunas tareas, como el Azure Portal, el Azure Monitor o el Azure Automation. Veremos más sobre este tema en otro post.

Instancias administradas en Azure VS instancias On Premise

Las instancias On Premise son aquellas que se ejecutan en nuestros propios servidores físicos o virtuales, dentro de nuestra infraestructura local. Estas instancias tienen algunas ventajas sobre las instancias administradas en Azure, como un mayor control sobre el hardware, una menor latencia y una mayor personalización. Sin embargo, también tienen algunos inconvenientes, como un mayor coste, una mayor complejidad y una menor flexibilidad.

Las instancias administradas en Azure nos ahorran los costes y las molestias de tener que comprar, instalar y mantener nuestros propios servidores. Además, nos ofrecen una mayor escalabilidad y disponibilidad, ya que podemos aumentar o reducir los recursos según la demanda y contar con la garantía de un SLA (Service Level Agreement) del 99.99%. También nos facilitan la migración y la recuperación de nuestras bases de datos, ya que podemos usar herramientas como el Data Migration Service o el Backup and Restore.

La elección entre las instancias administradas o las instancias on premise dependerá de nuestras necesidades y preferencias. Si queremos tener una solución más económica y flexible, con todas las ventajas de la nube, las instancias administradas son la mejor opción. Si queremos tener una solución más personalizada y con menos dependencia de internet, las instancias on premise pueden ser suficientes.

Instancias administradas en Azure VS Bases de datos de Azure

El servicio de bases de datos SQL en Azure es otro tipo de servicio PaaS que nos permite crear y administrar bases de datos SQL en la nube como ya vimos en el post anterior. Sin embargo, a diferencia de las bases de datos de Azure, las instancias administradas nos ofrecen una instancia completa de SQL Server y no solo una base de datos aislada que se ejecuta en un servidor compartido con otros clientes. Esto implica que tenemos mayor control sobre la base de datos y que podemos usar algunas características de SQL Server propias de la instancia.

El servicio de bases de datos SQL en Azure tiene algunas ventajas sobre las instancias administradas, como un menor coste, una mayor elasticidad y una menor complejidad. Sin embargo, también tiene algunas limitaciones, como una menor compatibilidad con las versiones y ediciones de SQL Server, una menor capacidad para escalar verticalmente y una menor flexibilidad para migrar o restaurar bases de datos.

La elección entre las instancias administradas o el servicio de bases de datos SQL en Azure dependerá de nuestras necesidades y preferencias. Si queremos tener una experiencia similar a la de un servidor SQL Server tradicional, con todas sus características y funcionalidades, las instancias administradas son la mejor opción. Si queremos tener una solución más simple y económica, con solo lo necesario para alojar nuestras bases de datos SQL, el servicio de bases de datos SQL en Azure puede ser suficiente.

Conclusión

Las instancias administradas de SQL Server en Azure son un servicio que nos ofrece una forma fácil y rápida de migrar nuestras bases de datos SQL Server existentes a la nube, sin perder ninguna característica ni funcionalidad. Se trata de un servicio PaaS que nos brinda un alto nivel de rendimiento, seguridad, escalabilidad y disponibilidad, así como un gran control sobre la instancia. Como esto se alargaba ya demasiado, mañana hablamos de temas más técnicos de la administración de este servicio (que seguro que os interesa más), mientras tanto, podéis dejarme vuestros comentarios aquí abajo, en Twitter o por mail.

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

Azure Database: SQL sin servidor

Seguimos con los artículos sobre SQL en la nube, ya hemos visto por encima todas las posibles soluciones de SQL en Cloud. Hoy quiero compartir con vosotros mi experiencia con Azure Databases, el servicio de bases de datos en la nube de Microsoft. ¿Qué ventajas tiene frente a otras opciones? ¿Cómo podemos migrar nuestras bases de datos SQL Server a Azure? ¿Qué retos y oportunidades nos ofrece este servicio? Estas son algunas de las preguntas que intentaremos responder en este artículo.

¿Qué es Azure Database?

Azure Databases es una plataforma que nos permite crear, administrar y escalar bases de datos en la nube, sin tener que preocuparnos por el hardware, el software o la infraestructura. Podemos elegir entre diferentes tipos de bases de datos, según nuestras necesidades y preferencias: SQL Database, MySQL, PostgreSQL, MariaDB, Cosmos DB, etc. Cada una de estas opciones tiene sus propias características, ventajas y desventajas, que podéis consultar en la documentación oficial de Azure.

Nosotros nos vamos a centrar en SQL Database, que es el servicio que nos permite usar SQL Server en la nube. SQL Server es uno de los sistemas de gestión de bases de datos relacionales más populares y potentes del mercado, y con Azure Databases podemos aprovechar todas sus funcionalidades y beneficios, pero con una mayor flexibilidad, escalabilidad y seguridad.

Una de las funcionalidades más interesantes que nos ofrece SQL Database en Azure es la posibilidad de usar SQL sin servidor (serverless SQL). ¿Qué significa esto? Significa que podemos crear una base de datos que solo consume recursos cuando está activa, y que se pausa automáticamente cuando no hay actividad. De esta forma, podemos ahorrar costes y optimizar el uso de los recursos. Además, podemos escalar la base de datos según la demanda, sin tener que especificar un tamaño fijo.

¿Qué beneficios tiene usar SQL sin servidor?

Algunos de los más destacados son:

  • No tenemos que comprar ni mantener servidores físicos ni licencias de software. Solo pagamos por lo que usamos, según el tiempo y el rendimiento que consuma nuestra base de datos.
  • Podemos crear y eliminar bases de datos rápidamente, sin tener que esperar a que se aprovisionen o desaprovisionen los recursos.
  • Podemos adaptar nuestra base de datos a las fluctuaciones del tráfico o la actividad, sin tener que hacer cambios en el código ni en la configuración. Azure se encarga de ajustar los recursos automáticamente según la demanda.
  • Podemos acceder a nuestra base de datos desde cualquier lugar y dispositivo, usando las herramientas y lenguajes que prefiramos. Azure nos ofrece una alta disponibilidad y redundancia, garantizando un tiempo de actividad del 99,99%.
  • Podemos proteger nuestra base de datos con las mejores prácticas de seguridad, como el cifrado de datos en reposo y en tránsito, el control de acceso basado en roles, la auditoría y el monitoreo. Además, Azure nos ofrece copias de seguridad automáticas y opciones de recuperación ante desastres.
  • Podemos integrar nuestra base de datos con otros servicios de como Azure Synapse Analytics, Azure Machine Learning o Azure Data Factory, para obtener más valor e insights de nuestros datos.

¿Cómo podemos crear una base de datos SQL sin servidor en Azure?

El proceso es muy sencillo y podéis seguir los pasos que se indican aquí. Básicamente, tenemos que:

  1. Acceder al portal de Azure e ir al servicio SQL Database.
  2. Hacer clic en Crear recurso y seleccionar Base de datos única.
  3. Rellenar los campos del formulario con los datos de nuestra base de datos: nombre, grupo de recursos, servidor, etc.
  4. En el apartado Tamaño + rendimiento, elegir la opción vCore como modelo de compra y seleccionar la casilla Habilitar SQL sin servidor.
  5. Configurar los límites mínimos y máximos de vCore y memoria para nuestra base de datos.
  6. Revisar y crear la base de datos.

Una vez creada la base de datos, podemos conectarnos a ella usando las herramientas y lenguajes que prefiramos: SSMS, Azure Data Studio, Visual Studio Code, PowerShell, etc. También podemos usar el portal de Azure para administrar y monitorear nuestra base de datos.

¿Qué necesitamos para implementar una base de datos de Azure?

Como todo cambio tecnológico, usar SQL sin servidor en Azure implica algunos desafíos y adaptaciones, pero también nos abre un mundo de posibilidades. Algunos aspectos a tener en cuenta son:

  • Debemos elegir bien el nivel de rendimiento y los límites de recursos que queremos para nuestra base de datos. Azure nos ofrece una calculadora de precios que nos ayuda a estimar el coste de nuestra base de datos según el tiempo y el rendimiento que consuma.
  • Debemos tener en cuenta que nuestra base de datos se pausará automáticamente cuando no haya actividad, lo que puede afectar al tiempo de respuesta de la primera consulta después de la reanudación. Podemos configurar el tiempo de espera antes de la pausa, que por defecto es de una hora, según nuestras preferencias.
  • Debemos aprovechar las nuevas funcionalidades y características que nos ofrece SQL sin servidor en Azure. Por ejemplo, podemos usar la inteligencia artificial para mejorar la calidad y el análisis de nuestros datos, usando servicios como Cognitive Services o Azure Machine Learning. También podemos usar la computación distribuida para procesar grandes volúmenes de datos, usando servicios como Azure Synapse Analytics o Azure Databricks.

¿Cómo podemos migrar nuestra base de datos SQL Server a Azure?

Hay varias opciones disponibles, según el tamaño y la complejidad de nuestra base de datos. Algunas de las más comunes son:

  • Usar la herramienta Data Migration Assistant (DMA) que ya hemos visto en profundidad en este post.
  • Utilizar el servicio Azure Database Migration Service (DMS), que nos permite migrar nuestra base de datos online u offline, con una mínima interrupción del servicio y una alta fiabilidad.
  • Usar el método bacpac, que consiste en exportar nuestra base de datos a un archivo .bacpac y luego importarlo a Azure mediante el portal o PowerShell.
  • Utilizar el método log shipping, que consiste en copiar los archivos .mdf y .ldf de nuestra base de datos a un blob storage en Azure y luego restaurarlos mediante T-SQL.

Conclusión

SQL sin servidor en Azure es una excelente opción para usar SQL Server en la nube, con todas las ventajas que ello implica. Nosotros hemos creado algunas bases de datos SQL sin servidor en Azure y estamos muy satisfechos con los resultados. Os animamos a que lo probéis y nos contéis vuestra experiencia. Si tenéis alguna duda o comentario, podéis escribirnos por mail o seguirnos en nuestra cuenta de Twitter. ¡Hasta la próxima!

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

Data Migration Assistant: Migrar de SQL Server a Azure SQL

En el pasado post vimos las distintas soluciones de SQL en la nube. En este post vamos a hablar de la herramienta Data Migration Assistant (o DMA), una aplicación de Microsoft que nos va a permitir migrar bases de datos SQL de nuestros servidores On Premise a la nube de Azure de forma fácil y rápida. Esta herramienta es ideal para los profesionales que quieren aprovechar las ventajas de la nube, como la escalabilidad, la seguridad y el ahorro de costes, sin perder el control y el rendimiento de sus datos.

Que es Data Migration Assistant

Data Migration Assistant es una solución integrada que nos ofrece Microsoft para facilitar el proceso de migración de bases de datos SQL a Azure. Con esta herramienta, además, podemos realizar las siguientes tareas:

  • Analizar el estado y la compatibilidad de nuestras bases de datos SQL con Azure.
  • Seleccionar el servicio de Azure más adecuado para alojar nuestras bases de datos, ya sea Azure SQL Database, Azure SQL Managed Instance o Azure SQL Server en una máquina virtual.
  • Realizar la migración de los datos, los esquemas, los objetos y las configuraciones de nuestras bases de datos SQL a Azure.
  • Validar y monitorizar el resultado de la migración y resolver posibles problemas.

¿Cómo usar Data Migration Assistant?

Para usar Data Migration Assistant necesitamos tenerlo instalado en nuestro equipo local, no os preocupéis porque es una aplicación gratuita que nos permite realizar el análisis y la evaluación de nuestras bases de datos SQL. También necesitamos tener una cuenta de Azure con una suscripción activa.

El proceso de migración se realiza en cuatro pasos:

  1. Crear un proyecto de migración en el DMA, indicando el origen y el destino de los datos, el tipo de migración (esquema, datos o ambos) y el alcance del proyecto (una o varias bases de datos).
  2. Ejecutar una evaluación de las bases de datos seleccionadas, que nos mostrará un informe con los posibles problemas de compatibilidad, las recomendaciones y las acciones correctivas que debemos realizar antes de la migración.
  3. Crear o seleccionar el servicio de Azure donde queremos alojar nuestras bases de datos, configurando los parámetros necesarios como el tamaño, la ubicación, la red y la seguridad.
  4. Ejecutar la migración propiamente dicha, que se realizará en modo online u offline dependiendo del servicio de destino elegido. Durante la migración podremos ver el progreso y el estado de cada base de datos.

Al finalizar la migración podremos acceder a nuestras bases de datos SQL en Azure desde cualquier dispositivo y aplicación, con las mismas funcionalidades y herramientas que teníamos en On Premise, pero con las ventajas añadidas de la nube.

Otros usos de Data Migration Assistant

Además de para migrar hacia Azure, DMA nos permite realizar migraciones entre otros entornos incluidos de On Premise a On Premise, AWS a On Premise, incluso a servidores SQL en servidores Linux. DMA acepta como origen todas las versiones de SQL Server On Premise desde SQL 2005 hasta SQL 2022 así como AWS RDS. Como destino podremos seleccionar cualquier SQL On Premise desde SQL 2012 hasta SQL 2022 o los servicios de Azure ya mencionados.

Por si esto fuese poco, no solo migrará nuestras bases de datos sino también objetos como inicios de sesión, roles de servidor e, incluso, evaluará la viabilidad de la migración de los paquetes SSIS.

Alternativas

Si no queremos usar Data Migration Assistant para realizar la migración, existen otras alternativas como:

  • Usar el portal de Azure o PowerShell para crear y configurar manualmente los servicios de destino y copiar los datos mediante herramientas como SQL Server Management Studio (SSMS), Azure Data Studio o bcp.
  • Usar Azure Database Migration Service (DMS), que es un servicio gestionado que nos permite realizar migraciones online o offline con un mínimo tiempo de inactividad. DMS soporta más tipos de origen y destino que DMA, como Oracle, MySQL o PostgreSQL.
  • Usar otras herramientas o servicios externos que ofrezcan soluciones específicas para cada caso, como Apex, Flyway, Redgate o Attunity.

Conclusión

Data Migration Assistant es una herramienta muy útil cuando queremos llevar a cabo una migración de SQL Server a la nube o a un entorno local sin complicaciones ni riesgos. Con esta herramienta podemos realizar una migración rápida, segura y eficiente, aprovechando al máximo los recursos y servicios que nos ofrece Azure. Si os ha quedado cualquier duda o queréis contarme vuestra opinión os leo en los comentarios, en Twitter o en mi mail..

Publicado por Roberto Carrancio en Cloud, SQL Server, 2 comentarios