SQL Server

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

11
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.

Comentario Query Store

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.

 

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 2 comentarios
08
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.

Ostress Temporales

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

Contencion Temporales

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.

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!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
06
Nov
2024

Optimizando TempDB: Metadata Optimizada en Memoria

Desde SQL Server 2019, Microsoft ha introducido varias mejoras en el manejo de la base de datos TempDB, una de las más destacadas es la funcionalidad Memory-Optimized TempDB Metadata. Esta característica está diseñada para reducir significativamente los cuellos de botella causados por la contención (bloqueos) en tablas internas de metadatos en entornos de alta concurrencia. En este artículo, quiero detallaros cómo funciona esta funcionalidad, sus beneficios, limitaciones y cómo implementarla en un entorno de producción.

Introducción a Memory-Optimized TempDB Metadata

TempDB es una base de datos que juega un papel crucial en el manejo de objetos temporales y tablas intermedias en SQL Server. Cuando trabajamos en entornos con múltiples usuarios concurrentes, la gestión de los metadatos de TempDB (estructuras como tablas temporales, índices y otros objetos transitorios) puede generar una gran contención y afectar negativamente el rendimiento.

Con la funcionalidad de Memory-Optimized TempDB Metadata, introducida en SQL Server 2019, las tablas del sistema que almacenan esta metadata se transforman en tablas en memoria no durables. Esto reduce significativamente la latencia, ya que elimina la necesidad de acceder a disco para gestionar estos objetos, un proceso que antes provocaba bloqueos en entornos altamente concurridos​.

Ventajas de Memory-Optimized TempDB Metadata

Como acabamos de ver, uno de los principales problemas con TempDB en entornos de alta concurrencia es la contención en las estructuras de metadatos. Al mover estos datos a tablas en memoria, SQL Server minimiza los tiempos de espera provocados por bloqueos y esperas de recursos (latches), lo que permite a más transacciones concurrentes acceder y modificar objetos temporales de manera más eficiente​

Además, al eliminar las operaciones de E/S de disco en los metadatos de TempDB, se mejora el rendimiento en las consultas que dependen de tablas temporales, como las utilizadas en procesos ETL, análisis de datos y operaciones transaccionales intensivas. Las tablas en memoria, al ser no durables, proporcionan tiempos de respuesta más rápidos y un mayor rendimiento en general​.

Gracias a estas mejoras, SQL Server 2019 y versiones posteriores pueden escalar mucho mejor en términos de transacciones concurrentes. Básicamente, la reducción en la contención permite que el sistema gestione un mayor volumen de transacciones sin experimentar una degradación del rendimiento​.

Disponibilidad y Soporte en Plataformas

La funcionalidad de Memory-Optimized TempDB Metadata está disponible desde SQL Server 2019. Sin embargo, algo incomprensible, no está implementada en entornos como Azure SQL Database o Azure SQL Managed Instance, lo que podría ser un inconveniente para aquellos que utilizan estas plataformas. Sin embargo, para aumentar aún más mi incomprensión, las instancias SQL Server RDS de AWS (Amazon) sí soportan esta funcionalidad, lo que supone una ventaja para los usuarios de AWS sobre los de Azure al poder implementar esta mejora en sus entornos administrados​.

Limitaciones de Memory-Optimized TempDB Metadata

A pesar de las claras ventajas, es importante tener en cuenta algunas limitaciones al considerar habilitar esta funcionalidad. Si bien las tablas en memoria optimizadas para metadatos son una excelente mejora, cuando está habilitada esta funcionalidad no es posible crear índices columnstore en tablas temporales, lo que puede afectar a algunos escenarios de análisis de datos​.

Siguiendo con los índices columnares, esto no es solo un problema a la hora de crear tablas temporales. El procedimiento sp_estimate_data_compression_savings no se va a poder ejecutar en tablas que utilicen índices columnstore cuando la metadata optimizada está habilitada. Esto puede limitar aún más el uso de esta funcionalidad en procesos que requieren estimar ganancias de compresión​.

Otro de sus problemas y uno de los principales es que cuando se utilizan tablas en memoria optimizadas en una transacción, esas transacciones que acceden a estas tablas temporales no pueden acceder simultáneamente a otras bases de datos. Esto puede complicar ciertos patrones de uso donde se necesite trabajar con múltiples bases de datos en una sola transacción​.

Para finalizar este apartado, un último problema (aunque para mi menor) es que para habilitar esta funcionalidad, es necesario reiniciar el servicio de SQL Server. Esto implica que su implementación debe planificarse durante una ventana de mantenimiento para evitar interrupciones en el servicio​ pero es una actuación que haremos una vez solamente.

Cómo Habilitar Memory-Optimized TempDB Metadata

Para habilitar esta funcionalidad vamos a seguir un proceso relativamente sencillo. Existen dos formas principales de habilitarla, mediante T-SQL o mediante sp_configure.

 Mediante T-SQL:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON;

Mediante sp_configure:

EXEC sys.sp_configure N'show advanced options', 1;
RECONFIGURE WITH OVERRIDE;
EXEC sys.sp_configure N'tempdb metadata memory-optimized', 1;
RECONFIGURE WITH OVERRIDE;

Después de ejecutar estos comandos, es necesario reiniciar el servicio de SQL Server para que los cambios surtan efecto​

Casos de Uso Comunes

Una vez que hemos visto que sus limitaciones no nos afectan (o que podemos salvar esas limitaciones) y habiendo habilitado la característica, Memory-Optimized TempDB Metadata es particularmente beneficiosa en los siguientes escenarios:

  • Sistemas OLTP (transaccionales) de Alta Concurrencia: En estos entornos, la contención en TempDB puede ser un cuello de botella significativo. Al habilitar esta funcionalidad, se mejora la capacidad del sistema para manejar miles de transacciones concurrentes que dependen de tablas temporales.
  • Procesos ETL y Consultas Analíticas: Las consultas que dependen de grandes conjuntos de datos temporales pueden beneficiarse enormemente al eliminar la latencia asociada con la gestión de objetos temporales en disco.
  • Cargas de Trabajo Intensivas en TempDB: En sistemas donde TempDB juega un papel crucial para la creación de objetos temporales o transacciones de corta duración, esta funcionalidad puede marcar una diferencia significativa en el rendimiento.

Conclusión

La funcionalidad Memory-Optimized TempDB Metadata es una mejora poderosa para SQL Server 2019, diseñada para solucionar problemas de contención y mejorar el rendimiento en entornos con alta concurrencia. Si bien no está libre de limitaciones, su capacidad para reducir la contención y mejorar el rendimiento la convierte en una opción atractiva para entornos que dependen intensamente de TempDB. Con el tiempo, es probable que Microsoft siga refinando esta característica, ampliando su soporte y optimización para más escenarios​.

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!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario
28
Oct
2024

¿Es recomendable usar caracteríticas en Public Preview?

El uso de características en Public Preview en productos de Microsoft genera un debate interesante dentro de la comunidad. Aunque no estamos acostumbrados a ver el uso de versiones Public Preview en producción en soluciones como SQL Server o la mayoría de servicios de Microsoft Fabric, en otros productos como Power BI sí que es más común que los usuarios adopten las nuevas funcionalidades de una manera más temprana. Lo mismo podríamos decir del SSMS, que muchos usuarios trabajan diariamente con versiones Beta.

Lo cierto es que existen ventajas y desventajas asociadas con el uso de estas funcionalidades antes de que lleguen a su fase de General Availability (GA). En este artículo vamos a ver si realmente es recomendable adoptar estas características en entornos productivos o si es preferible esperar a que se estabilicen con la liberación oficial.

Fases de Desarrollo: Hay más opciones que Public Preview o General Available

Antes de que una funcionalidad llegue a liberarse, existen varias etapas o fases en el ciclo de vida de desarrollo de un producto en las que los usuarios pueden participar. Estas fases permiten a las organizaciones y profesionales evaluar y probar características en distintos niveles de madurez. 

Beta Interna

En esta fase, las funcionalidades son probadas internamente dentro de los equipos de Microsoft. Es una etapa completamente cerrada para el público externo y su principal objetivo es corregir los errores iniciales críticos.

Private Preview

Un grupo seleccionado de usuarios avanzados, generalmente MVPs, socios estratégicos o expertos en la materia, tienen acceso a esta etapa temprana del desarrollo. En esta fase el producto no está terminado aunque se presupone que ya tiene toda la funcionalidad necesaria (por eso la disponibilidad para probar) y, en ocasiones, podemos nosotros mismos solicitar el acceso. Durante esta etapa el feedback recibido por los usuarios es crucial para afinar la funcionalidad, pero se sabe que aún puede haber cambios significativos.

Public Preview

Esta fase abre la funcionalidad a un público más amplio y permite que cualquier usuario la pruebe bajo su propio riesgo. Las características aún pueden cambiar, pero es común que las funcionalidades ya sean bastante robustas. No obstante, Microsoft advierte explícitamente sobre posibles fallos y la falta de un Acuerdo de Nivel de Servicio (SLA) para esta etapa. Esta etapa tiene una doble función, por un lado, los usuarios prueban los productos y, en caso de detectar algún problema, pueden notificarlo a Microsoft. Por otro lado, esta prueba temprana puede ayudar a las empresas a asegurar la compatibilidad de sus soluciones nada más la versión definitiva sea liberada habiendo hecho previamente los cambios necesarios.

Release Candidate (RC)

Esta fase es el último paso antes del lanzamiento oficial. El producto está casi completamente terminado, y aunque puede haber pequeñas correcciones de errores, la funcionalidad ya está prácticamente estable. Es una fase clave para los usuarios avanzados que quieran probar en escenarios reales y asegurarse de que están preparados para la versión final.

General Availability (GA)

Por último tenemos la fase GA, esta es la fase en la que la característica se considera completamente lista para producción, respaldada por SLA y con soporte completo. A partir de aquí, la funcionalidad es considerada apta para cualquier entorno de trabajo, ya sea de misión crítica o no.

 

Estas fases permiten a los usuarios involucrarse en el desarrollo de las funcionalidades, influyendo en su evolución, pero también exigen un manejo cuidadoso del riesgo, especialmente en entornos productivos.

Ventajas de Usar Funcionalidades en Public Preview

Una de las principales razones por las que algunas organizaciones deciden implementar características en Public Preview es obtener una ventaja competitiva. La adopción temprana de nuevas capacidades en SQL Server, Power BI o Fabric puede permitir a las empresas explorar nuevas oportunidades o mejorar procesos antes que sus competidores.

Por ejemplo, cuando se lanzaron funcionalidades como Columnstore Index en SQL Server o avances en DirectQuery y Dataflows en Power BI, las organizaciones que adoptaron estas características en fases tempranas pudieron optimizar sus procesos de análisis y gestión de datos más rápidamente que aquellos que esperaron hasta la fase de GA​​.

Además, la fase de Public Preview ofrece a los usuarios la oportunidad de influir en el desarrollo del producto. Los comentarios proporcionados por los usuarios son fundamentales para corregir errores y ajustar las funcionalidades a los escenarios reales de uso.

Inconvenientes de Usar Funcionalidades en Public Preview

A pesar de las ventajas, las características en Public Preview también presentan inconvenientes. La principal preocupación es la estabilidad. Dado que las funcionalidades están en constante desarrollo, es posible que no sean completamente fiables o que presenten errores importantes, lo que puede tener un impacto negativo en entornos productivos.

Un ejemplo de este riesgo ocurrió con la implementación temprana de Columnstore Indexes en SQL Server. Aunque la funcionalidad prometía mejoras de rendimiento significativas, las primeras versiones presentaban limitaciones importantes que reducían su eficacia. Los usuarios que implementaron esta tecnología tuvieron que realizar modificaciones considerables en sus consultas para aprovecharla plenamente​.

Además, las funcionalidades en Public Preview no suelen estar cubiertas por acuerdos de nivel de servicio (SLA), lo que significa que no hay garantía de resolución rápida de problemas. En entornos productivos , especialmente de misión crítica, este es un riesgo que muchas organizaciones no están dispuestas a asumir.

¿Cuándo actualizar?

Uno de los dilemas más comunes en la adopción de tecnología es decidir cuándo es el momento adecuado para actualizar a una nueva versión una vez que ha alcanzado la fase de General Availability (GA). Aunque las versiones GA son estables y están listas para producción, la decisión de actualizar inmediatamente puede variar según el entorno y las necesidades del negocio.

En entornos productivos críticos, como bases de datos o aplicaciones de análisis de datos, puede ser prudente esperar entre 3 y 6 meses tras el lanzamiento de GA antes de actualizar. Este margen de tiempo permite que se identifiquen y solucionen posibles problemas que no fueron detectados en las fases de prueba y permite beneficiarse de actualizaciones menores y parches que mejoran la estabilidad.

Sin embargo, en productos como Power BI, donde las actualizaciones suelen ser menos arriesgadas, algunas organizaciones optan por actualizar inmediatamente para aprovechar las nuevas funcionalidades y mejoras de rendimiento. Aunque no están libres de riesgo y en más de una ocasión he visto problemas graves. En resumen, la decisión debe basarse en el entorno específico y el nivel de riesgo que la organización esté dispuesta a asumir. Personalmente, para este producto con actualizaciones mensuales mi recomendación es tener los entornos productivos siempre una versión por debajo de la última, es decir, esperar un mes. 

Para cerrar este apartado es importante destacar que no siempre es posible esperar para actualizar. En ocasiones, nos vemos obligados a actualizar nada más una versión es liberada para solucionar un incidente de la anterior. Por ejemplo la actualización acumulativa 15 de SQL Server 2022 soluciona una incidencia con CDC causada por la anterior actualización.

Estrategia de Pruebas con Public Preview

Si decidimos adoptar características en Public Preview o Release Candidate, es crucial tener un plan de pruebas bien estructurado. Implementar nuevas funcionalidades en entornos de pruebas antes de migrarlas a producción es una práctica esencial para mitigar riesgos.

Es imprescindible que las funcionalidades en Public Preview o RC se prueben en un entorno de desarrollo o pruebas separado de la producción. Esto evita que los problemas afecten al entorno productivo. Sin embargo, aunque separado, debería ser idéntico al entorno productivo. En este sentido, también es recomendable probar la funcionalidad bajo condiciones de carga similares a las de producción ayuda a identificar problemas de rendimiento que podrían no ser evidentes en pruebas ligeras.

Además deberemos implementar herramientas de monitorización y proporcionar retroalimentación a Microsoft sobre los problemas encontrados ya que esto permite un ajuste continuo de las funcionalidades y contribuye al desarrollo del producto.

Por último, siempre debemos tener un plan B, debe existir un plan para revertir los cambios si la nueva funcionalidad no funciona como se esperaba. Este es un paso crítico, especialmente en entornos de misión crítica.

Excepciones: SSMS Public Preview

Una excepción personal que sigo es con SQL Server Management Studio (SSMS). En este caso, Microsoft permite instalar las versiones en Public Preview junto con versiones estables anteriores sin desinstalar las mismas. Esto me permite probar nuevas características sin el riesgo de perder acceso a las herramientas que uso diariamente.

Mi estrategia es instalar SSMS en Public Preview en mi equipo de trabajo, pero no en los servidores de producción, obviamente. De esta forma, puedo probar las funcionalidades sin comprometer la estabilidad de los entornos críticos. Si las nuevas características funcionan correctamente, sigo usándolas; de lo contrario, siempre puedo volver a la versión estable. Además, reporto cualquier problema que detecte a Microsoft, lo que contribuye al desarrollo del producto.

Conclusión

La adopción de características en Public Preview o esperar a la fase de General Availability depende del nivel de riesgo que estemos dispuestos a asumir. Aquellos que buscan mantenerse a la vanguardia tecnológica y participar en el desarrollo del producto pueden beneficiarse de la adopción temprana, pero para entornos productivos críticos, es más seguro esperar hasta que la funcionalidad esté completamente probada y respaldada por un SLA. En algunos casos, como con SSMS, es posible adoptar un enfoque más flexible, probando las nuevas características sin comprometer la estabilidad operativa. Sin embargo, en general, la decisión de actualizar debe basarse en una evaluación cuidadosa del entorno, los riesgos y los beneficios esperados.

Y ahora os invito a debatir: ¿Cuál ha sido vuestra experiencia usando características en Public Preview? ¿Esperáis a la fase de GA para actualizar o adoptáis nuevas tecnologías en cuanto están disponibles? ¿Qué estrategias de pruebas habéis implementado para mitigar los riesgos?

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!

Publicado por Roberto Carrancio en Power BI, SQL Server, 0 comentarios
25
Oct
2024

La pronunciación de SQL: ¿Es-kiu-el o Sicuel?

Una de las discusiones más recurrentes cuando hablamos de bases de datos es cómo se debe pronunciar «SQL» cuando hablamos en inglés: ¿deberíamos decir es-kiu-el o, como mucha gente pronuncia, sicuel? Aunque a primera vista pueda parecer un tema trivial, la evolución de este debate está profundamente entrelazada con la historia de uno de los lenguajes más importantes para la gestión de bases de datos. En este artículo, vamos a hablar de la historia del origen de SQL y su impacto en sistemas como SQL Server y PostgreSQL, mientras aclaramos cómo y por qué se originaron estas dos pronunciaciones.

Orígenes de SQL: El nacimiento de SEQUEL

El lenguaje SQL, que significa Structured Query Language (Lenguaje de Consulta Estructurado), fue desarrollado a principios de la década de 1970 en los laboratorios de IBM por Donald D. Chamberlin y Raymond F. Boyce, basándose en las teorías relacionales de Edgar F. Codd. Inicialmente, el lenguaje se llamaba SEQUEL (Structured English Query Language). El nombre SEQUEL, en inglés, se asemeja fonéticamente a sicuel, por no decir que es prácticamente igual.

Este término refleja la idea original del lenguaje de ser una herramienta de consulta para gestionar bases de datos relacionales. Sin embargo, debido a problemas legales con una empresa británica que ya tenía registrada la marca SEQUEL, IBM decidió cambiar el nombre a SQL. A pesar de este cambio, muchos de los primeros usuarios continuaron usando la pronunciación sicuel, que evocaba al nombre original.

El cambio a SQL y la aparición de es-kiu-el

Aunque el nombre oficial pasó a ser SQL, la pronunciación original sicuel permaneció en uso, especialmente entre aquellos que ya estaban familiarizados con SEQUEL. Sin embargo, también comenzó a surgir una nueva pronunciación: es-kiu-el, que es simplemente el resultado de pronunciar las letras «S-Q-L» por separado en inglés (S es «es», Q es «kiu», L es «el»). Este enfoque más literal se volvió popular, especialmente en entornos más técnicos y entre usuarios que preferían la claridad de pronunciar las siglas tal cual.

Con el tiempo, ambas pronunciaciones coexistieron. La pronunciación sicuel estaba más arraigada entre quienes habían empezado a trabajar con el lenguaje en sus primeros días, mientras que es-kiu-el comenzó a ganar popularidad entre generaciones posteriores y en entornos donde era común pronunciar las siglas una a una.

SQL Server y el debate sobre la pronunciación

SQL Server, desarrollado por Microsoft, ha sido uno de los actores clave en la popularización de SQL a nivel mundial. Lanzado en 1989, este sistema de gestión de bases de datos relacional ha jugado un papel crucial en el crecimiento de SQL como estándar global. A lo largo de su historia, el equipo de SQL Server ha utilizado ambas pronunciaciones de SQL.

Si no me cree mira este vídeo de un anuncio de SQL Server protagonizado por Ed Esber y el mismo Bill Gates en 1989. En el video podemos ver cómo ambas pronunciaciones, sicuel y es-kiu-el, se utilizan de manera intercambiable. Esta falta de un consenso claro refleja cómo las dos formas han coexistido a lo largo del tiempo, sin una regla estricta que indique cuál es la «correcta».

PostgreSQL: Su influencia en la pronunciación

PostgreSQL, a menudo abreviado como Postgres, es otro sistema de gestión de bases de datos relacional que ha jugado un papel importante en la historia de SQL. Al igual que SQL Server, PostgreSQL ha influido profundamente en la evolución de SQL, aunque su origen es independiente.

PostgreSQL fue desarrollado en la Universidad de California en Berkeley en 1986 como parte del proyecto POSTGRES, liderado por el profesor Michael Stonebraker. Inicialmente, Postgres no estaba diseñado para utilizar SQL, sino que empleaba su propio lenguaje de consultas llamado QUEL. No fue hasta 1994 cuando PostgreSQL adoptó SQL como lenguaje estándar, lo que permitió que el sistema ganara popularidad en el ámbito empresarial.

En la comunidad de PostgreSQL, la pronunciación sicuel es también común, ya que se remonta al origen de SQL como SEQUEL. Sin embargo, al igual que con SQL Server, muchos usuarios optan por la pronunciación es-kiu-el, especialmente en países donde es común leer las siglas de manera literal, como ocurre en gran parte del mundo hispanohablante.

El impacto de PostgreSQL en la estandarización

PostgreSQL no solo adoptó SQL, sino que ha jugado un papel crucial en su estandarización y expansión. A lo largo de los años, ha implementado una serie de características avanzadas que luego se han incorporado al estándar SQL, lo que ha reforzado su posición como uno de los motores más potentes y completos. Entre sus aportaciones destacan:

  • CTEs recursivos (Common Table Expressions): Que permiten realizar consultas jerárquicas complejas.
  • Soporte avanzado para JSON: PostgreSQL fue pionero en el manejo de datos no estructurados con JSON, una capacidad que luego se ha vuelto esencial en otros sistemas.
  • Herencia de tablas: Una característica única que extiende el modelo relacional tradicional.

Estas características han influido significativamente en la dirección del estándar SQL y han ayudado a que PostgreSQL sea ampliamente reconocido como uno de los sistemas más avanzados y robustos.

La influencia cultural y regional en la pronunciación de SQL

La elección entre sicuel y es-kiu-el no solo refleja preferencias personales o generacionales, sino también influencias culturales y regionales. En muchos países de habla hispana, es más común escuchar es-kiu-el, ya que esta pronunciación se ajusta mejor a las reglas fonéticas del español. En cambio, en el mundo angloparlante, sicuel sigue siendo predominante, sobre todo entre aquellos que conocieron el lenguaje en su versión original como SEQUEL.

Este fenómeno se observa también en empresas globales, yo lo he visto hasta en Microsoft, donde las pronunciaciones varían incluso entre los empleados. La alternancia entre es-kiu-el y sicuel, como se muestra en el vídeo de SQL Server, subraya que ambas formas son aceptables, y la preferencia suele depender del contexto o de las personas involucradas en la conversación.

Conclusión

No existe una pronunciación «correcta» de SQL. Tanto es-kiu-el como sicuel son formas válidas de referirse al lenguaje. La pronunciación que elijas dependerá de factores como tu trasfondo, la región en la que trabajas y las preferencias de tu entorno. SQL, ya sea pronunciado como sicuel o es-kiu-el, sigue siendo el estándar indiscutible para la gestión de bases de datos relacionales y continuará evolucionando gracias a sistemas como SQL Server y PostgreSQL.

Este debate sobre la pronunciación es solo una pequeña parte de la rica historia de SQL, un lenguaje que ha transformado el mundo de los datos y que sigue siendo fundamental para la infraestructura tecnológica moderna. Lo importante, más allá de cómo lo pronuncies, es la capacidad que ofrece SQL para gestionar y manipular datos de manera eficiente y robusta.

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!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
23
Oct
2024
¿Es la nube una solución competitiva?

¿Es la nube una solución competitiva?

Para hacer una solución SaaS (Software as a Service) e IaaS (Infrastructure as a Service) basada en Azure SQL y SQL Server realmente competitiva a nivel empresarial, debemos ser críticos y realistas. Aunque la nube ha sido abrazada por la mayoría de las empresas, siguen existiendo debates sobre los costes, el rendimiento y si realmente es la mejor opción en todos los casos. La cuestión de si las soluciones en la nube son superiores a las on-premise sigue siendo un tema caliente, y en este artículo vamos a tratar de abordar esta comparativa con argumentos sólidos, analizando tanto las ventajas como las desventajas de cada enfoque.

¿Es la nube realmente más barata que on-premise?

Uno de los argumentos más comunes a favor de las soluciones en la nube, como Azure SQL Database y SQL Server en IaaS (Azure VM), es que son más baratas que las soluciones on-premise. Pero, ¿es esto siempre cierto? La respuesta corta es: depende. La realidad es que en muchos casos, las empresas descubren que los costes a largo plazo de la nube pueden exceder a los de las soluciones tradicionales on-premise, especialmente si no se gestionan adecuadamente. De hecho, he visto cómo algunas empresas han comenzado a reconsiderar su migración a la nube debido a las crecientes facturas de servicios como Azure.

Comparativa de costes: Nube vs. On-Premise

Azure ofrece una estructura de precios que parece atractiva a primera vista, con pagos por uso (pay-as-you-go) que prometen flexibilidad y ahorro. Sin embargo, en la práctica, la realidad de los costes en la nube es muy diferente. Cuando migras a la nube, hay varios factores que rápidamente pueden inflar la factura:

Costes ocultos

Aunque Azure permite escalar hacia arriba y hacia abajo según la demanda, las empresas a menudo subestiman las horas que sus máquinas virtuales (VMs) y bases de datos están en funcionamiento. Servicios como Azure SQL Database, Managed Instance y SQL Server en máquinas virtuales (IaaS) pueden escalar en función de la demanda, pero esto puede resultar en facturas inesperadas si no se implementan estrategias adecuadas de monitoreo y escalado automático​​. Además, para aprovechar estas ventajas, normalmente no basta con subir el código ya desarrollado (lift and shift) sino que hay que hacer adaptaciones para sacar partido a las ventajas de este nuevo paradigma.

Licenciamiento

Mientras que SQL Server on-premise requiere un pago inicial considerable por licencias, las soluciones en la nube suelen requerir un pago constante y por suscripción. Azure Hybrid Benefit promete ayudar a reducir estos costes reutilizando licencias de SQL Server existentes, pero la realidad es que muchas empresas no pueden aprovechar este beneficio de manera efectiva, o descubren que las economías de escala no son tan favorables como se prometía​. Por otro lado, estamos asistiendo lentamente a la adopción del modelo de suscripción en SQL Server on-premise como el modelo de facturación Software Assurance que, a costa de un pago anual, nos proporciona características extra a nuestra licencia.

Costes de salida de datos

Un aspecto frecuentemente pasado por alto es el coste de descarga de datos desde la nube. En algunas plataformas en la nube, los costes de mover datos fuera de la nube, ya sea para hacer backups, migraciones o simplemente para integraciones con sistemas locales, pueden ser significativos. Este es un coste que las soluciones on-premise no tienen.

Rendimiento La batalla entre la nube y on-premise

Ahora bien, el tema del rendimiento es otro punto de fricción importante entre las soluciones en la nube y las soluciones tradicionales. Aquí, la historia no siempre favorece a la nube. Aunque Azure SQL Database y las soluciones SQL Server en IaaS prometen escalabilidad casi infinita, la realidad es que on-premise sigue ofreciendo mejor rendimiento en ciertas cargas de trabajo intensivas.

Escalabilidad y latencia

La capacidad de escalar automáticamente en Azure es una ventaja indiscutible cuando hablamos de escenarios variables, como el comercio electrónico o los servicios de streaming, donde las cargas fluctúan enormemente. Sin embargo, este beneficio tiene un precio en términos de latencia y rendimiento constante. En entornos on-premise, con infraestructura dedicada, la latencia y el rendimiento son más predecibles. Las aplicaciones que requieren baja latencia y un rendimiento constante, como las transacciones financieras o sistemas de bases de datos de alta concurrencia, pueden seguir funcionando mejor en infraestructura on-premise​​.

Por ejemplo, en una base de datos SQL Server alojada en Azure Virtual Machines, aunque puedas optar por discos premium y múltiples núcleos de CPU, la realidad es que la latencia de red entre las capas de aplicación y base de datos sigue siendo un factor limitante. Incluso con las opciones de red más optimizadas en Azure, una base de datos en un entorno on-premise configurada correctamente sigue siendo significativamente más rápida.

La trampa de la escalabilidad «ilimitada»

Uno de los mayores argumentos de venta de Azure es la escalabilidad ilimitada. Pero aquí es donde surge un gran problema: la escalabilidad tiene límites prácticos en cuanto a la optimización de la infraestructura y el coste que estás dispuesto a asumir. A medida que tu base de datos crece y requieres más recursos, los costes también se disparan, y en algunos casos, escalar en on-premise puede ser una mejor solución a largo plazo. Si tu carga de trabajo es predecible y estable, invertir en un sistema robusto on-premise puede ser significativamente más rentable que pagar por la escalabilidad en la nube de manera indefinida.

Además, muchos desconocen que algunas de las estrategias de escalado más avanzadas, como el uso de Elastic Pools en Azure SQL o la implementación de sharded databases, requieren una cantidad considerable de desarrollo adicional para optimizar. Esto significa que la promesa de una escalabilidad sencilla y sin fricciones en Azure no siempre se cumple sin costes adicionales de desarrollo y mantenimiento​. Volvemos a lo que comentábamos antes, subir a la nube implica adaptaciones en el código y, muchas veces, solo nos será rentable para nuevos desarrollos.

Seguridad: ¿Es la nube realmente más segura?

Otro mito popular es que la nube es intrínsecamente más segura que las soluciones on-premise. Si bien Azure ofrece una gama de herramientas de seguridad impresionantes como Azure Security Center, en muchos casos, la seguridad en la nube depende de cómo la configures. Por ejemplo, la gestión de claves de cifrado, la configuración de firewalls y la implementación de políticas de acceso son tareas que, si no se configuran correctamente, pueden dejar a una empresa vulnerable a ataques o fugas de datos​. Es tan compleja esta gestión que, en los últimos años, estamos viendo como crece la demanda de arquitectos cloud en las empresas.

Además, las empresas con grandes cantidades de datos sensibles o que operan en sectores altamente regulados, como el financiero o sanitario, a menudo prefieren seguir manteniendo sus datos on-premise por un mejor control sobre el acceso físico y la localización de los datos. De hecho, muchas empresas todavía desconfían de la nube para manejar datos confidenciales, y optan por mantener una infraestructura híbrida u on-premise para cumplir con las normativas locales de protección de datos.

Por último, a esto habría que añadir las limitaciones en cuanto a cumplimiento normativo. En determinados sectores regulados alojar datos fuera de la infraestructura de la empresa o no está permitido o requiere de una carga burocrática elevada. Y aún siendo posible, hay que extremar las precauciones y elegir bien las zonas geográficas donde se van a alojar los datos para no incurrir en problemas legales.

¿Hacia dónde vamos?

Para mi está claro, el futuro es híbrido. A pesar de las ventajas que ofrece la nube, está claro que no es la panacea para todas las situaciones. Es aquí donde el modelo híbrido se convierte en una solución inteligente para muchas empresas. El uso de bases de datos SQL Server en Azure, combinado con una infraestructura on-premise bien gestionada, permite aprovechar lo mejor de ambos mundos. Puedes tener la flexibilidad de la nube para cargas de trabajo variables, al mismo tiempo que mantienes un rendimiento consistente y control total sobre los datos más sensibles en entornos locales.

El debate no se trata de «nube vs. on-premise», sino de cuándo y cómo aprovechar cada tecnología de manera efectiva. Por ejemplo, Azure Arc permite extender las capacidades de administración de Azure a entornos on-premise y otros entornos en la nube, facilitando una verdadera experiencia híbrida. Esto permite a las empresas beneficiarse de las herramientas de administración avanzada de Azure, mientras siguen utilizando su infraestructura local para cargas críticas.

Conclusión

La nube tiene ventajas indiscutibles en términos de flexibilidad, facilidad de escalado y disponibilidad global, pero eso no significa que sea la mejor opción para todas las empresas o todas las cargas de trabajo. Los costes y el rendimiento de las soluciones en la nube no siempre superan a las soluciones on-premise, especialmente cuando hablamos de cargas de trabajo predecibles o sensibles a la latencia. Como profesionales de bases de datos, debemos ser críticos y cuidadosos al considerar qué opción es la mejor para nuestros clientes o nuestras empresas.

La clave está en evaluar las necesidades específicas y no dejarse llevar por el bombo publicitario de la nube ni por la comodidad que nos dan años de experiencia on-premise. La mejor solución sigue siendo aquella que esté alineada con los objetivos de negocio, y esto podría implicar el uso de la nube, de soluciones on-premise, o de un enfoque híbrido.

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!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 0 comentarios
16
Oct
2024

UPDATE STATISTICS vs sp_updatestats en SQL Server

Como vimos en el pasado artículo, cuando gestionamos bases de datos en SQL Server, uno de los aspectos más importantes es asegurarnos de que las estadísticas están actualizadas. Las estadísticas son fundamentales para que el optimizador de consultas del motor de SQL Server pueda tomar decisiones eficientes sobre cómo ejecutar las consultas. SQL Server nos proporciona varias formas de actualizar estas estadísticas, y dos de las más comunes son el comando UPDATE STATISTICS y el procedimiento almacenado sp_updatestats. En este artículo, vamos a analizar a fondo las diferencias entre ambos, cómo y cuándo utilizarlos, y qué impacto tienen en el rendimiento general de nuestras bases de datos.

Importancia de las estadísticas en SQL Server

Las estadísticas en SQL Server son colecciones de datos que describen la distribución de valores en una o más columnas de una tabla o índice. Estas estadísticas ayudan al optimizador de consultas a estimar la cantidad de filas que devolverá una consulta, lo que a su vez le permite seleccionar los planes de ejecución más eficientes.

Cuando las estadísticas están desactualizadas, el optimizador puede tomar decisiones incorrectas sobre los planes de ejecución, lo que provoca un rendimiento deficiente en las consultas. De ahí la importancia de mantenerlas actualizadas, especialmente en bases de datos con un alto volumen de inserciones, actualizaciones o eliminaciones de datos.

¿Qué es UPDATE STATISTICS?

El comando UPDATE STATISTICS es una instrucción explícita que actualiza las estadísticas para una tabla o índice en particular. Nos ofrece un control muy granular sobre qué estadísticas actualizar y cómo hacerlo. Podemos especificar un conjunto de opciones que nos permiten, por ejemplo, actualizar las estadísticas basadas en un muestreo de datos o una recolección completa de todos los datos.

Sintaxis básica de UPDATE STATISTICS

Para actualizar una estadística en concreto podemos usar el comando UPDATE STATISTICS con la siguiente sintaxis:

UPDATE STATISTICS [NombreTabla] [NombreEstadística]

Sin embargo, podemos necesitar actualizar todas las estadísticas de una tabla llamada en concreto, en ese caso escribiremos:

UPDATE STATISTICS [NombreTabla] ;

Y si queremos actualizar una estadística específica de un índice, podríamos usar el nombre del indice en vez de el nombre de la estadística:

UPDATE STATISTICS [NombreTabla]  [NombreIndice] ;

El comando UPDATE STATISTICS también nos permite utilizar varias opciones avanzadas como FULLSCAN, SAMPLE, y RESAMPLE, que determinan el método que SQL Server utiliza para actualizar las estadísticas.

  • FULLSCAN fuerza a SQL Server a leer todas las filas de la tabla para actualizar las estadísticas.
  • SAMPLE nos permite definir un porcentaje o número de filas de la tabla que se usarán para actualizar las estadísticas.
  • RESAMPLE reutiliza las configuraciones de muestreo anteriores para actualizar las estadísticas.

Casos de uso de UPDATE STATISTICS

El uso de UPDATE STATISTICS es apropiado cuando necesitamos un control fino sobre el proceso de actualización de estadísticas. Por ejemplo en bases de datos críticas. En entornos de producción donde el rendimiento es crucial, y necesitamos asegurarnos de que las estadísticas de ciertas tablas grandes o muy consultadas se actualizan con precisión. Otro caso de uso es con tablas con datos muy volátiles. Si tenemos tablas que cambian frecuentemente, como las que contienen datos transaccionales, las estadísticas pueden quedar obsoletas rápidamente. En estos casos, podemos forzar la actualización periódica de las estadísticas con UPDATE STATISTICS.

Limitaciones de UPDATE STATISTICS

La principal desventaja de UPDATE STATISTICS es que requiere que seleccionemos manualmente las tablas o índices que deben ser actualizados. Esto puede ser laborioso en bases de datos con muchas tablas y estadísticas. Además, si no seleccionamos las estadísticas adecuadas, podríamos pasar por alto aquellas que se han desactualizado, lo que afectaría el rendimiento.

¿Qué es sp_updatestats?

sp_updatestats es un procedimiento almacenado proporcionado por SQL Server que actualiza todas las estadísticas en la base de datos actual que hayan sido marcadas como obsoletas. Este procedimiento es mucho más conveniente cuando queremos actualizar las estadísticas de toda la base de datos de forma masiva y automática, sin tener que preocuparnos por cada tabla o índice en particular.

Cómo funciona sp_updatestats

Cuando ejecutamos sp_updatestats, SQL Server examina todas las tablas y determina qué estadísticas deben actualizarse en función de la propiedad modification_counter (contador de modificaciones). Solo las estadísticas que hayan sufrido cambios significativos (según los algoritmos internos de SQL Server) serán actualizadas, lo que optimiza el uso de los recursos del servidor. Para ejecutarlo simplemente usamos:

EXEC sp_updatestats;

Al hacerlo, SQL Server actualiza automáticamente las estadísticas necesarias sin necesidad de especificar tablas, índices o configuraciones adicionales.

Casos de uso de sp_updatestats

El uso de sp_updatestats es más apropiado cuando necesitamos realizar una actualización general de las estadísticas en toda la base de datos. Algunos ejemplos de uso incluyen el mantenimiento periódico o las bases de datos con poca actividad.

En bases de datos grandes, donde no queremos revisar manualmente todas las tablas o índices, podemos usar sp_updatestats como parte de nuestras tareas programadas de mantenimiento para asegurarnos de que las estadísticas estén razonablemente actualizadas. Por el contrario, si nuestras bases de datos no experimentan muchos cambios de datos, sp_updatestats puede sernos suficiente para mantener las estadísticas actualizadas sin un impacto significativo en el rendimiento.

Limitaciones de sp_updatestats

Aunque sp_updatestats es conveniente, no nos ofrece el mismo nivel de control que UPDATE STATISTICS. Al ser un procedimiento almacenado, SQL Server decide qué estadísticas actualizar basándose en su propio criterio, lo que puede no ser siempre ideal en situaciones donde necesitamos precisión y control. Además, puede no actualizar todas las estadísticas que en realidad lo necesitan si los cambios en los datos no alcanzan los umbrales establecidos por SQL Server.

Diferencias clave entre UPDATE STATISTICS y sp_updatestats

Como acabamos de ver, los métodos de actualización manual de estadísticas tienen sus diferencias, lo que hace que cada uno sea indicado para un caso concreto. 

Mientras que UPDATE STATISTICS nos permite un control muy específico sobre qué estadísticas actualizar, sp_updatestats es una solución más generalizada.

Por otro lado, sp_updatestats es menos intensivo en términos de recursos, ya que solo actualiza las estadísticas que SQL Server considera desactualizadas, mientras que UPDATE STATISTICS puede ser más intensivo, especialmente si usamos opciones como FULLSCAN.

En cuanto a la sencillez, sp_updatestats es mucho más sencillo de utilizar en escenarios donde no necesitamos un control tan granular sobre las estadísticas. Sin embargo, si necesitamos actualizar solo ciertas tablas o índices críticos, UPDATE STATISTICS es la mejor opción.

Por último, sp_updatestats, gracias a sus características, es más adecuado para procesos automáticos de mantenimiento, mientras que UPDATE STATISTICS puede necesitar más intervención manual, dependiendo del caso de uso.

Cuándo utilizar cada uno

La elección entre UPDATE STATISTICS y sp_updatestats depende de las necesidades específicas de nuestro entorno de base de datos. Si estamos administrando una base de datos crítica con muchas consultas y necesitamos un rendimiento óptimo en tablas específicas, UPDATE STATISTICS con opciones avanzadas como FULLSCAN es la mejor opción. Esto garantiza que las estadísticas se actualicen con precisión y se basen en datos reales y completos pero tendrá un alto coste en recursos.

Por otro lado, si buscamos un enfoque menos manual y necesitamos actualizar las estadísticas de toda la base de datos sin dedicar demasiado tiempo a configurar el proceso, sp_updatestats es una opción rápida y eficaz, especialmente cuando se utiliza en combinación con tareas programadas de mantenimiento.

Conclusión

Mantener las estadísticas actualizadas en SQL Server es una parte fundamental del mantenimiento de la base de datos para asegurar el rendimiento óptimo de las consultas. Mientras que UPDATE STATISTICS nos da un control detallado sobre qué estadísticas actualizar y cómo hacerlo, sp_updatestats ofrece una solución más automatizada y general para mantener la base de datos en buen estado.

La clave está en conocer cuándo utilizar cada enfoque. Si gestionamos bases de datos con altos volúmenes de datos o con requisitos específicos de rendimiento, optar por UPDATE STATISTICS puede ser lo más adecuado. Sin embargo, en escenarios de mantenimiento general, sp_updatestats nos proporciona una forma conveniente y eficaz de mantener las estadísticas actualizadas sin esfuerzo manual adicional. Como siempre, es fundamental realizar pruebas y monitorear el impacto de estas operaciones en el rendimiento de nuestras consultas y en el uso de los recursos del sistema.

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!

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