SQL Server

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

Nov

2024

Replicar datos de SQL a Fabric

Mucho hemos hablado en el blog de como pasar datos de SQL Server en local a la nube, o de la nube a local. Sin embargo, siempre nos hemos centrado en el ecosistema de SQL Server y Azure SQL que, con pequeñas diferencias, cubren las mismas necesidades. Pero, ¿qué pasa si lo que necesitamos es pasar nuestros datos de SQL recurrentemente a un servicio SaaS en la nube para ciencia y análisis de datos?. Eso es lo que vamos a ver hoy, cómo pasar nuestros datos de SQL Server a Fabric ya sea a un Lakehouse o a un Datawarehouse.

Fabric lakehouse vs Datawarehouse ¿qué son?

Al hablar de Fabric, uno de los primeros pasos cruciales es entender sus componentes principales para el almacenamiento de los datos, el Lakehouse y el DataWarehouse. Aunque realmente todo lo que almacenemos en Lakehouse o en Datawarehouse va a estar almacenado en el mismo sitio, nuestro Onelake, por encima de esa capa pura de almacenamiento tendremos que decidirnos por una de las dos estrategias anteriores de gestión de los datos. Puede parecer trivial, incluso en muchas ocasiones se confunden o se utilizan indistintamente pero, la realidad es que cada uno tiene características y funciones específicas dentro de un entorno de ciencia de datos y análisis en la nube. Estas particularidades van a ser claves a la hora de trabajar con ellos por lo que es importante que tengamos claro cuál va a ser nuestro destino antes de plantear el método de envío de datos.

Fabric Datawarehouse

Fabric Datawarehouse es una solución de almacenamiento de datos que integra las capacidades de un data warehouse tradicional con la flexibilidad de un data lake. Gracias a esta arquitectura podremos almacenar, procesar y analizar grandes volúmenes de datos estructurados y semiestructurados en un entorno unificado, lo que nos facilitará la gestión y el análisis de la información.

Una característica distintiva de Fabric Datawarehouse es su almacenamiento centrado en el lago de datos (One Lake), basado en el formato abierto Delta Lake. Este enfoque nos permite hacer uso de transacciones ACID y una interoperabilidad fluida con otras cargas de trabajo de Fabric, eliminando la necesidad de múltiples copias de datos y garantizando la consistencia y confiabilidad de la información. Además su punto de conexión SQL nos va a permitir consultar y manipular datos con código T-SQL

Fabric Lakehouse

Fabric Lakehouse es una arquitectura de datos integrada en Microsoft Fabric que combina las funcionalidades de un data lake con las capacidades de un data warehouse. Esta estructura nos permite almacenar, procesar y analizar grandes volúmenes de datos no estructurados, semiestructurados y estructurados en un solo entorno, simplificandonos la gestión y el análisis de los datos.

El concepto de lakehouse en Fabric fusiona la escalabilidad y flexibilidad de un datalake, donde se puede almacenar información en su formato nativo, con el rendimiento y las capacidades analíticas de un data warehouse, facilitando la ejecución de consultas SQL de lectura directamente sobre los datos sin necesidad de moverlos. Fabric Lakehouse soporta el uso de diversos lenguajes de consulta y herramientas de análisis, como SQL, Spark y Power BI, proporcionando un entorno colaborativo y unificado.

Además, Fabric Lakehouse utiliza Delta Lake, que añade un nivel de transaccionalidad y consistencia a los datos almacenados, algo crucial en entornos de análisis donde la integridad de los datos es prioritaria. Delta Lake permite realizar lecturas y escrituras simultáneas y asegura la disponibilidad de datos limpios y consistentes para el análisis.

Enviar datos de SQL a Fabric

Bien, ahora que ya hemos decidido cual de los sistemas tenemos en destino vamos a ver las posibilidades de sincronización que tenemos para los datos de SQL. Vamos a centrarnos principalmente en dos herramientas, los Dataflows gen 2 y los pipelines.

Dataflows Gen2

Los Dataflows Gen2 son una opción no-code que nos permite llevar a Fabric datos de casi cualquier origen. Son una evolución de los Dataflows de Power BI, con un aspecto similar pero, con una gran diferencia, permiten seleccionar el destino. Gracias a esta funcionalidad vamos a poder usarlos para llevar nuestros datos de SQL o Azure SQL a Fabric, ya usemos Lakehouse o Datawarehouse, sin problema.

Para crearlo, simplemente accederemos a la interfaz de Dataflows Gen2 dentro del menú de Data Factory y, a través de la interfaz gráfica seleccionaremos nuestro origen, ya sea Azure SQL o una puerta de enlace previamente configurada con la conexión a SQL Server. A partir de aquí, podremos seleccionar las tablas o vistas que replicar y aplicar transformaciones, siempre cuidando de no romper el plegado de consultas o lo notaremos en el rendimiento.

Pipelines

Los pipelines son otra alternativa sencilla y no-code para la copia de datos, aunque tienen un inconveniente. Si bien es teóricamente posible usarlo para transferir nuestros datos desde SQL Server hacia Fabrik Lakehouse o Datawarehouse, lo cierto es que hacia este último destino va a requerir de una serie de pasos adicionales que complican el proceso hasta hacer que no sea recomendable, al menos en mi opinión.

Entonces, si vas a trabajar con Fabric Lakehouse la cosa es simple, abres Pipelines desde la misma ventana de Data Factory que hemos comentado antes y practicamente sigues el asistente. Te va a pedir el origen (tu Azure SQL o tu puerta de enlace con la conexión a SQL Server, igual que antes), la tabla o consulta que se va a replicar y el destino con su tipo de datos para cada columna.

Bonus track: Fabric Mirroring, Shortcuts y Notebooks

Los que conocéis el ecosistema de Fabric sabéis que además de Dataflows Gen2 y Pipelines tenemos disponibles otras herramientas como son los mirroring shortcuts y Notebooks. Veamos qué podemos hacer con ellas.

Shorcuts: Igual que los accesos directos a los que estamos acostumbrados en nuestros sistemas operativos de Windows, los shortcuts en Fabric nos permiten leer información de otras fuentes sin tener que copiarlas a nuestro One Lake. Suena bien, ¿verdad? Pues es muy bonito pero, lamentablemente no están implementados ni para SQL Server ni para ninguna solución de SQL en la nube.
Notebooks: Los cuadernos (notebooks) son la principal herramienta de integración y manipulación de datos en Fabric. Sin embargo, no son compatibles con orígenes de una puerta de enlace por lo que solo podremos usarlos para copiar datos desde orígenes Azure SQL ya sean Managed Instance o bases de datos sin servidor.
Mirroring: He dejado lo mejor para el final. Mirroring es una nueva funcionalidad que promete replicar nuestras bases de datos SQL a Fabric. Sin embargo, aún está en Public Preview y solo para orígenes Azure SQL Database (bbdd sin servidor). Esperemos en un futuro cercano verlo en GA para todos los orígenes SQL Server.

Conclusión

Migrar datos de SQL Server a Microsoft Fabric abre un mundo de posibilidades para el análisis avanzado en la nube. Con herramientas como Dataflows Gen2 y Pipelines, podemos transferir datos de manera eficiente y sin código hacia entornos unificados de Fabric, eligiendo entre el Lakehouse, ideal para datos en formatos variados, y el Data Warehouse, optimizado para consultas estructuradas. Fabric facilita la gestión y transformación de datos en un entorno SaaS seguro, apoyado en OneLake y Delta Lake, que garantizan consistencia y escalabilidad. Así, centralizamos el análisis y optimizamos el rendimiento, aprovechando todo el potencial de nuestros datos en la nube.

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 Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Nov

2024

Puertas de Enlace Power BI y Fabric

En el análisis de datos con Power BI o Fabric, las puertas de enlace juegan un papel fundamental. Son el puente que nos permite conectar de forma segura y eficiente los servicios en la nube de Microsoft con los datos locales de nuestra organización. Estas herramientas facilitan la comunicación entre los sistemas internos y Power BI, garantizando que los datos estén siempre actualizados y disponibles para análisis en tiempo real. Sin embargo, las puertas de enlace no solo son esenciales para Power BI; también pueden integrarse con Microsoft Fabric, potenciando los flujos de trabajo avanzados y las capacidades de procesamiento en paralelo. Este artículo se inspira en los artículos de Toni Jurado en explorandodatos.com, quien ha profundizado en las características esenciales y las mejores prácticas de las puertas de enlace en Power BI, y busca añadir una perspectiva integral sobre su uso y consideraciones técnicas.

¿Qué es una puerta de enlace de Power BI y Microsoft Fabric?

Las puertas de enlace de Power BI y Fabric son un componente de software (programa) que se instala en nuestros servidores locales y que permiten a los servicios en la nube de Microsoft conectarse de manera segura a los datos almacenados en nuestras instalaciones on-premises. Esto es especialmente valioso para las empresas que, por razones de seguridad o privacidad, no desean o no pueden migrar sus datos sensibles a la nube. La puerta de enlace actúa como un intermediario, procesando solicitudes de datos y cifrando la comunicación entre la fuente local y el servicio en la nube, asegurando así la privacidad y protección de la información.

En la práctica, la puerta de enlace permite realizar transformaciones y filtrados de datos en el entorno local, reduciendo el volumen de datos que se envía a la nube. Esto optimiza el uso del ancho de banda de la red y mejora el rendimiento de las consultas en Power BI o Fabric. Sin embargo, este procesamiento requiere recursos en el servidor donde está instalada la puerta de enlace, lo que implica ciertas consideraciones técnicas a la hora de configurarla y mantenerla.

Tipos de puertas de enlace: Personal y Estándar

Existen dos tipos de puertas de enlace y, aunque las dos opciones sirven para enviar nuestros datos de los servidores locales a la nube de Power BI o de Fabric, tienen sus diferencias significativas. Tendremos que elegir una u otra en función de nuestras necesidades.

Puerta de enlace personal

Esta versión está diseñada para un único usuario y es ideal para casos de uso individual o pruebas rápidas. Permite conectar Power BI con fuentes de datos locales, pero está limitada a un solo usuario y no es adecuada para entornos de producción. No es compatible con los servicios de Microsoft Fabric.

Puerta de enlace estándar

Pensada para su uso en entornos de producción, esta puerta de enlace puede ser utilizada por múltiples usuarios y soporta una configuración avanzada para integrarse, además de con Power BI, con otros servicios, como Power Automate, Power Apps y Microsoft Fabric. Es ideal para empresas que manejan grandes volúmenes de datos y requieren análisis en tiempo real.

Es importante tener en cuenta que, aunque las puertas de enlace personales son útiles para usuarios individuales, en entornos de producción o con Microsoft Fabric se recomienda siempre utilizar las puertas de enlace estándar. Esto garantiza el soporte multiusuario, configuraciones avanzadas de balanceo de carga y alta disponibilidad, que son esenciales para entornos de análisis de datos complejos.

Uso de las puertas de enlace: Orígenes de datos compatibles

Una de las grandes ventajas de las puertas de enlace en Power BI y Fabric es su compatibilidad con una amplia variedad de orígenes de datos locales. Esto permite a las organizaciones integrar en sus análisis en la nube prácticamente cualquier sistema interno sin necesidad de migrar los datos a la nube, y manteniendo el control y la seguridad de la información. A continuación, os nombro algunos de los principales orígenes de datos locales que pueden conectarse a través de las puertas de enlace estándar:

Bases de datos relacionales

Entre los sistemas compatibles podemos encontrar SQL Server, Oracle Database, MySQL, PostgreSQL, DB2 y Teradata. Estos sistemas tienen la capacidad de plegar las consultas y nos permiten la conexión en modo DirectQuery, que consulta los datos en tiempo real, o en modo de importación, ideal para escenarios de carga periódica. Ambos modos facilitan el análisis sin necesidad de replicar todos los datos en la nube.

Fuentes de datos de archivos

Las puertas de enlace permiten el acceso a archivos de Excel, CSV, archivos de texto, XML y carpetas compartidas en red. Los datos de estos archivos pueden ser actualizados automáticamente para reflejar la última versión sin intervención manual. Esto es especialmente útil en entornos donde los datos se almacenan en archivos distribuidos en múltiples ubicaciones.

Sistemas de almacenamiento en la nube privada

Las puertas de enlace pueden conectar servicios de almacenamiento en la nube privada alojados dentro del entorno corporativo, incluyendo SAP HANA y SAP BW. Estos sistemas se encuentran en muchas grandes empresas, y la puerta de enlace asegura que los datos permanezcan en la red local mientras están disponibles para análisis en Power BI y Fabric.

Sistemas de información y aplicaciones empresariales

Power BI y Fabric permiten conectarse a sistemas como Microsoft Dynamics 365 on-premises y servicios OData, incluyendo SharePoint on-premises y otros servicios web empresariales. Estas integraciones son clave para empresas que utilizan sistemas empresariales complejos y desean incorporar datos de múltiples fuentes sin comprometer la seguridad.

Sistemas de mensajería y API REST

Las puertas de enlace también son compatibles con servicios que utilizan API REST, lo que permite integrarse con aplicaciones internas que exponen datos mediante servicios web. Esta opción ofrece flexibilidad para conectar sistemas personalizados de la organización.

Configuración de puertas de enlace en entornos de producción

La instalación y configuración de una puerta de enlace requiere ciertos conocimientos técnicos, especialmente en entornos de producción. Para instalar una puerta de enlace, debemos contar con un equipo (idealmente un servidor) que cumpla con los requisitos técnicos de Microsoft y que esté optimizado para manejar el flujo de datos y la carga de procesamiento.

Una vez instalada, la configuración de la puerta de enlace se gestiona desde el portal de administración de Power BI, donde podemos definir permisos de acceso a las fuentes de datos, configurar la autenticación de usuarios y programar las actualizaciones de datos. Las opciones de administración permiten a sus responsables controlar el acceso de los usuarios y gestionar los permisos para asegurar que solo personas autorizadas puedan acceder a los datos a través de la puerta de enlace.

Buenas prácticas para la instalación de puertas de enlace

Existen ciertas buenas prácticas recomendadas para optimizar el rendimiento y la seguridad de las puertas de enlace en entornos corporativos. A continuación, os comparto algunas consideraciones clave a tener en cuenta al instalar una puerta de enlace:

Separación de la puerta de enlace y el servidor de bases de datos

Aunque pueda parecer tentador, no es recomendable instalar la puerta de enlace en el mismo servidor donde reside la base de datos, ya que ambos servicios requieren recursos significativos. Si comparten el mismo servidor, podrían surgir conflictos de recursos en momentos de alta demanda, afectando la estabilidad y el rendimiento de ambos servicios. En su lugar, se recomienda instalar la puerta de enlace en un servidor dedicado que cuente con recursos suficientes para manejar la carga de trabajo de la puerta de enlace.

Ubicación en la misma subred

Para minimizar la latencia y optimizar el rendimiento de las transferencias de datos, es ideal que la puerta de enlace y el servidor de origen de los datos se encuentren en la misma subred. Esto permite una comunicación más rápida y reduce el riesgo de pérdida de paquetes de datos. Cuando la puerta de enlace y la base de datos están en diferentes subredes o ubicaciones, se puede experimentar una mayor latencia, lo cual afecta la eficiencia en el análisis de datos.

Ahora una recomendación personal. El tráfico de datos generado entre la puerta de enlace y un servidor de base de datos puede ser considerable lo que puede afectar al rendimiento de la red y verse afectado por otros usuarios de la red. Para estos casos la solución ideal es una subred aislada entre el servidor de bases de datos y la puerta de enlace. De este modo, nuestro servidor de bases de datos tendrá dos tarjetas de red, cada una en una red, una para el tráfico de los usuarios y otra exclusiva de comunicación con la puerta de enlace. Tampoco es raro encontrarnos en escenarios empresariales con una subred entre servidores aislada de los usuarios. En estos casos, deberéis valorar con los técnicos de redes si la puerta de enlace debe ir en esta red o en una dedicada.

Además, en entornos corporativos complejos, se recomienda aislar el tráfico de la puerta de enlace y la base de datos mediante VLANs independientes. Esta práctica no solo permite gestionar mejor el ancho de banda como acabamos de comentar sino que mejora la seguridad. La segmentación es particularmente importante cuando se trabaja con datos sensibles, ya que ayuda a cumplir con las normativas de privacidad y seguridad.

Balanceo de carga y alta disponibilidad

En organizaciones con grandes volúmenes de datos o con una alta frecuencia de actualizaciones, es recomendable implementar un clúster de puertas de enlace. Esto permite distribuir la carga de trabajo entre varias instancias, garantizando alta disponibilidad. En caso de que una puerta de enlace falle, otra puede asumir su carga, evitando interrupciones. El balanceo de carga es esencial cuando se trabaja con Microsoft Fabric, especialmente cuando usamos procesamiento de datos en tiempo real que requiere una infraestructura robusta y estable. Estos cluster de puertas de enlace solo los podremos hacer con puertas de enlace estándar, las personales no lo permiten.

Monitorización de recursos

Como la puerta de enlace realiza procesamiento de datos local, es importante monitorizar regularmente los recursos del servidor, como CPU, memoria y uso de red. Si detectamos un uso elevado de recursos, podríamos necesitar escalar la capacidad del servidor o migrar la puerta de enlace a un servidor con mayor capacidad para evitar problemas de rendimiento.

Consideraciones especiales para Microsoft Fabric

Con la integración de Microsoft Fabric, las puertas de enlace han ampliado su funcionalidad, permitiendo manejar flujos de datos más complejos y ejecutar análisis en tiempo real. En entornos de Fabric, es fundamental que la puerta de enlace tenga acceso a suficiente capacidad de procesamiento para soportar las demandas adicionales. Esto incluye configuraciones avanzadas para equilibrar la carga de procesamiento y distribuir las solicitudes de datos de forma eficiente. Además, como ya os he mencionado solo las puertas de enlace estándar son compatibles con Fabric, no vamos a poder usar una puerta de enlace personal.

Conclusión

Las puertas de enlace de Power BI y Microsoft Fabric son herramientas indispensables para las organizaciones que necesitan conectar sus datos locales con el servicio en la nube de forma segura y eficiente. Al permitir el procesamiento local de datos, las puertas de enlace optimizan el uso del ancho de banda y aseguran que solo los datos necesarios se transmiten a la nube, reduciendo la carga en la red y mejorando el rendimiento.

Este artículo y las ideas expuestas han sido inspirados en los artículos de Toni Jurado en explorandodatos.com, quien ha compartido valiosos conocimientos sobre el uso de puertas de enlace en Power BI. También os recomiendo el video sobre este tema del Power Quiz presentado por Ricardo Rincón y Diego jurado con Toni Jurado como quiz maker.

Espero que esta guía contribuya a un entendimiento más profundo de estas herramientas y a su implementación eficaz en entornos empresariales. 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 Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Nov

2024

Obtener el plan de ejecución real de una consulta sin ejecutarla

La semana pasada hablamos del impacto de Query Store en el rendimiento de nuestros servidores. Veíamos que por norma general es prácticamente nulo pero, en casos concretos, con muchas consultas Ad Hoc podría llegar a ser un problema. Si está en uno de esos rarísimos casos donde los beneficios de Query Store no compensan su impacto en el rendimiento aun hay algo que vas a poder hacer para obtener el plan real de una consulta sin tener que llegar a ejecutarla.

Obtener el plan real es importante para medir el rendimiento de nuestras consultas y localizar problemas de rendimiento pero, el problema es que para ello necesitamos ejecutar la consulta y esta puede ser costosa. Por suerte, desde SQL Server 2019 tenemos una alternativa. Para poder hacer uso de ella es necesario configurar adecuadamente el servidor para que almacene el plan real en lugar de solo el estimado. En este artículo profundizaremos en cómo lograrlo, lo que facilita el acceso a estos planes sin impacto en el sistema productivo.

Introducción a los Planes de Ejecución en SQL Server

Como ya hemos visto en varias ocasiones en el blog, un plan de ejecución representa la secuencia de operaciones que SQL Server realiza para ejecutar una consulta. Estos planes se pueden clasificar en dos tipos:

Estimados: SQL Server los calcula antes de ejecutar la consulta, basándose en estadísticas de los índices y distribuciones de datos.
Reales: Se generan después de ejecutar la consulta, reflejando los datos y operaciones reales ejecutadas, incluyendo métricas de tiempo y consumo de recursos.

La posibilidad de acceder a un plan de ejecución real sin re-ejecutar la consulta es especialmente valiosa en entornos de producción. SQL Server 2019 introdujo una funcionalidad para almacenar estos planes reales en caché, permitiendo su análisis sin la sobrecarga de una nueva ejecución.

¿Por qué vas a querer almacenar el plan real de las consultas?

Guardar el plan de ejecución real en lugar del estimado nos ofrece una visión precisa del rendimiento y consumo de recursos en tiempo de ejecución de una consulta, algo crucial para entornos de producción. A diferencia del plan estimado, que se basa en estadísticas previas, el plan real refleja las operaciones exactas que SQL Server ejecuta, incluyendo ajustes específicos de paralelismo, decisiones en el uso de índices y variaciones en la ejecución según los datos y los recursos disponibles. Esta precisión nos permite identificar cuellos de botella y problemas de optimización, como el parameter sniffing, donde SQL Server puede seleccionar un plan ineficiente basado en parámetros iniciales de la consulta.

Además, el plan real permite observar el impacto de condiciones específicas del sistema, como bloqueos y alta carga de CPU o memoria, brindándonos una comprensión completa del rendimiento bajo diferentes estados. En resumen, esta visibilidad detallada nos facilita la optimización continua, ya que podemos detectar patrones de rendimiento y ajustar el sistema o la consulta para mejorar la eficiencia sin necesidad de re-ejecutar la consulta. En conjunto, el acceso a planes reales convierte el análisis de rendimiento en un proceso más efectivo, permitiéndonos una gestión más precisa y proactiva del rendimiento del sistema SQL Server.

Almacenar en caché planes de ejecución reales

SQL Server nos permite almacenar el plan de ejecución real en la caché de planes, en lugar de solo el estimado. Esta configuración es especialmente útil para detectar problemas de rendimiento, ya que proporciona información precisa sin la necesidad de una segunda ejecución de la consulta.

Para activar la traza globalmente en el servidor, podemos hacer uso de la traza 2451:

DBCC TRACEON(2451, -1);

Donde 2451 es el número de la traza que permite almacenar el plan real y -1 establece que la traza se active a nivel global para todas las bases de datos y usuarios.

Nota: Activar la traza puede aumentar el uso de recursos del sistema, ya que SQL Server debe registrar información adicional para cada consulta que se ejecuta. Además, activar esta función requiere vaciar la caché de planes por lo que es recomendable activarlo solo si es estrictamente necesario y preferiblemente en ventanas de mantenimiento programadas o aprovechando una intervención de un reinicio del servicio.

Otra opción es activar esta característica a nivel de base de datos para que no se aplique a todo el servidor. En este caso, aunque los riesgos son los mismos vamos a poder minimizar el impacto. Para activarlo a nivel de base de datos usaremos el siguiente comando sobre la base de datos donde queramos cambiar la configuración.

ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON;

Acceso al último plan de rjecución real

Una vez activada la traza o la configuración de base de datos, SQL Server almacenará los planes de ejecución reales en el caché de planes. Para acceder a ellos, utilizamos vistas de administración dinámica (DMVs) como sys.dm_exec_query_stats y sys.dm_exec_query_plan. Estas vistas nos proporcionan datos sobre las consultas y los planes almacenados en caché, permitiendo su análisis sin necesidad de re-ejecutar la consulta.

Ejemplo de consulta para obtener el último plan real

La siguiente consulta permite recuperar el último plan de ejecución real de las consultas en caché:

SELECT qs.creation_time, qs.last_execution_time, qs.execution_count, st.text AS query_text, qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
ORDER BY qs.last_execution_time DESC;

Esta consulta devuelve el campo query_text con el texto SQL de la consulta y el campo query_plan con el plan de ejecución en formato XML. Para ver el plan de ejecución gráfico, podemos hacer clic en el XML en SQL Server Management Studio (SSMS), lo cual nos permite analizar visualmente las operaciones ejecutadas, los índices utilizados y el costo relativo de cada operación.

Filtrado de una consulta específica

Si estamos buscando el plan de ejecución de una consulta en particular, es posible restringir los resultados usando un filtro en el texto de la consulta, lo cual facilita la identificación del plan específico entre todas las consultas en el caché:

SELECT qs.creation_time, qs.last_execution_time, qs.execution_count, st.text AS query_text, qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE st.text LIKE '%Parte del texto de la consulta%'
ORDER BY qs.last_execution_time DESC;

Nota: A la hora de introducir parte del texto de la consulta que buscas en el filtro ten en cuenta que debe ser parte de la consulta (normalmente un nombre de una tabla o de un campo) pero nunca uno de los valores de los campos por los que estás filtrando ya que SQL Server remplaza esos valores por parámetros a la hora de almacenar el plan.

Es decir, si quieres buscar la consulta “SELECT Campo1 FROM MiTabla WHERE Campo2=’tutifruti’;” podrás buscar por ‘%Campo1%’, ‘%Campo2%’ o ‘%MiTabla%’ pero no por ‘%tutifruti%’. Cuando encuentres el plan de ejecución vas a ver que lo que se ha guardado es algo parecido a esto “SELECT Campo1 FROM MiTabla WHERE Campo2=@0”

Consideraciones Finales

La capacidad de acceder al último plan de ejecución real sin re-ejecutar la consulta es una capacidad poderosa para los DBAs, especialmente porque nos facilita la tarea de buscar problemas de rendimiento. Esta configuración nos ofrece un enfoque integral para monitorizar, analizar y optimizar el rendimiento de las consultas en entornos de producción sin comprometer la estabilidad del sistema. Sin embargo, aunque este enfoque nos permite detectar problemas de rendimiento con precisión y realizar ajustes informados para mejorar la eficiencia general del sistema para mi sigue siendo mejor la alternativa de Query Store donde vamos a poder ver todo el historial de planes de ejecución a lo largo del tiempo que hayamos definido y no solo el último plan real almacenado en caché.

Nov

2024

Migrar datos de Azure a local

En ocasiones nos vamos a encontrar con que necesitamos migrar una base de datos que tenemos alojada en Azure hacia un entorno local, ya sea porque nuestras necesidades han cambiado y preferimos una solución on-premise o para pruebas. Sea cual sea el motivo lo cierto es que existen diferentes enfoques y herramientas disponibles y no todas las podremos usar en todos los casos. Vamos a verlo.

Análisis previo

Lo primero que tenemos que tener en cuenta es nuestra versión de SQL Server on-premise. Para esta tarea, un SQL Server 2022 actualizado con los últimos parches nos va a facilitar enormemente la tarea, no es un aspecto bloqueante pero sí que nos va a limitar las opciones que tenemos disponibles para el proceso.

Lo siguiente que debemos tener en cuenta es el tipo de solución en Azure de la que vamos a sacar los datos, como vamos a ver, las bases de datos sin servidor (Azure Database) nos van a limitar mucho las opciones. Si tenemos una Azure Managed Instance también tendremos que mirar qué configuración tenemos. Por defecto las managed instance tienen las bases de datos en modo de compatibilidad SQL Server 2022 pero esta configuración se puede cambiar por una configuración Always-up-to-date que, es una de las ventajas de la nube, pero que a la hora de pasar los datos a local también nos va a suponer una complicación.

Migrar con Archivos BACPAC

La exportación e importación de bases de datos a través de archivos BACPAC es uno de los métodos más utilizados para mover bases de datos entre Azure SQL Database, Azure Managed Instance y un servidor SQL local. Este archivo incluye tanto los esquemas como los datos de la base de datos, lo que permite una transferencia completa.

Para Azure SQL Database, esta opción es completamente compatible y el proceso es relativamente sencillo. En el caso de Azure Managed Instance, aunque también es posible, su uso es menos común ya que Managed Instance permite la creación de backups nativos (.bak), que son más rápidos y efectivos para bases de datos más grandes o complejas.

La configuración Always-up-to-date de Managed Instance no afecta al uso de BACPAC, ya que este formato es compatible con múltiples versiones de SQL Server. Sin embargo, si se importa un archivo BACPAC en un entorno SQL local con una versión más antigua de SQL Server, podría haber problemas de compatibilidad debido a nuevas características que no son soportadas en versiones anteriores.

Migrar con Archivos de Backup (.bak)

Uno de los métodos más directos para copiar bases de datos desde Azure Managed Instance a un servidor local es la restauración desde archivos de backup nativo (.bak). Esta opción no está disponible para Azure SQL Database, pero en Managed Instance es completamente compatible y el proceso es similar al que se realizaría con cualquier otra instancia de SQL Server.

No obstante, la configuración Always-up-to-date de Managed Instance puede afectar este método si el servidor local tiene una versión más antigua de SQL Server. Los archivos de backup generados en Managed Instance con la versión más reciente podrían incluir características o formatos de almacenamiento que no son compatibles con versiones antiguas.

Para usar este método de migración deberemos hacer una copia de seguridad de las bases de datos de Azure Managed Instance en un almacenamiento de Azure, descargaremos los archivos de copia y ya en local los podremos restaurar en nuestro SQL Server.

Generación de Scripts con Datos

La generación de scripts SQL es otra forma flexible de migrar bases de datos desde Azure SQL Database o Azure Managed Instance a un servidor local. Este método permite exportar tanto el esquema como los datos en un formato SQL ejecutable, que puede ser personalizado según las necesidades del entorno local.

Esta opción es completamente compatible tanto con Azure SQL Database como con Managed Instance, y no se ve afectada por la configuración Always-up-to-date ni por la versión de SQL Server. Sin embargo, si el script contiene características avanzadas introducidas en versiones más recientes de SQL Server, puede que no se ejecute correctamente en versiones más antiguas del servidor SQL local, lo que obligaría a realizar ajustes manuales en el script.

Para este tipo de migración, desde SSMS, seleccionamos la base de datos en Azure que queremos migrar. Utilizamos la opción «Generar scripts» desde el menú contextual (clic derecho sobre la base de datos). Se nos abrirá un asistente que nos permitirá elegir qué objetos queremos incluir en el script. Podemos optar por seleccionar todas las tablas, vistas, procedimientos almacenados y otros objetos de la base de datos, o solo algunos de ellos, según sea necesario. Para incluir los datos, debemos ir a las opciones avanzadas y seleccionar «Esquema y Datos» en la sección de scripts.
Esto generará un script que incluirá tanto las definiciones de las tablas como los comandos INSERT para poblarlas con los datos existentes. Una vez que el script está generado, podemos guardarlo en un archivo o abrirlo en una nueva pestaña de SSMS para ejecutarlo en el servidor de SQL Server local.
Este script creará la base de datos y restaurará tanto la estructura como los datos aunque es posible que debamos editar un poco las opciones de creación de la base de datos.

Migrar con el asistente de Importación/Exportación

El Asistente de Importación/Exportación de SQL Server, que utiliza paquetes SSIS, es una herramienta versátil para mover datos entre bases de datos en la nube y servidores SQL locales. Este método permite seleccionar qué tablas transferir, realizar transformaciones de datos durante el proceso y manejar grandes volúmenes de información.

Este método es compatible tanto con Azure SQL Database como con Azure Managed Instance, y no se ve afectado por la configuración Always-up-to-date. Sin embargo, la base de datos debe existir previamente en el entorno local. También os recomiendo usar el método anterior, aunque sin datos, previamente para crear los objetos ya que este asistente solo sirve para la copia de datos y si la tabla no existe la creará pero sin índices, restricciones, etc… El resto de objetos tampoco los va a crear este asistente.

Replicación de Datos con Azure SQL Data Sync

Azure SQL Data Sync es una herramienta diseñada específicamente para sincronizar datos entre bases de datos de Azure SQL Database y servidores locales de SQL Server. Esta opción es útil para entornos híbridos en los que se necesita mantener la sincronización de datos entre múltiples bases de datos.

Data Sync es compatible con Azure SQL Database, pero no puede utilizarse con Azure Managed Instance. Además, la configuración Always-up-to-date no influye en este método, ya que esta es una configuración exclusiva de Managed Instance. Sin embargo, la versión del servidor SQL local puede influir, especialmente si es necesario utilizar características de sincronización que no están disponibles en versiones más antiguas.

Migrar con Azure Managed Instance Link: Migraciones Online

Azure Managed Instance Link es una solución avanzada para realizar migraciones online entre Azure Managed Instance y servidores locales mediante Distributed Availability Groups que ha salido en GA el pasado octubre. Permite replicar datos en tiempo real, facilitando migraciones sin interrupciones significativas en el servicio.

Esta funcionalidad solo está disponible para Azure Managed Instance, por lo que no es compatible con Azure SQL Database. La configuración Always-up-to-date puede influir, ya que es necesario que la versión de SQL Server local sea compatible con las características de replicación de Managed Instance. La documentación dice que para que esta funcionalidad funcione correctamente, el servidor SQL local debe tener al menos SQL Server 2016 o una versión superior que soporte Distributed Availability Groups pero eso es para la replicación desde local a la nube, para una replicación bidireccional o de la nube a local vas a necesitar que el servidor local sea SQL Server 2022 CU 10 o superior y que la configuración Up-to-Date de Azure MI no esté activada.

Comparativa de opciones para migrar

Como lo que acabamos de ver tiene muchas variables y hay muchas opciones disponibles creo que la mejor manera de verlo todo claro es con esta tabla comparativa

Método	Compatibilidad con Azure SQL Database	Compatibilidad con Managed Instance	Impacto de la Configuración Always-up-to-date	Requisitos de Versión en SQL Server Local
BACPAC	Compatible	Compatible	No afecta	Puede fallar en versiones antiguas
Backup Nativo (.bak)	No compatible	Compatible	Puede afectar	Requiere misma versión o superior
Generación de Scripts	Compatible	Compatible	No afecta	Puede requerir ajustes en versiones antiguas
Asistente Import/Export	Compatible	Compatible	No afecta	No afecta
Azure SQL Data Sync	Compatible	No compatible	No afecta	Puede requerir versión reciente
Azure MI Link	No compatible	Compatible	No compatible	Requiere SQL Server 2022 CU 10 o superior

Conclusión

El proceso de copiar o migrar bases de datos desde Azure SQL a entornos locales de SQL Server varía en función del método elegido y de las características específicas del entorno en la nube y el servidor local. Las opciones como BACPAC y la generación de scripts son flexibles y ampliamente compatibles con ambas soluciones en la nube. Sin embargo, los backups nativos (.bak) y Azure Managed Instance Link son exclusivos de Azure Managed Instance, y su efectividad puede verse afectada por la configuración Always-up-to-date y la versión de SQL Server en el entorno local. Es fundamental tener en cuenta la compatibilidad de versiones y las características avanzadas en cada entorno antes de realizar una migración para asegurar un proceso fluido y sin interrupciones.

Nov

2024

Bloqueos con un SPID negativo

Los bloqueos en SQL Server son un componente fundamental en la gestión de transacciones concurrentes, asegurando la integridad y consistencia de los datos. Sin embargo, algunos bloqueos pueden presentar características inusuales, como aquellos que involucran identificadores de sesión (SPID) negativos. Estos bloqueos negativos pueden generar confusión si no se comprenden a fondo, ya que están relacionados con operaciones internas de SQL Server o problemas específicos en el manejo de transacciones y recursos.

En este artículo, vamos a ver en profundidad los bloqueos con identificadores de sesión (SPID) negativos en SQL Server, incluyendo los valores del -1 al -5, explicando qué significan, qué los causa y cómo diagnosticarlos y resolverlos. Como vais a poder ver a lo largo del artículo, estos bloqueos no serán los más comunes que nos vamos a encontrar pero si que tienen una gran importancia y debemos conocerlos.

Introducción a los bloqueos en SQL Server

El sistema de gestión de bloqueos de SQL Server asegura que las transacciones accedan a los recursos de manera controlada, evitando conflictos que puedan comprometer la integridad de los datos. Los bloqueos suelen ser representados por un número positivo, que identifica la sesión (SPID) que sostiene el bloqueo. Sin embargo, en situaciones especiales, SQL Server puede mostrar bloqueos con identificadores de sesión negativos.

Estos SPID negativos no representan directamente sesiones de usuario, sino que están relacionados con tareas internas del motor de SQL Server, como la gestión de transacciones distribuidas (DTC), recuperación diferida, y la gestión de latches (mecanismos de sincronización de memoria). A continuación, vamos a explorar cada uno de estos identificadores negativos y sus implicaciones.

SPID -1: Bloqueo por Orphaned Lock (bloqueo huérfano)

El identificador -1 se asocia con bloqueos huérfanos (orphaned locks). Un bloqueo huérfano es un bloqueo que SQL Server ha perdido de vista, es decir, SQL Server ha perdido la referencia a qué sesión tenía el control de dicho bloqueo.

Descripción: El SPID -1 indica que el bloqueo ha sido dejado huérfano, lo que generalmente ocurre debido a errores en la gestión de bloqueos. En muchas ocasiones, este comportamiento es el resultado de un bug en SQL Server o de una desconexión inesperada de una sesión que estaba reteniendo el bloqueo.

Causas comunes: Esto puede suceder si una conexión de cliente se cierra inesperadamente mientras sostenía un bloqueo o si SQL Server experimenta un problema interno que afecta la gestión de los bloqueos. Estos bloqueos huérfanos pueden impedir que otros procesos accedan a los recursos bloqueados.

Diagnóstico y solución: En la mayoría de los casos, SQL Server debería liberar automáticamente los bloqueos huérfanos, pero si persisten, es recomendable revisar los registros de errores (SQL Server error logs) para identificar posibles fallos. Si el bloqueo huérfano afecta el rendimiento del servidor o causa problemas de acceso a los datos, es posible que se necesite reiniciar la instancia de SQL Server o aplicar parches que solucionen el problema.

SPID -2: Bloqueo por Pending DTC Transaction (transacción DTC pendiente)

El SPID -2 está relacionado con las transacciones distribuidas (DTC, Distributed Transaction Coordinator) que están pendientes de finalización. Esto ocurre cuando la conexión del cliente, que formaba parte de una transacción distribuida, se desconecta y la transacción queda en un estado incompleto, esperando que el administrador de DTC (MSDTC) procese el estado final de la transacción.

Descripción: Este identificador de sesión indica que SQL Server está esperando una notificación de cambio de estado por parte del coordinador de transacciones distribuidas (MSDTC). La transacción no puede completarse porque los clientes asociados con la transacción distribuida se han desconectado antes de invocar el commit o rollback.

Causas comunes: Esto suele ocurrir cuando una aplicación cliente que maneja transacciones DTC se desconecta inesperadamente sin finalizar correctamente la transacción. SQL Server queda a la espera de que el cliente confirme si debe comprometer o revertir la transacción.

Diagnóstico y solución: Para resolver el problema, el cliente debe reconectarse y completar la transacción invocando explícitamente un commit o rollback. En situaciones donde el cliente no puede reconectarse, el administrador de SQL Server puede finalizar la transacción manualmente utilizando las herramientas del coordinador de transacciones distribuidas (DTC). También es útil revisar los registros de errores de SQL Server y del DTC para identificar qué causó la desconexión.

SPID -3: Bloqueo por Deferred Recovery (recuperación diferida)

El SPID -3 está relacionado con transacciones diferidas. Una transacción diferida es una transacción que ha sido marcada para ser revertida o recuperada, pero que no puede completarse de inmediato debido a que los recursos necesarios no están disponibles.

Descripción: Este identificador indica que SQL Server mantiene el bloqueo porque una operación de recuperación o reversión ha sido pospuesta. Esto suele ocurrir cuando una transacción está en proceso de ser revertida (rollback), pero la operación no puede completarse debido a problemas con los recursos implicados, como archivos o tablas que ya no están disponibles.

Causas comunes: Las transacciones diferidas suelen ocurrir cuando SQL Server no puede acceder a los recursos necesarios para completar la reversión de la transacción. Un ejemplo sería si una tabla o índice fue eliminado mientras una transacción estaba activa sobre esos objetos. También puede ser resultado de problemas de espacio en disco o de memoria.

Diagnóstico y solución: Para diagnosticar este tipo de bloqueo, puedes utilizar la vista sys.dm_tran_active_transactions, que muestra información sobre las transacciones activas, incluidas las diferidas. Generalmente, SQL Server resolverá estas transacciones diferidas cuando los recursos se vuelvan disponibles, pero en algunos casos podría ser necesario realizar acciones manuales, como restaurar la base de datos o liberar espacio en disco.

SPID -4: Bloqueo por Latch Transition (transición de latch)

El SPID -4 se refiere a las transiciones de latch. Un latch es una estructura interna de sincronización que SQL Server utiliza para gestionar el acceso a los recursos en memoria, como las páginas de datos en la caché de búferes.

Descripción: Este SPID indica que SQL Server está en el proceso de liberar un latch, pero dicha liberación aún no ha finalizado. Estos bloqueos suelen aparecer cuando SQL Server está manejando una alta carga de trabajo que involucra operaciones intensivas de lectura o escritura en memoria.

Causas comunes: Las transiciones de latch son comunes en operaciones de alta concurrencia, como cuando múltiples sesiones intentan acceder a las mismas páginas en la caché de búferes. Esto puede ocurrir durante operaciones de entrada/salida intensivas o en escenarios donde se produce una contención por el acceso a recursos de memoria.

Diagnóstico y solución: Para diagnosticar estos bloqueos, puedes utilizar la vista sys.dm_os_latch_stats para monitorizar las estadísticas de latches. Si los bloqueos relacionados con latches son frecuentes, puede ser necesario optimizar las consultas, rediseñar los índices o ajustar los parámetros de configuración de memoria de SQL Server. También puedes revisar el tamaño de la caché de búferes para asegurarte de que SQL Server tenga suficientes recursos de memoria para manejar la carga de trabajo.

SPID -5: Bloqueo por Latch Task Releasor (liberación de latch)

El SPID -5 está relacionado con la liberación de latches en SQL Server, específicamente con tareas del sistema que están en proceso de liberar un latch. Los latches de entrada/salida (I/O) son los más comunes que se liberan bajo este identificador.

Descripción: Este identificador de sesión indica que SQL Server está esperando que una tarea del sistema libere un latch. Los I/O latches son los más comunes en este tipo de situación, protegiendo el acceso a las páginas de datos durante operaciones de lectura o escritura.

Causas comunes: Los bloqueos con SPID -5 suelen aparecer cuando hay contención en la memoria, particularmente en las páginas de datos almacenadas en la caché de búferes. Si varios hilos intentan acceder a la misma página simultáneamente, SQL Server utiliza un latch para asegurar que sólo un hilo acceda a la página en un momento dado, lo que puede generar tiempos de espera.

Diagnóstico y solución: Para diagnosticar este tipo de bloqueo, puedes utilizar las vistas sys.dm_exec_requests y sys.dm_os_waiting_tasks para identificar las sesiones que están esperando la liberación de latches. Optimizar el diseño de índices o ajustar los patrones de acceso a los datos puede ayudar a reducir la contención por los latches. Además, monitorizar el uso de la memoria y evaluar si SQL Server tiene suficientes recursos para manejar la carga de trabajo puede ser necesario.

Conclusión

Los bloqueos con identificadores de sesión negativos en SQL Server son indicadores de operaciones internas y procesos de administración de recursos dentro del motor de la base de datos. Desde bloqueos huérfanos hasta problemas con transacciones distribuidas y latches, cada uno de estos SPIDs negativos tiene un significado específico y un impacto potencial en el rendimiento y la estabilidad del servidor.

Comprender la naturaleza de estos bloqueos y cómo diagnosticarlos es clave para asegurar el buen funcionamiento de SQL Server. Utilizar herramientas como las vistas de administración dinámica (DMVs) y monitorizar los registros de errores te permitirá identificar problemas antes de que afecten el rendimiento general del sistema. En muchos casos, las soluciones implican ajustes en la configuración de recursos, la optimización de consultas y, en situaciones más complejas, la intervención manual para liberar o resolver los bloqueos pendientes.

SQL Server proporciona un entorno robusto para la gestión de transacciones y acceso concurrente, pero la correcta interpretación de estos SPIDs negativos puede marcar la diferencia en la identificación temprana de problemas que podrían afectar el rendimiento de la base de datos.

Nov

2024

Impacto en el rendimiento de Query Store

Cuando hablamos de Query Store en SQL Server, lo hacemos refiriéndonos a una de las herramientas más útiles para controlar y mejorar el rendimiento de nuestras consultas. No es ningún secreto que es una herramienta que personalmente me encanta y, no es para menos, nos permite capturar el historial de ejecución, los planes utilizados y, lo más importante, las métricas asociadas. Sin embargo, el otro día, un seguidor me trasladó una inquietud en un comentario de YouTube y no es otra que si la activación de Query Store puede tener un impacto negativo en el rendimiento. Ciertamente, Query Store conlleva una carga adicional que, en ciertos entornos, debemos saber gestionar con cuidado.

En este artículo, vamos a profundizar en el impacto real que tiene el Query Store en términos de CPU, memoria y disco, y cómo podemos configurarlo para obtener el máximo beneficio sin comprometer el rendimiento de nuestros sistemas.

¿Qué hace Query Store y por qué es tan útil?

En resumidas cuentas, Query Store se encarga de registrar el historial de todas las consultas que se ejecutan en nuestra base de datos, junto con los planes de ejecución y sus métricas de rendimiento. Es como tener un «registro médico» de nuestras consultas, donde podemos ver qué ha ido mal (o bien) y cuándo. Esto nos permite identificar rápidamente problemas de rendimiento y aplicar soluciones, como forzar el uso de un plan de ejecución específico. Es decir, cuando una consulta empieza a tardar más de lo habitual, Query Store nos permite ver qué ha cambiado, ya sea el plan de ejecución o las estadísticas.

Antes de seguir, si quieres saber más sobre el funcionamiento de Query Store, te recomiendo leer el artículo que le dedicamos.

¿Cuánto impacto tiene realmente Query Store en el rendimiento?

Aunque tener todo ese control suena genial, también hay que ser conscientes de que capturar tanta información tiene un coste. Y eso es justo lo que venimos a analizar hoy. Veamos cómo afecta a los distintos recursos del sistema.

Consumo de CPU y memoria

Lo primero que debemos tener claro es que Query Store no afecta a la ejecución directa de las consultas, ya que guarda la información de manera asíncrona. Pero eso no significa que no utilice recursos. El impacto más notable en CPU y memoria ocurre cuando se agregan los datos de las consultas para almacenarlos. Dependiendo de la cantidad de consultas y el tipo de carga (ad-hoc o batch, por ejemplo), este proceso puede requerir más recursos.

Por lo general, el impacto en CPU suele ser pequeño, pero no inexistente. El procesamiento de los datos para agregarlos y almacenarlos puede generar una pequeña sobrecarga, especialmente si el servidor ya está bajo presión por una alta carga de trabajo.

Hablando sobre la memoria RAM, Query Store usa su propia caché en memoria para almacenar temporalmente los datos antes de volcar (flush) al disco. En entornos con mucha actividad, puede necesitar más memoria de lo esperado si los intervalos de flush son largos o si el servidor está cerca de su límite de uso de memoria.

Espacio en disco

Aquí es donde más suele preocuparnos el impacto de Query Store. Todos los datos capturados tienen que almacenarse en disco, y si no tenemos cuidado, la cantidad de espacio utilizado puede crecer rápidamente. En Azure SQL Database, por ejemplo, el tamaño máximo que podemos asignar a Query Store es de 10 GB. En SQL Server on-premise, no hay un límite y, aunque el espacio propuesto por defecto es de 1 Gb podemos configurar manualmente el espacio que necesitemos y podamos asumir.

Si trabajamos en un entorno de producción con una base de datos que recibe muchas consultas por segundo, podríamos empezar a ver cómo el espacio en disco se reduce rápidamente si no gestionamos bien la configuración. En muchos casos, el crecimiento de los datos es gradual, pero en sistemas con grandes volúmenes de consultas, los datos pueden acumularse más rápido de lo esperado.

¿Cómo minimizar el impacto de Query Store?

Como hemos visto, es cierto que Query Store añade cierta carga al sistema, sin embargo, hay varias formas de mitigar su impacto y asegurarnos de que siga siendo beneficioso sin comprometer el rendimiento. Aquí os dejo algunas estrategias prácticas.

Ajustar el intervalo de flush

El flush es el proceso por el cual los datos que Query Store guarda en memoria en un primer momento se escriben en disco para persistirse. De manera predeterminada, este proceso ocurre cada 15 minutos, pero puedes ajustar este intervalo para reducir la carga en momentos críticos. Si trabajas con una base de datos muy activa, podrías reducir el intervalo para evitar que se acumule demasiada información en memoria y así dispersar la carga de escritura.

Una buena práctica es empezar con el valor por defecto y observar el comportamiento del servidor. Si notas que el servidor tiene picos de uso de disco en momentos específicos, reducir el intervalo de flush puede ayudar a que la escritura de datos sea más constante y menos impactante. Como ves, esta configuración afecta tanto a la cantidad de RAM que demanda Query Store como al consumo de CPU necesario para mover los datos de la memoria al disco.

Limitar el uso de espacio en disco

No todas las consultas tienen que ser almacenadas indefinidamente. SQL Server te permite configurar límites de espacio para Query Store y también establecer políticas de retención que eliminen los datos antiguos. Esto es especialmente útil para evitar que la información histórica crezca sin control.

Recomendación: Establece un límite de espacio en disco que sea acorde al tamaño y volumen de consultas de tu base de datos. Por ejemplo, para bases de datos medianas, un límite de 500 MB podría ser suficiente. En bases de datos más grandes, este valor puede aumentar, pero es esencial realizar una monitorización constante.

Configurar la retención de datos

Muy ligado al punto anterior. No tiene sentido almacenar datos de consultas por años si solo los vamos a analizar durante las últimas semanas. Configura un período de retención que se ajuste a tus necesidades de análisis. En la mayoría de los casos, mantener entre 30 y 60 días de historial es suficiente para identificar patrones y resolver problemas de rendimiento.

Usar el modo CUSTOM de captura

De forma predeterminada Query Store está configurado con un modo de captura automático que no captura todas las consultas sino solo aquellas que el motor de base de datos considera relevantes para el rendimiento. Esto, se puede cambiar para capturar todas las consultas lo que claramente incrementará el consumo de recursos.

Sin embargo, con SQL Server 2019, se introdujo un modo CUSTOM que nos permite capturar solo aquellas consultas que nos interesan, según criterios específicos que podemos definir. Esto es extremadamente útil en entornos donde se ejecutan miles de consultas ad-hoc o de bajo valor, que realmente no necesitamos monitorizar en detalle. Al usar este modo, reducimos el volumen de datos capturados, lo que disminuye la carga en disco y memoria.

Monitorizar el impacto de Query Store

Como siempre, es clave monitorizar cualquier herramienta que utilicemos en nuestros servidores. SQL Server Management Studio (SSMS) nos ofrece varias vistas que nos permiten ver el impacto que Query Store tiene en términos de uso de CPU, memoria y disco. Estas vistas nos ayudarán a realizar ajustes si detectamos que la carga es mayor de lo esperado. Otra opción sería usar el monitor de recursos de windows y comparar el consumo con la herramienta activada y sin ella

Conclusión

Habilitar Query Store puede ser un gran aliado para mejorar el rendimiento de nuestras bases de datos, pero requiere un enfoque cuidadoso para no generar sobrecarga en el servidor. Al ajustar el intervalo de flush, limitar el uso de espacio en disco, y capturar solo los datos necesarios, podemos beneficiarnos de su potencial sin afectar negativamente el rendimiento general.

La clave está en configurar y ajustar Query Store según las necesidades específicas de nuestro entorno. En la mayoría de los casos, unos pequeños ajustes pueden marcar una gran diferencia en términos de rendimiento y eficiencia. Como siempre, no olvides monitorizar y realizar pruebas periódicas para asegurarte de que todo funcione de manera óptima.

Nov

2024

Gestión de tablas temporales en SQL Server

El uso de tablas temporales en SQL Server es común para el almacenamiento de datos temporales durante el procesamiento de consultas. Aunque su uso es sencillo, la eliminación de estas tablas debe gestionarse adecuadamente. Seguro que estás acostumbrado a ver algo parecido a esto “DROP TABLE #TEMPTABLE;” al final de las consultas que usan tablas temporales. Yo también, sin embargo, el otro día encontré un artículo que lo desaconsejaba.
El resumen es simple, con decenas de sesiones creando y eliminando tablas temporales en bucle, al final nos encontramos con tiempos de espera de PAGELATHes pero si no borramos las tablas y cerramos la sesión esto no pasa. El artículo en cuestión no solo captó mi curiosidad, David, un seguidor del blog, también lo vio y me lo mandó para que opinase al respecto. Yo me debo a vosotros así que aquí van mis pruebas. En este artículo, veremos como no siempre es la mejor idea y cómo puede llegar a generar problemas de contención en tempdb.

Introducción a las tablas temporales

Las tablas temporales, identificadas con el prefijo # (locales) o ## (globales), son útiles para almacenar datos que solo necesitamos de manera transitoria. Son empleadas comúnmente en escenarios como el almacenamiento de resultados intermedios, la manipulación de datos en procesos ETL, o la mejora del rendimiento de consultas mediante la reducción del número de accesos a disco.

Estas tablas residen en la base de datos tempdb, lo que las convierte en una solución conveniente para manipular grandes volúmenes de datos sin afectar el esquema de las tablas principales. Sin embargo, tempdb es un recurso compartido, lo que significa que un uso incorrecto de las tablas temporales puede afectar el rendimiento global del servidor SQL.

Impacto de la eliminación de tablas temporales en tempdb

Eliminar tablas temporales manualmente usando DROP TABLE puede parecer una buena práctica para liberar recursos, pero en ciertos contextos, como sistemas de alta concurrencia, esto puede exacerbar los problemas de contención en tempdb. Cada vez que una tabla temporal se crea o elimina, tempdb necesita actualizar sus páginas de asignación, lo que incrementa la posibilidad de bloqueos de tipo PAGELATCH.

El uso del DROP TABLE, por tanto, desencadena este problema y si abusamos de ello, podemos llegar a notarlo.Por el contrario si dejamos que las tablas temporales se eliminen solas al cerrar la sesión esto no pasa. La clave está en cómo se elimina la tabla mediante DROP TABLE y en alguna optimización (no documentada, por supuesto) que tiene SQL Server para liberar las tablas temporales al cerrar la sesión. En teoría, cada operación que implique la creación, modificación o eliminación de tablas temporales añade carga a las páginas de asignación, lo que puede desencadenar los problemas de contención pero, lo cierto es que esto no pasa si cerramos la sesión y dejamos que las tablas temporales se eliminen solas.

Probando el problema de las tablas temporales

Como sé que es lo que la mayoría estáis esperando, no me voy a enrollar más, aquí va mi prueba. Lo primero que debéis saber es que estas pruebas las he realizado en mi máquina de pruebas más potente (16 procesadores lógicos a 3,8GHz y 32Gb de RAM), con un SQL Server 2022 completamente actualizado y la tempDB en un disco SSD.

Para la prueba he usado la herramienta Ostress de la suite RML Utilities de Microsoft. Esta herramienta está desarrollada para hacer pruebas de estrés contra servidores SQL y, si os parece, otro día hablaremos de ella.

Primera prueba: Borrar las tablas temporales

Para esta primera prueba he creado este procedimiento almacenado que veis a continuación. Simplemente crea una tabla temporal, inserta un valor y borra la tabla temporal.

CREATE PROC [dbo].[DropTempTable]
AS
BEGIN
CREATE TABLE #TempTable (ID INT null)
INSERT INTO #TempTable values(1)
DROP TABLE #TempTable 
END

A continuación, haciendo uso de Ostress he ejecutado el procedimiento 1000 veces en 50 sesiones paralelas. Es decir, he abierto 50 conexiones a la vez a la base de datos y en cada una de ellas he ejecutado 20 veces el procedimiento.

El resultado, como podéis ver a continuación han sido los comentados tiempos de espera de PAGELATACH

Siguientes pruebas

Bien, lo comentado por Haripriya Naidu en su artículo parece que es cierto pero, ¿será cierto que si no borramos la tabla temporal los problemas desaparecen?

Para esta segunda prueba simplemente he creado un procedimiento almacenado como el anterior pero sin la parte del borrado de la tabla temporal. Lo he llamado NoDropTempTable y de la misma manera que antes lo he ejecutado con Ostress y, ¿sabéis qué? No ha ocurrido nada. Cero contención. Ni un solo problema. He repetido la prueba con 1000 ejecuciones pero esta vez en 100 sesiones simultáneas y nada, mismo resultado, todo bien. Va a resultar que es cierto, alguna optimización tiene el motor de base de datos que no genera estos tiempos de espera.

En este punto, tenía que probar otra cosa, pero para ello, antes tenemos que comprender por qué nos hemos encontrado con este problema. Vamos a ello y luego os sigo contando.

¿Qué es PAGELATCH y cómo afecta a tempdb?

Un PAGELATCH es una forma de sincronización de acceso en memoria que SQL utiliza para garantizar la coherencia cuando múltiples procesos intentan acceder a las mismas páginas de datos. En el contexto de tempdb, estos bloqueos ocurren cuando múltiples sesiones intentan crear, modificar o eliminar tablas temporales simultáneamente, ya que todas residen en tempdb, un recurso compartido entre todas las sesiones.

En concreto, el problema que acabamos de ver surge porque muchas sesiones intentan acceder a las mismas páginas de administración en tempdb, en particular las páginas PFS (Page Free Space), GAM (Global Allocation Map) y SGAM (Shared Global Allocation Map), que gestionan la asignación de espacio en disco. Esto provoca contención de recursos y puede causar que las operaciones que dependen de estas páginas se ralenticen significativamente.

La última prueba, borrar temporales pero en memoria

Ahora que ya sabemos que los PAGELATCH que estabamos viendo son causados por el acceso a las páginas donde se almacenan los metadatos de las tablas, ¿que pasará si habilitamos la opción de Memory-Optimized TempDB Metadata que vimos en el pasado artículo? Pues bien, según mis pruebas con esta característica que se lleva a memoria las páginas de metadatos de TempDB el problema desaparece. La velocidad de la memoria es capaz de asumir las operaciones de lectura y escritura sin generar contención.

Estrategias para mitigar los problemas de contención en tempdb

Para reducir el riesgo de bloqueos PAGELATCH en tempdb, especialmente cuando trabajamos con tablas temporales en entornos altamente concurrentes, podemos implementar las siguientes estrategias:

Habilitar Memory-Optimized TempDB Metadata como acabamos de ver. El problema es que esto, en entornos cloud de Azure no es compatible, como vimos ayer.
Aumentar el número de archivos de tempdb: Una de las estrategias más efectivas es aumentar el número de archivos de datos de tempdb para distribuir la carga entre varias páginas de asignación. Se recomienda tener al menos un archivo de datos por cada núcleo lógico, hasta un máximo de ocho archivos, para aliviar la contención en las páginas PFS. Aunque en mi caso con esos 8 archivos no ha sido suficiente, lo cierto es que la prueba con 50 sesiones simultaneas sobre TempDB es un poco exagerada.
Optimizar el uso de tablas temporales: Limitar el uso de tablas temporales a los casos en los que sean estrictamente necesarias. Cuando sea posible, se deben utilizar alternativas como variables de tabla, que no generan la misma carga sobre tempdb.
Reutilización de tablas temporales: En lugar de crear y eliminar tablas temporales repetidamente en la misma sesión, es recomendable reutilizarlas dentro de la misma transacción o procedimiento almacenado, reduciendo así el número de operaciones de creación y eliminación en tempdb.

Otras ventajas de no borrar las tablas temporales

Además de todo lo que hemos visto hasta ahora, existe otra ventaja de la que no hemos hablado para no borrar las tablas temporales antes de tiempo. Cuando creamos y utilizamos tablas temporales en SQL Server, el optimizador de consultas puede reutilizarlas para generar y mantener planes de ejecución eficientes. Estos planes son cruciales, ya que permiten al servidor recordar la mejor manera de ejecutar consultas similares en el futuro, reduciendo la sobrecarga computacional.

Si eliminamos manualmente las tablas temporales mediante DROP TABLE y luego las recreamos, el optimizador pierde la capacidad de aprovechar estos planes previamente generados. Esto significa que, en consultas repetitivas, SQL Server tendría que volver a calcular el plan de ejecución desde cero, lo que incrementa el tiempo de procesamiento y reduce el rendimiento global. En casos donde las mismas tablas temporales son necesarias en múltiples ocasiones dentro de la transacción, dejar que SQL Server gestione automáticamente su ciclo de vida puede mejorar significativamente la eficiencia, ya que el sistema tiene más oportunidades de reutilizar los planes de ejecución optimizados y reducir la carga sobre tempdb.

Conclusión

El uso de tablas temporales en SQL Server puede ser una herramienta extremadamente útil, pero en entornos de alta concurrencia puede generar problemas de rendimiento si no se gestiona adecuadamente. El riesgo principal no reside en el DROP TABLE manual en sí, sino en la concurrencia y la carga sobre tempdb, pero evitando el borrado evitaremos el problema. Otras estrategias para mitigar los bloqueos PAGELATCH incluyen aumentar el número de archivos de tempdb, limitar el uso excesivo de tablas temporales y aprovechar las mejoras de las versiones más recientes de SQL Server. Con estas precauciones, podemos garantizar un uso más eficiente de las tablas temporales, evitando bloqueos y manteniendo un rendimiento óptimo del sistema.

SQL Server

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes