Infra

Asignación AVANZADA de páginas en SQL Server

En nuestro pasado artículo vimos como SQL Server organizaba el almacenamiento de los datos en páginas de datos y como lo administraba gracias a páginas de metadatos. En ese artículo, os prometí que hablaríamos más de estas páginas de asignación. Es muy importante entender estos conceptos pues son imprescindibles para poder hacer una optimización avanzada y enfrentar con solvencia problemas complejos de almacenamiento. 

Como ya vimos en el pasado artículo, SQL Server administra el almacenamiento mediante estructuras internas diseñadas para optimizar la asignación y reutilización del espacio. Dentro de estas estructuras, las páginas de asignación juegan un papel clave en la gestión de las páginas y extensiones dentro de los archivos de datos (.mdf o .ndf). Estas páginas permiten un acceso eficiente a los datos y minimizan la fragmentación, asegurando el mejor uso posible del espacio disponible.

En este artículo, profundizaremos en la función y el comportamiento de las páginas de asignación en SQL Server, complementando la información que vimos y ajustando los detalles donde sea necesario para proporcionarnos una visión más completa.

Estructuras de asignación de espacio en SQL Server

Resumamos un poco lo que vimos en el pasado artículo. SQL Server organiza el almacenamiento en páginas de 8 KB, que se agrupan en extents de 64 KB (8 páginas). Para administrar la asignación de estas páginas y extensiones, SQL Server utiliza las siguientes estructuras especializadas:

  • PFS (Page Free Space) → Rastreo del uso del espacio en páginas individuales.
  • GAM (Global Allocation Map) → Rastreo de extensiones asignadas y libres.
  • SGAM (Shared Global Allocation Map) → Rastreo de extensiones mixtas con espacio libre.
  • IAM (Index Allocation Map) → Mapeo de asignaciones de páginas y extensiones a objetos específicos.

Ahora que ya hemos refrescado ideas vamos a  ver en detalle cada una de estas estructuras. Pero antes una pequeña aclaración. Todos los archivos de datos (mdf y ndf) empiezan siempre con la misma estructura, una primera página (página 0) con cabeceras, y a continuación una página PFS, una GAM y una SGAM (página 1, 2 y 3 respectivamente)

Páginas PFS (Page Free Space)

Para gestionar correctamente la asignación de almacenamiento es imprescindible tener controlado en todo momento cuánto espacio tienes libre. Las PFS controlan cuánto espacio libre hay dentro de cada página individual en un archivo de base de datos. Son fundamentales para la inserción eficiente de datos, ya que SQL Server puede identificar rápidamente qué página tiene espacio disponible para nuevas filas sin necesidad de asignar nuevas páginas.

Características de las páginas PFS

Cada página PFS rastrea el estado de 8,088 de datos (~64 MB de datos). Es decir, si la página PFS es la página 1 del archivo de datos nos vamos a encontrar con una de estas cada 8088 páginas de datos, 

Estas PFS se actualizan cada vez que una página de datos cambia de estado, por ejemplo, cuando se insertan o eliminan filas.

La información se almacena en bits dentro de la página PFS, con los siguientes valores:

0x00 → Página vacía.
0x40 → Página 1-50% ocupada.
0x80 → Página 51-100% ocupada.
0xC0 → Página completamente llena.
0xE0 → Página reservada para IAM u otros propósitos.

Ubicación de las páginas PFS en el archivo de datos

SQL Server es capaz de registrar con un Byte de información la página y su estado por lo que en una página PFS que es de 8KB podremos almacenar información de 8 * 1024 páginas de datos. Esto significa que las PFS aparecen cada 8,088 páginas en un archivo de datos. Por ejemplo, si la primera página PFS sabemos que está en la página 1, la siguiente estará en la página 8,089, la siguiente en la página 16,177, y así sucesivamente.

Consulta para inspeccionar páginas PFS

Podemos analizar las PFS con DBCC PAGE pero para ello vamos a tener que activar primero la traza 3604 para ver el resultado en SSMS y que no vaya al log de errores de SQL Server. Al comando DBCC PAGE le vamos a pasar como parámetros primero el ID de la base de datos, seguido del ID del fichero de datos, el número de página que queremos ver y un 3.

Páginas GAM (Global Allocation Map)

Las GAM rastrean la asignación de extensiones dentro del archivo de base de datos. Permiten a SQL Server identificar rápidamente qué extensiones están libres y cuáles han sido asignadas a objetos.

Características de las páginas GAM

Cada página GAM cubre 511,232 de datos (unos 3 GB de datos).

Utiliza 1 bit por extensión:
1 → Extensión libre.
0 → Extensión asignada.

Como sabéis, SQL Server no libera el espacio cuando los datos se borran sino que se lo queda y lo marca como disponible. Pues bien, GAM se usa cuando SQL Server necesita encontrar espacio disponible y no asignado para nuevos objetos. 

Almacenamiento GAM

Cada página GAM es una página de 8 KB (como todas) que contiene información de 63,904 extents (ya que cada bit representa un extent). Como cada extent tiene 8 páginas, esto significa que una página GAM puede rastrear 511,232 páginas, lo que equivale a aproximadamente 3 GB de almacenamiento. Pero no tienes por qué creer ciegamente en lo que yo te diga, vamos a hacer los números.

1 GAM = 8 KB = 8 * 1024 bytes = 8192  bytes
De estos 8192 bytes, 204 bytes están reservados por lo que quedan 7988 en una página  GAM. ¿Cuántas páginas de datos pueden cubrir 7988 bytes?
1 GAM = 7988 bytes = 7988 * 8 bits = 63904 bits
Entonces si una página GAM tiene 63904 bits y necesita 1 bit para registrar 1 extent eso significa que puede almacenar información de 63904 extents. Convirtamos eso en tamaño.
1 GAM = 63904 extents = 63904 * 8 páginas = 511232 páginas
11232 páginas * 8 KB = 4,089,856 KB
4,089,856 KB / 1024 = 3994 MB / 1024 = 3,3144 GB

Ubicación de las páginas GAM en el archivo de datos

Si ya sabemos que las GAM aparecen cada 511,232 páginas y que la primera GAM está en la página 2, podemos saber que la siguiente en la página 511,234, etc.

Consulta para inspeccionar GAM

Igual que hemos hecho antes podemos usar DBCC PAGE para ver las GAM.

Páginas SGAM (Shared Global Allocation Map)

Las SGAM funcionan de manera complementaria a las GAM y se utilizan para rastrear extents mixtos que aún tienen espacio disponible para nuevos datos.

Características de SGAM

Cada página SGAM cubre 511,232 páginas ( unos 3 GB de datos), igual que GAM. También utiliza 1 bit por extensión:
1 → Extensión mixta con espacio libre.
0 → Extensión completamente ocupada o no mixta.

SGAM se usa cuando SQL Server necesita encontrar espacio en extensiones mixtas para insertar nuevos datos sin asignar nuevas páginas.

Almacenamiento SGAM

Ubicación de las SGAM en el archivo de datos

Las SGAM aparecen cada 511,232 páginas, comenzando en la página 3, luego en la página 511,235, y así sucesivamente.

Consulta para inspeccionar SGAM

Páginas IAM (Index Allocation Map)

Las IAM rastrean qué páginas y extensiones pertenecen a un objeto específico, como una tabla o un índice. Cada página IAM cubre un solo objeto (una tabla o un índice) en un solo archivo. Incluso puede abarcar múltiples páginas y archivos si el objeto está distribuido. 

Las IAM almacenan la relación entre los objetos y sus páginas de datos distribuidas en el archivo de datos. A diferencia de las GAM y SGAM, las IAM no tienen una ubicación fija dentro del archivo, ya que se crean dinámicamente para cada objeto.

Consulta para inspeccionar IAM

En este caso es mucho más complicado porque las IAM no tienen ubicación fija pero si supiesemos el número de página podremos consultarlo igual con DBCC PAGE y en el resultado podríamos ver que páginas y extents pertenecen a ese objeto. 

Conclusión

SQL Server administra el almacenamiento de manera eficiente utilizando páginas de asignación especializadas como PFS, GAM, SGAM e IAM. Estas estructuras permiten al motor de base de datos optimizar el uso del espacio, minimizar la fragmentación y mejorar el rendimiento. Comprender su funcionamiento es clave para administrar bases de datos de manera óptima y solucionar problemas de asignación de espacio en SQL Server.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de 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

Gestión de almacenamiento en SQL Server

¿Alguna vez te has preguntado cómo hace SQL Server para gestionar los datos en disco? Y no sólo SQL Server, la administración eficiente del almacenamiento es fundamental para garantizar un rendimiento óptimo y una gestión eficaz de los datos en cualquier sistema gestor de bases de datos. El motor de base de datos tiene que utilizar estructuras bien definidas, como páginas y extensiones, para organizar y controlar el espacio en disco. Para nosotros, como DBAs o usuarios avanzados, comprender en profundidad estas estructuras y sus mecanismos asociados es esencial para diseñar, implementar y mantener bases de datos de alto rendimiento.

Páginas, la unidad atómica de almacenamiento en SQL Server 

Una página es la unidad básica de almacenamiento en SQL Server, en estas páginas se guardan nuestros datos y tienen un tamaño fijo de 8 KB, siempre tienen el mismo tamaño.

Cada página comienza con un encabezado de 96 bytes que contiene información crucial, como el número de página, el tipo de página, la cantidad de espacio libre y el ID de la unidad de asignación del objeto propietario. Las filas de datos se almacenan secuencialmente después del encabezado, y al final de la página se encuentra una tabla de desplazamiento de filas que facilita el acceso rápido a cada fila.

Tipos de Páginas en función su almacenamiento

SQL Server utiliza diversos tipos de páginas para almacenar diferentes tipos de información.

Aunque el usuario medio podría pensar que todo lo que hay son páginas de datos lo cierto es que este es solo un tipo de página. En concreto, son las páginas que almacenan las filas de datos de las tablas pero, excluyendo los datos de tipos como text, ntext, image, nvarchar(max), varchar(max), varbinary(max) y xml cuando la opción «text in row» está activada. Esos datos veremos que van a otro tipo especial de página.

En concreto a páginas de texto o imagen que son las encargadas de almacenar datos de objetos grandes (LOB), incluyendo text, ntext, image, nvarchar(max), varchar(max), varbinary(max) y xml.

Para cerrar con las páginas que almacenan datos tenemos que nombrar las páginas de índice que contienen esas entradas de índices que facilitan el acceso rápido a los datos.

Pero esto no es todo, no sólo hay páginas con nuestros datos, SQL Server necesita una serie de metadatos para poder gestionar todo esto y los almacena en las páginas de asignación. En este tipo de páginas incluimos las páginas GAM (Global Allocation Map), SGAM (Shared Global Allocation Map), IAM (Index Allocation Map) y PFS (Page Free Space), que gestionan la asignación y el seguimiento del espacio en la base de datos.

Extensiones, como realmente SQL Server gestiona el almacenamiento

Una extensión (lo encontrarás también como extent) es un conjunto de ocho páginas físicamente contiguas, totalizando 64 KB. Las extensiones son la unidad básica mediante la cual SQL Server gestiona el espacio de almacenamiento. 

Permitidme hacer un parón en este punto para interiorizar esto, vuelve a leer el párrafo anterior y grábatelo a fuego así, la próxima vez que tengas que preparar un nuevo disco para almacenar datos de SQL Server entenderás por qué es una buena práctica formatear los discos con un tamaño de asignación de bloques de 64 KB.

Ahora sé, volvemos con los extent y, nuevamente, nos encontramos con que existen varios tipos. En este caso, no dependen del tipo de los datos que estamos almacenando sino de si son o no dedicados para un objeto. 

De esta manera, podemos encontrar extensiones uniformes donde las ocho páginas son propiedad de un único objeto o extensiones mixtas donde las ocho páginas pueden ser compartidas por hasta ocho objetos diferentes, permitiendo una asignación eficiente para objetos pequeños. Es importante destacar que aunque el extent puede ser mixto, las páginas siempre son dedicadas al 100% para el mismo objeto.

Almacenamiento GAM
Almacenamiento SGAM

A partir de SQL Server 2016, veremos que el comportamiento predeterminado es asignar extensiones uniformes para la mayoría de las operaciones. En principio para optimizar el rendimiento pero bueno, eso es un tema discutible. 

Gestión del almacenamiento

Como hemos comentado antes, SQL Server emplea varias estructuras internas (páginas de asignación) para gestionar la asignación y el uso del almacenamiento. Aquí va un pequeño resumen aunque ya os adelanto que a este tema le vamos a dedicar un artículo completo porque tiene mucho de lo que hablar.

Páginas GAM: mapa global de asignación de almacenamiento

Las páginas GAM (Global Allocation Map) registran qué extents han sido asignadas en el archivo de datos. Cada bit en una página GAM representa una extensión: un bit en 1 indica que la extensión está libre, mientras que un bit en 0 señala que está asignada. Cada página GAM puede rastrear aproximadamente 4 GB de datos, cubriendo 64,000 extents.

Páginas SGAM: mapa global de almacenamiento compartido

Las páginas SGAM (Shared Global Allocation Map) indican qué extents mixtos tienen al menos una página disponible para su uso. Un bit en 1 significa que la extensión mixta tiene espacio libre, mientras que un bit en 0 indica que todas sus páginas están ocupadas o que no es una extensión mixta. Al igual que las páginas GAM, cada página SGAM cubre cerca de 4 GB de datos.

Páginas PFS: almacenamiento disponible

Las páginas PFS (Page Free Space) rastrean el estado de cada página individual en términos de asignación y espacio libre. Cada bit en una página PFS representa una página de datos y señala si está libre, parcialmente llena o completamente ocupada. Cada página PFS puede rastrear 8,088 páginas, lo que equivale aproximadamente a 64 MB de datos.

Páginas IAM: Mapa de asignación de índices

Las páginas IAM (Index Allocation Map) mapean las extensiones utilizadas por un objeto específico, como una tabla o un índice, en una unidad de asignación particular. Estas páginas permiten a SQL Server identificar rápidamente qué páginas y extensiones pertenecen a cada objeto, facilitando operaciones eficientes de lectura y escritura.

Consideraciones Avanzadas

Antes de cerrar este artículo quería remarcar unos conceptos sobre los que he podido pasar de manera tangencial antes. 

De cara a entender la compatibilidad con filas largas, aunque una fila de datos no puede dividirse entre múltiples páginas, SQL Server maneja columnas de longitud variable que pueden exceder los 8 KB moviendo parte de los datos a páginas especiales denominadas ROW_OVERFLOW_DATA. Esto permite almacenar filas que, en conjunto, superan el tamaño de una página estándar.

Otra cosa que hemos comentado pero que quería matizar es que en versiones anteriores a SQL Server 2016, las tablas e índices pequeños comenzaban utilizando extensiones mixtas y, al crecer, se les asignaban extensiones uniformes. Desde SQL Server 2016, el comportamiento predeterminado es asignar extensiones uniformes desde el inicio para la mayoría de las operaciones, mejorando el rendimiento en la gestión del almacenamiento. Sin embargo, ahora mismo, con los discos SSD modernos, las lecturas secuenciales ya no representan tanta ventaja como cuando los discos eran mecánicos y esta supuesta ventaja en rendimiento puede ser un problema de desaprovechamiento del almacenamiento. Tampoco es que importe mucho, los discos duros, a la vez que se hacían más rápidos, también han visto crecer su capacidad total y el coste del almacenamiento se ha reducido mucho.

Conclusión

Una comprensión profunda de las estructuras de almacenamiento en SQL Server, incluyendo páginas, extensiones y mapas de asignación, es esencial para administradores y desarrolladores que buscan optimizar el rendimiento y la eficiencia de sus bases de datos. Al dominar estos conceptos, es posible diseñar estrategias de almacenamiento que maximicen el uso de los recursos y aseguren operaciones de base de datos robustas y escalables.

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

Azure Data Studio ha muerto. Larga vida a VS Code.

El pasado 6 de febrero de 2025, Azure Data Studio (ADS) dejaba de recibir soporte y actualizaciones. Aunque se mantendrá operativo hasta el 28 de febrero de 2026, Microsoft ha dejado claro que el futuro del desarrollo SQL pasa por Visual Studio Code (VS Code) con la extensión MSSQL.

Este anuncio marca el fin de una era para quienes han utilizado ADS como su herramienta principal de administración y desarrollo SQL. Sin embargo, lejos de ser una mala noticia, este cambio representa una evolución lógica hacia un entorno más moderno, flexible y potente.

Hoy voy a desgranar qué significa el fin de Azure Data Studio, cómo afecta a los desarrolladores y DBAs, y por qué VS Code es el camino a seguir.

¿Por qué Microsoft ha decidido matar Azure Data Studio?

Azure Data Studio nació como una alternativa ligera y multiplataforma a SQL Server Management Studio (SSMS), con una interfaz moderna, soporte para notebooks y conectividad con Azure. Durante años, fue una herramienta fundamental para administradores de bases de datos y desarrolladores SQL, más bien para estos segundos, que buscaban una solución ágil.

Sin embargo, VS Code ha evolucionado hasta el punto de haber alcanzado en funcionalidad a ADS. Consolidar todo en un único entorno de desarrollo reduce la fragmentación y permite concentrar esfuerzos en una sola plataforma.

Motivos clave detrás de la migración a VS Code

Principalmente, como ya he comentado, VS Code ha mejorado tanto que ya hace todo lo que hacía ADS y más.

Con la extensión MSSQL, VS Code soporta conexiones a SQL Server, Azure SQL Database y Fabric. Pero no solo conectar, obviamente permite ejecutar consultas, visualizar esquemas, exportar resultados y administrar bases de datos con una experiencia optimizada.

Además, en VS Code tenemos a nuestra disposición herramientas avanzadas como Table Designer, Query Execution Plans y scripting.

Menos fragmentación, más velocidad de innovación

Por supuesto, mantener dos herramientas similares implica duplicar esfuerzos. Esto es otro de los principales motivos para consolidar todo en VS Code. De esta manera, Microsoft acelera el desarrollo de nuevas funcionalidades y se eliminan inconsistencias entre ADS y VS Code, asegurando que todos los usuarios tengan acceso a las últimas mejoras.

Integración total con el ecosistema DevOps y CI/CD

A día de hoy VS Code es la herramienta más utilizada por desarrolladores de software. Su ecosistema de extensiones permite integrar bases de datos con herramientas de DevOps, CI/CD y control de versiones. Microsoft está apostando por una experiencia SQL que encaje dentro del mundo cloud-native y automatizado.

¿Qué ofrece VS Code con la extensión MSSQL?

Si aún no has probado VS Code como entorno SQL, te sorprenderá lo completa que es su experiencia con la extensión MSSQL.

Como funciones destacadas de VS Code para SQL Server podemos encontrar el soporte para filtrado, ordenación y exportación a JSON, CSV y Excel. También la administración visual de bases de datos gracias a las herramientas Object Explorer y Table Designer que nos permiten gestionar esquemas sin escribir código. En cuanto a las herramientas de optimización del rendimiento SQL tenemos un visualizador de planes de ejecución de consultas. 

Por último, pero importante tenemos el soporte para DevOps y CI/CD especialmente pensado para proyectos de bases de datos SQL para integración con pipelines de despliegue. Esto es totalmente compatible con herramientas de control de versiones y automatización como Git o Azure DevOps.

Y no olvidemos que es extensible y personalizable, ya fuera de lo que es SQL tiene miles de extensiones disponibles en el marketplace de VS Code con soporte para Python, PowerShell, Bash, Kubernetes y más, todo en el mismo entorno.

Cómo migrar de Azure Data Studio a VS Code

Microsoft ha asegurado que la transición de Azure Data Studio a VS Code será sencilla, ya que casi todas las funcionalidades de ADS ya están disponibles en VS Code con la extensión MSSQL. 

Para la migración lo primero que debemos hacer, obviamente, es descargar e instalar VS Code. Una vez hecho esto deberemos instalar la extensión MSSQL ya sea desde el Marketplace de Extensiones (buscando «SQL Server (mssql)») o con este comando en la barra de búsqueda de comandos de VS Code:

Con todo instalado es el momento de configurar las conexiones a bases de datos Usa la opción «Agregar conexión» para configurar tus servidores SQL Server o Azure SQL.

Puedes trasladar manualmente tus conexiones de ADS sin necesidad de migración de datos. 

Por último, si usabas notebooks Jupyter, puedes instalar la extensión de Jupyter en VS Code. 

Y si eres administrador de bases de datos o necesitas funcionalidades avanzadas para SQL Server Agent y Schema Compare, existen alternativas dentro de SQL Projects y herramientas de terceros. Esto no es lo ideal pero, es lo mismo que nos pasaba en ADS y el motivo por el que, al menos de momento, yo sigo prefiriendo SSMS para trabajar.

Preguntas frecuentes sobre la transición

A continuación os respondo algunas de las preguntas que he visto sobre el tema de la desaparición de Azure Data Studio

¿Pierdo funcionalidades si dejo de usar Azure Data Studio?

No realmente. VS Code con MSSQL Extension cubre casi todas las funcionalidades de ADS, y en muchos casos, las mejora. Es cierto que no tiene todas las opciones que nos da SSMS pero es que ADS tampoco las tenía.

¿Mis scripts y consultas seguirán funcionando en VS Code?

Sí. No necesitas modificar nada. Lo que cambia es la herramienta de conexión pero los scripts SQL que ejecutabas en ADS funcionan sin problemas en VS Code porque vas a usar los mismos servidores.

¿Qué pasa si no quiero cambiarme de ADS?

¿Eres un rebelde y te gusta ir contracorriente? No pasa nada, puedes seguir usándo ADS hasta febrero de 2026, pero ya no recibirás actualizaciones ni soporte. El cambio es inevitable amigo.

Conclusión

Azure Data Studio nos ha servido bien, pero VS Code representa el futuro del desarrollo SQL. Con una comunidad activa, actualizaciones constantes y una integración más fluida con herramientas modernas, VS Code con MSSQL Extension es la mejor alternativa para administrar bases de datos SQL. Si aún no has probado VS Code, este es el momento perfecto para hacer la transición y aprovechar todas sus ventajas. Yo prometo hacer pronto un video en mi canal de youtube explicando la interfaz.

Para más información, consulta la documentación oficial.

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

Integración de FILESTREAM y FileTable con Always On Availability Groups

La combinación de FILESTREAM y FileTable con Always On Availability Groups en SQL Server permite gestionar datos no estructurados con integridad transaccional (FILESTREAM y FileTable) mientras se garantiza alta disponibilidad y recuperación ante desastres (Always On). Sin embargo, esta integración no está exenta de retos, lo que requiere un enfoque y mantenimiento planificados y precisos. En este artículo, quiero hacer una introducción a cómo configurar estas tecnologías y resolver los problemas más comunes que surgen en su implementación. No pretendo generar una guía paso a paso, simplemente introducir los conceptos clave que debéis tener en cuenta.

Introducción a FILESTREAM, FileTable y Always On Availability Groups

FILESTREAM es una funcionalidad de SQL Server que habilita el almacenamiento de datos binarios grandes (como imágenes, documentos o vídeos) directamente en el sistema de archivos. Esto permite a las aplicaciones interactuar con los datos mediante APIs de sistema de archivos estándar, mientras que SQL Server mantiene la consistencia transaccional.

FileTable extiende FILESTREAM al ofrecer una estructura predefinida que facilita la gestión de datos no estructurados. Proporciona una forma más sencilla de organizar los archivos almacenados, permitiendo su acceso directo a través de rutas de sistema de archivos además de la base de datos.

Por su parte, Always On Availability Groups ofrece un modelo avanzado de alta disponibilidad y recuperación ante desastres a nivel de base de datos. Su capacidad para replicar datos entre réplicas en distintas ubicaciones lo hace ideal para garantizar continuidad en el servicio.

Cuando se combinan FILESTREAM y FileTable con Always On, surgen retos relacionados con la sincronización de datos, el acceso mediante Nombres de Red Virtual (VNN) y la compatibilidad funcional tras un failover.

Requisitos previos y consideraciones iniciales

Para garantizar una integración exitosa, es fundamental cumplir con ciertos requisitos previos:

Habilitar de FILESTREAM en todas las instancias del grupo

Debemos asegurarnos de que FILESTREAM esté habilitado en cada instancia del grupo de disponibilidad. Esto incluye habilitar el acceso a través de Transact-SQL y APIs de sistema de archivos.

Configuración del clúster y actualizaciones

Si utilizamos Windows Server 2012 o versiones más recientes, deberemos asegurarnos también de aplicar cualquier hotfix recomendado para el acceso adecuado a recursos compartidos mediante VNN.

Validar la infraestructura de Always On

El clúster de conmutación por error debe estar configurado y operativo. 

Además, las bases de datos que contendrán FILESTREAM o FileTable deben cumplir con los requisitos para formar parte de un Availability Group.

Configuración de FILESTREAM y FileTable con Always On Availability Groups

Una vez que FILESTREAM está habilitado en todas las instancias, podremos añadir bases de datos que utilicen FILESTREAM a un grupo de disponibilidad. Para hacerlo, no tenemos que hacer nada fuera de lo normal. Simplemente crear un grupo de disponibilidad desde SSMS o mediante el asistente de Always On y asegurarnos de que las bases de datos estén en modo «FULL Recovery Model» y se haya realizado un backup full reciente. De esta manera podremos incluir las bases de datos con FILESTREAM al configurar el grupo de disponibilidad.

Configuración del acceso mediante Nombres de Red Virtual (VNN)

Always On utiliza un VNN para virtualizar el acceso al grupo de disponibilidad. Para acceder a los datos FILESTREAM o FileTable en este contexto.

Tendremos que validar que el recurso compartido de FILESTREAM se haya creado automáticamente para el VNN. Este recurso compartido tendrá la forma típica de un directorio de red pero con el nombre del grupo de disponibilidad en vez de el de uno de los nodos:

\\<NombreVirtualDelGrupo>\mssqlserver

Las aplicaciones que interactúan con FILESTREAM mediante APIs de sistema de archivos deben usar este recurso compartido en lugar del nombre del servidor físico.

Sincronización y replicación de datos

Aunque Always On replica los datos relacionales entre réplicas, los datos almacenados en el sistema de archivos a través de FILESTREAM no se replican automáticamente. Para garantizar consistencia podremos usar herramientas como Distributed File System Replication (DFS-R), que permite sincronizar las carpetas de FILESTREAM entre las réplicas.

Problemas comunes y tips para superarlos

La sincronización de datos no estructurados con FILESTREAM entre nodos puede ser compleja. Como ya hemos mencionado, DFS-R u otras soluciones de replicación similares nos ayudarán a mantener consistencia entre las réplicas. Es imprescindible asegurarse de que las carpetas FILESTREAM estén correctamente sincronizadas en todas las réplicas antes de habilitar un grupo de disponibilidad.

Ten en cuenta que, tras un failover, los datos de FILESTREAM son accesibles tanto en la nueva réplica primaria como en las réplicas secundarias legibles. Sin embargo, una limitación que debemos conocer es que los datos de FileTable solo son accesibles en la réplica primaria

Otra cosa importante, que ya habrás adivinado en puntos anteriores es que las aplicaciones que dependen de rutas de sistema de archivos deben actualizarse para usar las rutas basadas en VNN, evitando dependencias del servidor físico. De este modo, en caso de failover seguirán siendo accesibles

Buenas prácticas para FILESTREAM y FileTable en Always On

Es aconsejable usar DFS-R para sincronizar los datos FILESTREAM entre réplicas y para ello deberemos configurar correctamente las políticas de la aplicación.

Tampoco debemos olvidar adaptar nuestras herramientas para monitorizar el estado de las réplicas para tener bajo control también los recursos compartidos de FILESTREAM.

Y ahora dos cosas que nunca me cansaré de decir. Primero, realizad pruebas periódicas para garantizar que los failovers funcionan y, en este caso, que no interrumpen el acceso a los datos FILESTREAM o FileTable. Y segundo y muy importante, mantened siempre una documentación clara sobre la configuración y validad regularmente los cambios en la infraestructura.

Conclusión

Integrar FILESTREAM y FileTable con Always On Availability Groups es una solución potente para gestionar datos no estructurados con alta disponibilidad. Sin embargo, requiere una configuración cuidadosa y una planificación meticulosa para superar los desafíos inherentes.

Con una configuración adecuada y el uso de herramientas complementarias como DFS-R, las empresas pueden disfrutar de las ventajas de estas tecnologías mientras minimizan los riesgos y los problemas operativos. Para obtener más detalles sobre FILESTREAM, recomendamos consultar nuestro artículo previo sobre FILESTREAM en SQL Server y la documentación oficial de Microsoft.

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 Alta Disponibilidad, SQL Server, 0 comentarios

FileTable en Filestream

La característica FileTable en SQL Server es una extensión que tenemos a nuestro alcance para dar superpoderes a la funcionalidad FILESTREAM. Está diseñada para simplificar el almacenamiento, la administración y el acceso a datos no estructurados en nuestras bases de datos relacionales. Suena bien, ¿verdad? En este artículo, veremos en detalle cómo funciona, sus beneficios, casos de uso y consideraciones para implementarla.

Introducción a FileTable

En resumidas cuentas FileTable combina las capacidades de FILESTREAM con una estructura de tabla especial que permite gestionar datos no estructurados, como documentos o imágenes, directamente desde el sistema de archivos. Lo interesante de esta funcionalidad es que los archivos y carpetas almacenados en una FileTable son accesibles desde aplicaciones tradicionales que usan operaciones de entrada/salida (E/S) en el sistema de archivos, mientras que también se pueden consultar y administrar desde SQL Server.

Esta dualidad ofrece lo mejor de ambos mundos: el rendimiento y las características del sistema de archivos junto con la robustez de SQL Server para consultas y transacciones.

Cómo funciona FileTable

Lo principal que debemos saber es que FileTable está estrechamente relacionado con FILESTREAM. Es más, FileTable se basa en FILESTREAM que, como ya vimos, es una funcionalidad que habilita el almacenamiento de datos binarios en el sistema de archivos en lugar de dentro de las páginas de datos de la base de datos. Cuando habilitamos FileTable el comportamiento cambia y mientras que FILESTREAM por sí solo requiere que las aplicaciones interactúen directamente con SQL Server para leer y escribir los datos binarios, FileTable da un paso más al exponer los datos a través del sistema de archivos, como si fueran carpetas y archivos normales.

Estructura de FileTable

Cuando se crea una FileTable, SQL Server configura una tabla especial que incluye las siguientes columnas adicionales, entre otras:

  • stream_id: un identificador único para cada archivo o carpeta.
  • file_stream: una columna tipo VARBINARY(MAX) que almacena los datos binarios del archivo.
  • name: el nombre del archivo o carpeta.
  • file_type: la extensión del archivo.
  • path_locator: una jerarquía que representa la ubicación del archivo o carpeta dentro de la estructura de directorios.
  • is_directory: indica si el registro representa un archivo o una carpeta.

Estas columnas permiten que FileTable se integre perfectamente tanto en el sistema de archivos como en las operaciones SQL.

Carpetas raíz y Namespace

Cada FileTable tiene una carpeta raíz en el sistema de archivos. Los archivos y carpetas dentro de esta raíz se gestionan automáticamente en sincronización con los registros correspondientes en la base de datos. Esto significa que cualquier cambio realizado en el sistema de archivos, como mover, renombrar o eliminar un archivo, se refleja automáticamente en SQL Server.

Casos de uso de FileTable

Esta característica, como veis, eleva la funcionalidad de FILESTREAM y lo hace ideal para aplicaciones de gestión documental, por ejemplo. En concreto, en sistemas de gestión documental donde es necesario almacenar archivos, como PDFs, imágenes o documentos de Word, FileTable nos habilita acceder a los ficheros tanto desde aplicaciones que utilizan SQL Server como desde exploradores de archivos estándar.

También podemos recurrir a esta característica para una migración de aplicaciones legacy. Es decir, aplicaciones heredadas que gestionan archivos directamente en las carpetas del sistema. En estos casos FileTable permite una transición gradual hacia una solución basada en bases de datos sin necesidad de reescribir el acceso a los archivos.

Podría seguir, por ejemplo es muy interesante  para archivos adjuntos en aplicaciones web o móviles. En estas aplicaciones, los archivos adjuntos cargados por los usuarios pueden almacenarse en una FileTable, ofreciendo una gestión más sencilla de los datos no estructurados con capacidades avanzadas de consulta y seguridad.

Configuración de FileTable en SQL Server

Para utilizar FileTable, es necesario habilitar y configurar varias opciones tanto a nivel de instancia como de base de datos. Veamos los pasos principales.

Antes de crear una FileTable, es necesario habilitar FILESTREAM en el servidor. Esto puede hacerse desde SQL Server Configuration Manager. Después debemos configurar la base de datos para habilitar FILESTREAM. No me detengo más en estos pasos porque ya los vimos cuando hablamos de FILESTREAMUna vez configurado FILESTREAM, podemos crear una FileTable usando un comando SQL. Os pongo un ejemplo:

CREATE TABLE MiFileTable AS FileTable
WITH (
    FileTable_Directory = ‘Documentos’,
    FileTable_Collate_Filename = DATABASE_DEFAULT
);
GO

En este caso, FileTable_Directory define la carpeta raíz donde se almacenarán los archivos.

Beneficios de FileTable

Como vengo mencionando, el principal beneficio de FileTable es el acceso híbrido a los ficheros. FileTable nos permite trabajar con los archivos desde aplicaciones que usan el sistema de archivos o mediante consultas SQL. Derivado de esto, podemos resaltar también la capacidad de tener soporte transaccional. Me refiero a que los cambios en los archivos se pueden incluir en transacciones SQL, garantizando consistencia.

Al ser parte de SQL Server, los archivos se pueden indexar y buscar utilizando capacidades de texto completo lo que también es un gran punto a su favor. 

Por último siempre me gusta destacar el tema de la seguridad integrada. FileTable aprovecha la autenticación y autorización de SQL Server para controlar el acceso a los datos y no solo los permisos sobre la estructura de carpetas.

Limitaciones y consideraciones

Aunque la característica FileTable ofrece muchas ventajas, no está exenta de limitaciones. Por ejemplo, no admite replicación, las FileTables no son compatibles con las tecnologías de replicación tradicionales de SQL Server. Además tiene una gran dependencia del sistema de archivos y ya sabemos que las operaciones intensivas en archivos pueden verse limitadas por el rendimiento del hardware subyacente. 

Otra de las cosas que debemos vigilar muy de cerca es el uso de espacio en disco. Dado que los datos se almacenan en el sistema de archivos, es necesario dimensionar rigurosamente el almacenamiento para evitar problemas de espacio.

Conclusión

FileTable es una funcionalidad poderosa y única de SQL Server que simplifica la gestión de datos no estructurados, al permitir un acceso integrado tanto desde el sistema de archivos como desde consultas SQL. Es especialmente útil en escenarios donde las aplicaciones deben trabajar con archivos directamente, pero también se requiere la capacidad de consulta y gestión avanzada que ofrece SQL Server.

Como siempre, antes de implementar FileTable en un entorno de producción, es fundamental evaluar cuidadosamente los requisitos de la aplicación, las capacidades del sistema y las posibles limitaciones. Si se utiliza correctamente, puede transformar la forma en que gestionamos los datos no estructurados en nuestras bases de datos.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de 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

Reduce el tiempo de tus BACKUPS a la mitad o más

La semana pasada publiqué un post sobre las configuraciones avanzadas de backups BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT y cómo impactan en el rendimiento de nuestras copias de seguridad. A raíz de este artículo, muchos comentasteis una optimización mucho más sencilla y que mejora sustancialmente los tiempos de backup, separar las copias en varios ficheros. Y es cierto, incluso cuando no estás escribiendo estos múltiples ficheros en discos separados puedes ganar tiempo con esta configuración. Pero, ¿por qué? Veámoslo en profundidad. Además veremos otro truco que nos puede ahorrar gran cantidad de tiempo en estos procesos.

¿Por qué optimizar los backups?

A menudo no pensamos en que la optimización de rendimiento sea algo que afecte a las copias de seguridad y sin embargo es un campo donde podemos ganar mucho. 

A ver, un momento, si trabajas con una base de datos pequeña o mediana (hasta 300Gb aprox) y tu empresa solo tiene necesidad de acceso a la base de datos en horas de oficina esto no es un problema, no te compliques más. Seguramente tengas tiempo durante la noche y los fines de semana para hacer todas las tareas de mantenimiento completas sin mucho más miramiento. Pero, a medida que los datos crecen o crecen la demanda de los datos acercándose al tan temido 24×7 te va a tocar hacer malabares con los tiempos de los planes de mantenimiento y ajustarlo todo de manera que impacte lo menos posible en el resto de actividad. 

Vale, en estos casos lo mejor sería una aplicación externa de backup por snapshot para reducir el tiempo a casi 0 pero no seamos tan extremos, veamos qué podemos hacer con herramientas nativas.

Separar los backups en varios ficheros

Incluso cuando escribimos los distintos ficheros de copias de seguridad en el mismo disco duro físico o por la misma interfaz de red suele ser más rápido separar las copias de seguridad en varios ficheros. Esto pasa porque SQL Server tiene “cuellos de botella internos” (limitaciones) en la escritura a ficheros de copias de seguridad y al generar varios vamos a poder salvar en gran medida esas limitaciones. 

Es cierto que a cambio vamos a tener que complicar un poco tanto el script de recuperación de la copia de seguridad como el de la restauración pero, ¿de verdad eso es importante? ¿Sigues escribiendo a mano los scripts de backup y restore en 2025? Amigo para eso existen soluciones como los script de Ola Hallengren o el maravilloso sp_DatabaseRestore de Brent Ozar.

Demostración práctica BACKUPS

Veamos cómo impacta en los tiempos el hecho de dividir las copias de seguridad. Para la prueba estoy usando la base de datos StackOverflow2013 de demo de 52 Gb que tiene 4 ficheros de datos y uno de log. Sobre el hardware de mi máquina de pruebas es una máquina con 8 cores (16 vCores), 32Gb de RAM y un disco SSD M2.Tanto los ficheros de datos como el de log y el backup están en la misma unidad, no es lo ideal pero es lo que tengo para esto.

En un primer intento he hecho un backup full sencillo, a un solo fichero y ha tardado 1:52 minutos, la misma prueba de backup pero con 2 ficheros ha tardado 0:49 minutos y sin embargo, en cuanto he puesto 4 ficheros la prueba se ha ido a 3:42 minutos. ¿Por qué estos resultados? En teoría os había dicho que SQL Server limita la cantidad de datos que escribe a un único fichero por lo que podríamos entender que a más ficheros menos tiempo y sin embargo aunque con 2 ficheros hemos bajado los tiempos con 4 se han disparado.

Esto es porque también tenemos que tener en cuenta las limitaciones de velocidad del disco, en mi caso donde además todos los ficheros de datos y log están en la misma unidad esto cobra más sentido. Durante la prueba con un fichero el uso de disco ha rondado el 30%, durante la segunda prueba entre el 65 y 70% y, en la prueba con 4 ficheros el consumo ha sido del 100% del disco. Por tanto, con 4 ficheros mi hardware ha sobrepasado su límite generando tiempos de espera por cuellos de botella en la E/S de disco.

Demostración práctica RESTORE

Ahora os comparto los resultados que he tenido en la restauración de estas copias que acabo de hacer. Para esta prueba todos los backups siguen en la misma unidad que los datos y los logs y la base de datos existente va a ser sobrescrita, es decir no hay que generar de nuevo los ficheros. ¿Qué pasará?

Aquí los tiempos se disparan, la restauración de la copia con un solo fichero ha tardado 7:18 minutos. La restauración de la copia con dos ficheros, por su parte, ha demorado 11:07. Por último la copia de 4 ficheros ha tomado 10:19 minutos para restaurarse.

Cabe destacar que todas las pruebas de restauración han tenido el uso de disco al 100% en todo momento por lo que no puedo dar por 100% fiables los datos al haber encontrado tán pronto el límite del hardware. Ya os había dicho que la configuración de todo en el mismo disco no es una buena idea.

Bonus extra: Verificar los backups

Otra de las cosas que seguro que estás haciendo es verificar los backups a la hora de hacerlos. Verificar los backups no es que sea una buena práctica es que es imprescindible si queremos estar seguros y cumplir con la normativa vigente para muchas empresas. Como se suele decir, un backup sin probar no es un backup, es como el gato de Schrödinger (claro que he tenido que buscar en google como se escribe). 

Sin embargo, que tengamos que comprobar nuestras copias de seguridad no significa que debamos hacerlo al momento de hacer la copia, ni siquiera significa que debamos hacerlo en el mismo servidor. 

Si nuestros backups están en una unidad de red vamos a poder probarlas de manera independiente y en una máquina distinta al servidor de producción (por ejemplo el servidor de DR o el de pruebas) vamos a poder ganar un 30% o más del total de tiempo de la tarea de copias de seguridad. Incluso, podemos hacer uso del procedimiento sp_DatabaseRestore que he mencionado antes y hacer un CheckDB a la base de datos en este proceso separado de verificación. ¿Te das cuenta de lo que te estoy diciendo, verdad? Más seguridad y mejor rendimiento sin apenas complicarte.

Conclusión

Optimizar los procesos de backups no es solo cuestión de ahorrar tiempo, sino también de garantizar que nuestro entorno sea resiliente, eficiente y cumpla con los estándares de seguridad. A través de ajustes relativamente simples, como dividir los backups en múltiples ficheros o separar la verificación en un proceso independiente, podemos obtener grandes beneficios sin necesidad de recurrir a herramientas externas costosas.

Sin embargo, como hemos visto en las pruebas, no existe una configuración única que funcione para todos los escenarios. Cada entorno tiene sus propias limitaciones, ya sea por el hardware, la arquitectura de los datos o los requisitos operativos. Por eso, es fundamental medir, analizar y ajustar las configuraciones basándonos en pruebas reales. La clave está en encontrar el equilibrio entre el rendimiento y la fiabilidad, adaptando las estrategias a las características de nuestros sistemas.

En resumen, la optimización no siempre implica complejidad, y pequeños cambios pueden marcar una gran diferencia. Ahora te toca a ti: ¿qué ajustes has probado en tus backups? ¿Qué resultados has obtenido? Como siempre, la mejor forma de aprender es compartiendo experiencias.

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

SQL Server Big Data Clusters

Hoy vamos a hablar de una funcionalidad no tan conocida de SQL Server. Esta funcionalidad se estrenó con SQL Server 2019 y realmente no ha tenido la adopción del mercado deseada. Quizá porque al poco tiempo le surgió un enemigo dentro de su propia casa, Microsoft Fabric. Pero bueno, no es mi objetivo hacer análisis de mercado, simplemente vamos a descubrir hoy SQL Server Big Data Clusters (BDC). 

SQL Server Big Data Clusters es una solución avanzada para gestionar, analizar y transformar grandes volúmenes de datos integrando el potencial de SQL Server con tecnologías de Big Data como Apache Spark y Hadoop Distributed File System (HDFS). Como os decía, en este artículo, profundizaremos en qué consiste esta tecnología, sus componentes clave y cómo se implementa en entornos empresariales modernos.

¿Qué es SQL Server Big Data Clusters?

Empecemos por el principio, SQL Server Big Data Clusters es una implementación de contenedores que permite desplegar un clúster escalable de SQL Server, Spark y HDFS utilizando Kubernetes como orquestador. La solución está diseñada para trabajar con datos estructurados, no estructurados y semiestructurados, facilitando tanto la consulta como el procesamiento distribuido.

Esta plataforma no solo facilita la consulta sobre grandes volúmenes de datos, sino que también permite integrar fuentes de datos externas y realizar análisis avanzados directamente desde SQL Server.

Componentes Clave de SQL Server Big Data Clusters

Ahora que ya sabemos lo que es, veamos de qué se compone y que debemos tener en cuenta. 

  • Control Plane: El componente principal que debemos conocer es el Control Plane. Es el núcleo del clúster que administra la infraestructura y orquesta las operaciones entre los diferentes servicios. Kubernetes actúa como el motor principal para gestionar el despliegue de los recursos.
  • SQL Server Master Instance: SQL Server Master Instance es la instancia principal de SQL Server en el clúster que actúa como punto de entrada para las consultas y la administración de datos. Desde aquí se pueden realizar operaciones T-SQL estándar, así como consultas externas.
  • Data Pool: El Data Pool es el componente que almacena y gestiona los datos estructurados que se cargan directamente en el clúster para procesamiento intensivo. Es ideal para cargas de trabajo analíticas donde los datos se distribuyen y procesan en paralelo.
  • Storage Pool: El Storage Pool es la integración de Hadoop Distributed File System (HDFS) y se usa para manejar datos no estructurados. Este almacenamiento es distribuido y permite el escalado horizontal para manejar grandes volúmenes de datos.
  • Compute Pool: El componente Compute Pool es el grupo diseñado para manejar consultas distribuídas sobre grandes datasets. A grandes rasgos, lo que hace es ejecutar SQL Server en contenedores con funcionalidades de consulta paralela.
  • Spark Pool: El Spark Pool, como su propio nombre indica es el componente de Apache Spark que proporciona capacidades de procesamiento de datos. Nos sirve para optimizar tareas de Machine Learning, ETL y análisis en tiempo real.Application Services: Por último, los Application Services nos facilitan el desarrollo y despliegue de aplicaciones personalizadas dentro del clúster, incluyendo APIs, paneles analíticos y aplicaciones de Machine Learning.

Beneficios Principales de SQL Server Big Data Clusters

Lo más destacable de esta solución es su escalabilidad y flexibilidad. Al estar basado en Kubernetes, se pueden escalar los recursos del clúster según las necesidades de la carga de trabajo, optimizando tanto el costo como el rendimiento.

Además, el procesamiento de datos distribuido es otra de sus grandes ventajas. Gracias a HDFS y Spark, los BDC permiten procesar grandes volúmenes de datos de manera distribuida, reduciendo significativamente los tiempos de procesamiento.

Por si esto fuese poco, tenemos también su gran capacidad de integración de fuentes de datos externas. SQL Server BDC soporta PolyBase, permitiendo la consulta y análisis de datos almacenados en plataformas como Azure Data Lake, Amazon S3, y otros sistemas externos, directamente desde SQL Server.

Como veis, tenemos a nuestro alcance todo un ecosistema analítico completo que incluye capacidades analíticas avanzadas, como análisis en tiempo real, integración con herramientas de Machine Learning y capacidades ETL robustas.

Casos de Uso

SQL Server Big Data Clusters, gracias a sus capacidades para el análisis de datos masivos, es ideal para organizaciones que manejan grandes cantidades de datos estructurados y no estructurados. Estas organizaciones pueden beneficiarse de la capacidad de consulta distribuida y almacenamiento escalable de los BDC.

Además su integración multifuente hace que empresas con datos distribuidos en múltiples plataformas pueden usar BDC para consolidar y analizar datos sin necesidad de migrarlos.

Otro de los casos de uso de rabiosa actualidad es para escenarios de Machine Learning e Inteligencia Artificial. Con Spark integrado, los BDC son ideales para implementar modelos de Machine Learning en entornos de Big Data. Pero no hace falta apuntar tan alto, la combinación de Spark y SQL Server facilita la transformación de datos y su preparación para análisis haciendo accesibles los procesos ETL más complejos.

Implementación de SQL Server Big Data Clusters

Como hemos visto, la instalación de SQL Server BDC requiere un entorno Kubernetes configurado. A continuación, os resumo los pasos básicos:

  1. Preparar el Entorno Kubernetes: Lo primero que deberemos hacer es configurar un clúster de Kubernetes compatible con SQL Server BDC, como AKS, OpenShift o cualquier distribución Kubernetes certificada.
  2. Configurar el Almacenamiento: Una vez el entorno de Kubernetes está configurado deberemos seleccionar el almacenamiento persistente para HDFS y otros componentes del clúster.
  3. Desplegar el Clúster: En este punto ya estamos en disposición de usar herramientas como Azure Data CLI (azdata) para desplegar los contenedores de SQL Server BDC en el clúster Kubernetes.
  4. Configurar el Acceso: Por último, no debemos olvidarnos de implementar reglas de acceso seguro y configurar el acceso a las fuentes de datos externas.

¿Qué pasa ahora que ha llegado Fabric?

SQL Server BDC fue concebido como una solución para gestionar datos estructurados y no estructurados en entornos híbridos y locales, utilizando Kubernetes como orquestador. Sin embargo, Fabric ha superado a BDC en varias áreas críticas.

Mientras que BDC ofrece escalabilidad mediante Kubernetes, Fabric utiliza una arquitectura nativa en la nube, permitiendo una expansión horizontal más ágil y transparente. Esto simplifica la gestión de recursos y permite un enfoque más integral hacia el análisis en tiempo real. Fabric también centraliza las herramientas de análisis, desde la ingestión de datos hasta su visualización, lo que elimina la necesidad de múltiples tecnologías y reduce la complejidad operativa. Por el contrario, BDC requiere una integración manual de componentes como PolyBase y HDFS, aumentando la carga administrativa. A todo esto hay que sumar que, en Fabric, al incorporar servicios completamente gestionados, se reduce drásticamente la necesidad de conocimientos especializados para administrar clústeres, facilitando la adopción incluso para equipos con menos experiencia en Kubernetes.

Mientras que Fabric brilla en escenarios modernos como análisis avanzado, gobernanza centralizada y machine learning, BDC sigue siendo relevante únicamente para organizaciones con fuertes inversiones en infraestructura híbrida local que requieren una compatibilidad estrecha con SQL Server. 

Debemos tener en cuenta que aunque Microsoft no ha declarado explícitamente el final del soporte para BDC, su desarrollo está estancado en favor de Fabric. Esto posiciona a BDC como una tecnología de nicho, útil en entornos muy específicos o en organizaciones que todavía no pueden migrar completamente a la nube.

Conclusión

SQL Server Big Data Clusters representó un avance significativo en su tiempo, combinando SQL Server con tecnologías de Big Data para abordar desafíos complejos de gestión de datos. Sin embargo, la llegada de Microsoft Fabric ha redefinido este espacio, ofreciendo una solución más moderna, integrada y eficiente para la mayoría de los casos de uso actuales.

Si bien BDC sigue siendo útil en ciertos contextos específicos, Microsoft Fabric es claramente el futuro de la analítica de datos en el ecosistema de Microsoft. Para maximizar el valor y mantenerse alineados con el roadmap tecnológico, las organizaciones deben considerar una transición estratégica hacia Fabric. Este cambio no solo optimiza la infraestructura, sino que también abre nuevas oportunidades para aprovechar al máximo los datos en un entorno dinámico y escalable. Fabric no es simplemente una evolución; es una revolución en la forma en que entendemos y utilizamos los datos.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en SQL Server, 1 comentario