Infra

¿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

Memory Clerks en SQL Server

La memoria es uno de los recursos más importantes en SQL Server. En cualquier entorno de bases de datos, la gestión adecuada de la RAM tiene un impacto directo en el rendimiento, por lo que entender cómo SQL Server distribuye y utiliza la memoria es esencial para optimizar el rendimiento. Una de las herramientas más potentes para analizar el uso de la memoria en SQL Server son los Memory Clerks, estructuras que el motor de base de datos utiliza para clasificar y medir el consumo de memoria en distintas áreas.

En este artículo, explicaré qué son los memory clerks, cómo trabajan y qué podemos aprender de ellos para optimizar la memoria en nuestras instalaciones de SQL Server. A medida que profundizamos en el tema, entenderemos mejor cómo estos componentes nos permiten a los administradores diagnosticar problemas relacionados con la memoria y ajustar las configuraciones para maximizar el rendimiento. O eso espero 🙂

¿Qué son los Memory Clerks?

Los Memory Clerks en SQL Server son componentes encargados de controlar y rastrear el uso de la memoria en diferentes subsistemas del servidor. SQL Server utiliza estos «clerks» o «registradores» de memoria para identificar qué tipo de carga de trabajo o función está consumiendo la RAM y cuánto consume en cada momento. Cada memory clerk agrupa los recursos consumidos en una parte específica del servidor, lo que nos permite hacer un análisis detallado y entender en qué áreas está impactando más el uso de la memoria.

Los clerks no solo controlan el uso de la memoria dinámica, sino también la memoria fija y los buffers que SQL Server utiliza para las diversas operaciones internas. Al proporcionar una visión clara del consumo de memoria, los memory clerks son esenciales para el diagnóstico de problemas de rendimiento y cuellos de botella.

¿Cómo trabajan los Memory Clerks?

Cada vez que una parte de SQL Server requiere memoria, ya sea para una operación de consulta, la compilación de un plan de ejecución o el mantenimiento de índices, el sistema asigna dicha memoria a un clerk específico. Esto asegura que cada subsistema tenga control sobre su propia porción de memoria y pueda gestionar la demanda de recursos de manera adecuada.

Existen diferentes tipos de memory clerks, cada uno de ellos responsable de una parte particular del sistema. Algunos de los clerks más importantes son:

  • CACHESTORE_SQLCP: Encargado de gestionar la memoria utilizada para almacenar planes de ejecución de consultas en caché. Este clerk es clave para optimizar el rendimiento en consultas repetidas.
  • CACHESTORE_OBJCP: Similar al anterior, pero enfocado en el almacenamiento en caché de objetos compilados, como procedimientos almacenados y funciones definidas por el usuario.
  • USERSTORE_SCHEMAMGR: Maneja la memoria utilizada para almacenar metadatos del esquema de las bases de datos.
  • MEMORYCLERK_SQLBUFFERPOOL: Uno de los más importantes, ya que gestiona el Buffer Pool, la zona de memoria donde se almacenan las páginas de datos leídas desde el disco.

Cada uno de estos memory clerks actúa como un “departamento” dentro del servidor que controla cuánta memoria utiliza su sección específica, asegurando que no se consuman recursos de manera desproporcionada y permitiendo una gestión más eficiente de los recursos en general.

Tipos principales de Memory Clerks

Aunque existen muchos tipos de memory clerks en SQL Server (y cada versión nueva más), algunos son especialmente relevantes para la gestión de la memoria. Los más importantes en un entorno típico de bases de datos son los siguientes:

  • MEMORYCLERK_SQLBUFFERPOOL: Como hemos mencionado antes, este clerk es responsable del Buffer Pool. Se encarga de gestionar las páginas de datos que están almacenadas en la memoria RAM y que son esenciales para el rendimiento de las consultas. Su buen funcionamiento es crítico, ya que cualquier problema en este clerk puede derivar en un mayor número de lecturas desde disco, lo que ralentiza considerablemente las operaciones.
  • MEMORYCLERK_SQLSTORENG: Este clerk gestiona la memoria relacionada con el almacenamiento de datos y el motor de almacenamiento. Aquí es donde SQL Server maneja las estructuras de datos de los archivos físicos de las bases de datos.
  • MEMORYCLERK_SQLCLR: Responsable de la memoria utilizada por el Common Language Runtime (CLR) de SQL Server. Si ejecutamos código .NET dentro de SQL Server, como procedimientos almacenados CLR o funciones definidas por el usuario, este clerk gestionará la memoria asignada.
  • MEMORYCLERK_SQLQUERYEXEC: Este clerk gestiona la memoria utilizada para la ejecución de consultas. Se ocupa de los recursos necesarios para ejecutar y optimizar las consultas, incluyendo el almacenamiento temporal de los resultados intermedios.
  • MEMORYCLERK_SQLGENERAL: Este clerk se encarga de la memoria utilizada para operaciones generales que no están categorizadas bajo otros clerks específicos. Incluye operaciones diversas del sistema.

Monitorización

Monitorizar el uso de los memory clerks nos proporciona información valiosa sobre cómo se está distribuyendo la memoria en nuestro servidor. SQL Server ofrece varias formas de acceder a esta información, mi favorita es la vista de gestión dinámica (DMV) sys.dm_os_memory_clerks. Esta vista nos permite ver cuánta memoria está utilizando cada memory clerk en tiempo real, lo que nos ofrece un nivel de detalle profundo para diagnosticar problemas de rendimiento. Un ejemplo de consulta que podemos ejecutar para obtener una visión clara del consumo de memoria por parte de los memory clerks es la siguiente:

Esta consulta nos muestra el tipo de memory clerk y la cantidad de memoria que cada uno está utilizando, ordenados de mayor a menor consumo de memoria. De esta manera, podemos identificar rápidamente qué área del sistema está consumiendo más recursos y si hay algún subsistema que esté utilizando más memoria de la esperada.

Además de esta DMV, SQL Server proporciona otras vistas de gestión como sys.dm_os_sys_memory y sys.dm_os_process_memory, que nos permiten analizar el estado general de la memoria del sistema y la memoria utilizada por el proceso de SQL Server.

Diagnóstico de problemas de rendimiento con Memory Clerks

Cuando un servidor presenta problemas de rendimiento relacionados con la memoria, los memory clerks son una de las primeras áreas que me gusta analizar. Un uso desproporcionado de memoria en algún clerk puede ser un indicativo claro de que algo no está funcionando correctamente. Por ejemplo, si el CACHESTORE_SQLCP está consumiendo una cantidad anormal de memoria, podría significar que el sistema está almacenando demasiados planes de ejecución en caché, lo que podría requerir ajustes en los parámetros de configuración del Plan Cache.

Por otro lado, si el MEMORYCLERK_SQLBUFFERPOOL está saturado, probablemente estemos ante un escenario en el que el sistema está lidiando con demasiadas páginas de datos y no hay suficiente memoria para almacenarlas. En este caso, aumentar la memoria física o implementar la Buffer Pool Extension podría ser una solución viable.

El análisis continuo de los memory clerks nos proporciona las herramientas necesarias para realizar ajustes proactivos y optimizar la configuración del servidor, mejorando así el rendimiento general.

Conclusión

Los Memory Clerks son una de las claves para entender cómo SQL Server gestiona la memoria y optimizar el rendimiento en entornos de bases de datos. Estos componentes permiten una visión detallada del uso de memoria en distintas áreas del sistema, lo que resulta esencial para diagnosticar problemas de rendimiento y ajustar la configuración del servidor de manera efectiva.

Al comprender cómo funcionan los memory clerks y monitorizar su uso de manera regular, los administradores de bases de datos podemos asegurarnos de que SQL Server está utilizando la memoria de forma óptima. Esto nos permite resolver problemas relacionados con el consumo de memoria antes de que afecten gravemente al rendimiento del sistema y garantizar que nuestros entornos de bases de datos operen con la máxima eficiencia posible.

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

Buffer Pool Extension

En nuestras instalaciones de SQL Server, la gestión eficiente de los recursos es uno de los factores clave para obtener un rendimiento óptimo. Sobre este tema, sabemos que el subsistema de memoria juega un papel crucial al permitir que SQL Server procese consultas y acceda a los datos de la forma más rápida posible. En concreto el Buffer Pool, que almacena páginas de datos en memoria para evitar accesos frecuentes al disco, es una de las estructuras más importantes en este aspecto. Sin embargo, cuando la cantidad de datos que estamos manejando supera la capacidad de la memoria física disponible, es cuando entra en juego una funcionalidad que muchos conocen, pero no siempre aprovechan al máximo: el Buffer Pool Extension (BPE).

¿Qué es el Buffer Pool?

Aunque ya hablamos de esto en profundidad en el artículo sobre el uso de la RAM, el Buffer Pool en SQL Server es donde se cargan las páginas de datos desde disco para ser procesadas por el motor de base de datos. Si la base de datos que estamos gestionando es lo suficientemente pequeña como para caber completamente en memoria, el rendimiento será óptimo porque las operaciones de lectura y escritura ocurren en la memoria, que es significativamente más rápida que el almacenamiento en disco. Sin embargo, cuando el tamaño de la base de datos excede la memoria disponible, SQL Server comienza a intercambiar páginas entre la memoria y el disco, lo que genera un impacto en el rendimiento.

¿Qué es exactamente el Buffer Pool Extension?

Aquí es donde el Buffer Pool Extension entra en juego. SQL Server puede utilizar una unidad SSD configurada como extensión de la memoria. Este mecanismo permite que las páginas de datos menos utilizadas se almacenen temporalmente en la SSD en lugar de ser expulsadas completamente del Buffer Pool, lo que reduce significativamente la latencia en comparación con el almacenamiento tradicional en disco mecánico.

Pero, empecemos por el principio, el Buffer Pool Extension es una característica introducida en la versión 2014 en las ediciones Standard y Enterprise de SQL Server que nos permite extender la memoria física utilizando almacenamiento en disco de estado sólido (SSD). Aunque a primera vista podría parecer que añadir más memoria física sería una mejor solución, el Buffer Pool Extension ofrece una alternativa interesante, especialmente cuando los costes de expansión de memoria RAM son prohibitivos. A lo largo de este artículo exploraremos cómo funciona esta extensión, cuándo es útil y cómo configurarla para sacar el máximo partido a nuestros sistemas SQL Server.

Aunque no sustituye a la memoria física, el Buffer Pool Extension es una solución que puede proporcionar una mejora sustancial en rendimiento cuando las bases de datos no pueden ser completamente almacenadas en la memoria RAM. Es importante tener en cuenta que las SSD utilizadas para el Buffer Pool Extension deben ser de alta calidad, ya que su durabilidad y velocidad de acceso son factores críticos para el éxito de esta estrategia.

Ventajas y desventajas del uso de Buffer Pool Extension

La principal ventaja del Buffer Pool Extension es que permite mejorar el rendimiento de SQL Server en escenarios donde el acceso a la memoria es un cuello de botella. Al utilizar almacenamiento en SSD para extender el Buffer Pool, SQL Server puede mantener más datos «cerca» del procesador, reduciendo la necesidad de acceder a discos más lentos.

Sin embargo, esta funcionalidad también presenta algunas limitaciones. El Buffer Pool Extension no es una solución mágica que elimine la necesidad de tener suficiente memoria RAM. Sigue siendo fundamental que tengamos una cantidad adecuada de memoria física disponible, ya que el Buffer Pool Extension solo es efectivo para gestionar picos de carga o situaciones donde la demanda de memoria excede temporalmente la capacidad instalada. Además, las unidades SSD, aunque rápidas, no tienen la misma velocidad que la RAM, por lo que su uso implica una pequeña penalización en el rendimiento en comparación con la memoria física.

Otro punto muy importante a considerar es el desgaste de las unidades SSD. Este tipo de almacenamiento, aunque eficiente, tiene un número limitado de ciclos de escritura, lo que puede provocar su deterioro con el tiempo, especialmente en sistemas que generan una alta cantidad de escrituras en el Buffer Pool. Es por ello que, si bien los SSD pueden mejorar el rendimiento, debemos monitorizar cuidadosamente su uso para evitar sorpresas desagradables en cuanto a su durabilidad.

Casos de uso para el Buffer Pool Extension

El Buffer Pool Extension es particularmente útil en escenarios donde la base de datos es mucho más grande que la memoria disponible y además no podemos incrementar la RAM fácilmente debido a restricciones presupuestarias o técnicas. Un ejemplo típico es cuando gestionamos bases de datos que contienen grandes volúmenes de datos históricos que no se consultan con frecuencia. En este tipo de situaciones, las páginas menos accedidas pueden ser almacenadas en el Buffer Pool Extension, dejando el espacio en memoria para los datos que son más críticos para las consultas activas.

Otro escenario en el que el Buffer Pool Extension puede resultarnos muy útil es cuando trabajamos con aplicaciones con picos de carga impredecibles. En lugar de dimensionar un sistema con más RAM de la que se necesitaría el 90% del tiempo, podemos dimensionarlo adecuadamente y permitir que el Buffer Pool Extension absorba los picos temporales de demanda de memoria.

No obstante, el Buffer Pool Extension no es adecuado para todas las situaciones. Si nuestra base de datos está en constante cambio y todo el conjunto de datos es consultado de manera uniforme, es probable que el Buffer Pool Extension no aporte beneficios significativos. En estos casos el intercambio entre memoria y SSD será constante, y no veremos mejoras notables en el rendimiento. Por no hablar además delriesgo de “romper” el disco SSD antes de tiempo.

Configuración y buenas prácticas

Configurar el Buffer Pool Extension en SQL Server es un proceso relativamente sencillo, pero debemos seguir algunas buenas prácticas para asegurarnos de que funcione correctamente. La primera recomendación es seleccionar un dispositivo SSD de alta calidad, con una baja latencia y alta durabilidad. Es preferible utilizar SSD dedicadas exclusivamente para el Buffer Pool Extension en lugar de compartir el mismo almacenamiento con otras cargas de trabajo. Compartir disco podría impactar en el rendimiento de ambas funciones y, en caso de degradación del disco, afectar a otros datos.

Una vez seleccionada la unidad adecuada, la configuración del Buffer Pool Extension se realiza a través de T-SQL, utilizando el comando ALTER SERVER CONFIGURATION. Es importante asegurarse de que el tamaño asignado al Buffer Pool Extension sea suficiente para cubrir las necesidades de las cargas de trabajo más intensivas, pero sin exceder el tamaño total del almacenamiento SSD disponible. La clave es encontrar un equilibrio que permita optimizar el uso de la unidad SSD sin sobrecargarla ni saturarla de datos que, en realidad, deberían estar en la memoria RAM.

Es recomendable monitorizar el uso del Buffer Pool Extension mediante las vistas de gestión dinámica (DMVs), como sys.dm_os_buffer_descriptors, para comprobar que las páginas almacenadas en la extensión realmente están siendo aprovechadas. Además, debemos estar atentos a los posibles problemas de rendimiento en el SSD y estar preparados para ajustar la configuración en caso de que notemos que la extensión no está ofreciendo las mejoras esperadas.

Conclusión

El Buffer Pool Extension de SQL Server es una herramienta valiosa para mejorar el rendimiento en sistemas con restricciones de memoria física, especialmente cuando se dispone de almacenamiento en SSD de alta calidad. Aunque no sustituye a la RAM, ofrece una solución intermedia eficaz en situaciones donde aumentar la memoria física no es viable. Sin embargo, debemos ser cuidadosos al implementarlo, asegurándonos de que nuestras aplicaciones realmente se beneficien de su uso y evitando su abuso en sistemas donde podría generar más desgaste que beneficios.

En definitiva, la clave para sacar el máximo partido del Buffer Pool Extension es entender las características de nuestras cargas de trabajo y aplicar esta funcionalidad solo cuando sea necesario. Con una correcta planificación y configuración, el Buffer Pool Extension puede marcar una gran diferencia en el rendimiento de nuestros sistemas 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, 0 comentarios

¿Cómo usa SQL la RAM?

La memoria RAM es uno de los recursos más críticos para cualquier sistema informático, ya que impacta directamente en el rendimiento. En SQL Server también es un tema clave ya que afecta a cómo de rápido se van a completar las operaciones de consulta y escritura. Aunque a menudo nos enfocamos en cómo SQL Server utiliza la RAM para cargar y procesar las páginas de datos, la realidad es que hay muchos otros elementos que también consumen memoria. En este artículo, profundizaremos en cómo SQL Server gestiona la memoria RAM.

Uso general de la memoria RAM en SQL Server

SQL Server utiliza la memoria RAM para una amplia variedad de funciones operativas, no sólo para las páginas de datos. La RAM se reparte entre tareas que van desde la gestión de conexiones y sesiones hasta el procesamiento de consultas y la ejecución de procedimientos almacenados. Cada vez que un usuario se conecta a SQL Server, se asigna una porción de memoria para gestionar la sesión y almacenar detalles sobre los planes de ejecución de las consultas.

Además, las operaciones de consulta más complejas, como las ordenaciones, agrupaciones y uniones, requieren memoria temporal para gestionar los datos durante el proceso. Esto significa que, incluso en escenarios donde el acceso a los datos no es intensivo, SQL Server utiliza la RAM para agilizar las operaciones que no necesariamente dependen de las páginas de datos.

Otro gran consumidor de memoria es el caché de planes de ejecución, también conocido como Plan Cache. Este área almacena los planes de ejecución de consultas reutilizables, lo que mejora el rendimiento al evitar la recompilación constante de planes consultas similares.

Si bien estas áreas son importantes, el mayor consumidor de memoria dentro de SQL Server es, sin duda, el Buffer Pool.

El Buffer Pool de la RAM

El Buffer Pool es el área de la memoria en la que SQL Server carga las páginas de datos desde los discos. Estas páginas tienen un tamaño estándar de 8 KB y contienen los datos que las consultas necesitan para ejecutarse. Siempre que una consulta requiere acceder a una tabla, SQL Server primero intenta cargar la página correspondiente en el Buffer Pool. Si la página ya está en memoria, el motor puede procesarla rápidamente. Si no está, se debe leer del disco, lo que es significativamente más lento.

En el mejor de los casos, el Buffer Pool es lo suficientemente grande como para almacenar todas las páginas de datos activas. Sin embargo, esto es un ideal y lo normal es encontrarnos con bases de datos que exceden la capacidad de la memoria física disponible. En estos casos, SQL Server debe gestionar el intercambio de páginas entre el Buffer Pool y el almacenamiento en disco. El motor utiliza un algoritmo de reemplazo de páginas conocido como LRU (Least Recently Used), que expulsa las páginas menos utilizadas de la memoria para hacer espacio a nuevas páginas que necesitan ser cargadas.

Este proceso es crítico para el rendimiento general del sistema, ya que el acceso a datos almacenados en disco es mucho más lento que el acceso a datos en memoria. Cuantas más páginas de datos puedan permanecer en el Buffer Pool, más rápido será el rendimiento del servidor. Ten en cuenta que el motor de SQL Server jamás va a leer datos del disco directamente, siempre carga en memoria las páginas de datos necesarias y luego accede a los datos contenidos en ellas. Para los procesos de escritura, en resumidas cuentas, es lo mismo: se carga la página en memoria, se modifica lo que sea necesario y después se vuelca al disco.

Otras áreas de uso de la memoria RAM en SQL Server

Además del Buffer Pool, SQL Server utiliza la RAM para una variedad de funciones adicionales, todas ellas orientadas a mejorar el rendimiento del sistema:

Como ya hemos visto antes, la caché de planes de consulta es una de las áreas más importantes fuera del Buffer Pool. Aquí se almacenan los planes de ejecución de las consultas para evitar tener que recompilar consultas idénticas. La caché de planes mejora significativamente el rendimiento de consultas recurrentes al permitir que el servidor reutilice los planes de ejecución almacenados.

También hemos visto que otro de los procesos en los que SQL Server emplea la memoria RAM es en las operaciones internas como ordenaciones y uniones requieren memoria adicional para gestionar los datos intermedios antes de que los resultados finales puedan ser escritos o enviados al cliente. SQL Server asigna memoria temporal para estas operaciones, que luego es liberada una vez que se completan.Además, es probable que el uso de RAM sea mayor al volumen de los datos por lo que hay que tener cuidado con este tipo de operaciones.

Otra funcionalidad que consume gran cantidad de memoria son las operaciones In-Memory OLTP. Esta característica permite que ciertas tablas se mantengan completamente en memoria, lo que acelera enormemente las transacciones de alta concurrencia. Sin embargo, este enfoque consume una cantidad significativa de RAM.

En resumen, SQL Server no solo utiliza la memoria para las páginas de datos, sino que gestiona dinámicamente la memoria entre varias áreas clave para maximizar el rendimiento del sistema. El reto que tenemos los DBAs es equilibrar estas áreas de uso para garantizar que el Buffer Pool tenga suficiente espacio para almacenar las páginas de datos más utilizadas sin comprometer otras operaciones importantes del sistema. Sin embargo, el reto es que no podemos actuar sobre este reparto, al menos directamente. 

Mecanismos de ajuste dinámico de memoria RAM

Como acabamos de ver, no podemos actuar sobre como SQL Server gestiona la memoria. El motor de base de datos cuenta con mecanismos internos para gestionar y ajustar el uso de la memoria de manera dinámica. Esto es crucial en entornos donde la demanda de memoria puede fluctuar con frecuencia debido a cambios en las cargas de trabajo o la actividad de usuarios externos. Uno de los mecanismos más importantes es el ajuste dinámico de memoria, que permite a SQL Server ajustar automáticamente la cantidad de RAM que utiliza dentro de los límites establecidos en la configuración del servidor.

Cuando otros procesos en el sistema operativo necesitan memoria, SQL Server puede liberar parte de su memoria para evitar sobrecargar el sistema. A este proceso se le conoce como «presión de memoria externa». Aunque SQL Server es bastante eficiente en este ajuste, es importante para nosotros monitorizar el uso de la memoria para asegurarnos de que el servidor no esté liberando demasiada memoria en detrimento del rendimiento. Esto podemos asegurarlo configurando un mínimo de RAM para la instancia.

En situaciones donde la memoria es insuficiente, SQL Server también puede aplicar «esperas de memoria», lo que significa que las consultas se ponen en cola hasta que haya suficiente memoria disponible para su ejecución. Este escenario puede generar cuellos de botella en el rendimiento si no se gestiona adecuadamente, por lo que es fundamental tener configurados límites de memoria adecuados y suficientes recursos físicos disponibles.

Optimización de la gestión de memoria en SQL Server

Para optimizar el uso de la memoria RAM en SQL Server, ya que no podemos actuar sobre la gestión interna de la memoria, es vital que comprendamos cómo maneja nuestro sistema las cargas de trabajo. Si nuestras bases de datos están activamente consultadas y el tamaño de los datos excede la capacidad de la memoria física, priorizar el uso del Buffer Pool es fundamental. Aquí es donde técnicas como la extensión de memoria mediante Buffer Pool Extension pueden ser útiles, pero siempre como complemento a una buena planificación de memoria RAM física.

Un punto importante es mantener un equilibrio adecuado entre las diferentes áreas que consumen memoria en SQL Server. No podemos permitir que áreas como el Plan Cache o la memoria para operaciones internas consuman una cantidad excesiva de memoria a expensas del Buffer Pool. Si bien SQL Server ajusta la memoria de forma dinámica, un buen DBA debe estar atento a las señales de advertencia, como esperas prolongadas de memoria o un uso excesivo de intercambio de páginas.

Conclusión

La gestión eficiente de la memoria en SQL Server es clave para garantizar un rendimiento óptimo, especialmente en sistemas con grandes volúmenes de datos. Comprender cómo SQL Server utiliza la RAM y ajustar la configuración en función de las necesidades de cada implementación es el primer paso para asegurar un equilibrio entre el uso de la memoria y la eficiencia 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, 1 comentario

Particionado en ReFS vs NTFS para SQL Server

Hace unos días surgió en nuestra comunidad de telegram un debate interesante sobre cual es el mejor particionamiento para SQL Server si NTFS o ReFS. Lo cierto es que al gestionar bases de datos SQL Server, la elección del sistema de archivos adecuado puede tener un impacto significativo en el rendimiento y la fiabilidad. Tradicionalmente, NTFS ha sido la opción por defecto en sistemas Windows, pero la llegada de ReFS (allá por 2012) ha planteado una alternativa interesante. En este artículo, voy a tratar de analizar las diferencias entre ReFS y NTFS para SQL Server, evaluando sus implicaciones en términos de rendimiento, integridad de datos y consumo de recursos.

NTFS: Un sistema probado y compatible

NTFS es el sistema de archivos más utilizado en Windows Server desde hace décadas. Ofrece estabilidad y un amplio soporte para características como la compresión de archivos, encriptación y la gestión eficiente de grandes volúmenes de datos. En el contexto de SQL Server, NTFS ha demostrado ser un sistema fiable y compatible, especialmente en entornos de producción donde se utilizan herramientas y utilidades estándar para la administración de discos y almacenamiento.

A nivel de rendimiento, NTFS puede enfrentar problemas cuando se manejan grandes volúmenes de datos o cuando las operaciones de entrada/salida (E/S) son intensivas. Su estructura jerárquica y los metadatos asociados pueden llegar a ser un cuello de botella en consultas complejas o bases de datos con altas transacciones. Además, NTFS es susceptible a la fragmentación de archivos, un problema que afecta al rendimiento a medida que las bases de datos crecen y se modifican. La desfragmentación, aunque útil, requiere tiempo y recursos adicionales.

ReFS: Ventajas y limitaciones para SQL Server

ReFS (Resilient File System) fue introducido por Microsoft como una alternativa más robusta a NTFS, con la promesa de mejorar la resiliencia ante la corrupción de datos y ofrecer un mejor rendimiento en operaciones de E/S intensivas. En teoría, ReFS presenta varias ventajas sobre NTFS, como la reducción de la fragmentación y una mayor tolerancia a errores, lo que lo convierte en una opción atractiva para gestionar volúmenes de datos grandes y sistemas de almacenamiento avanzado, como Storage Spaces.

Uno de los puntos fuertes de ReFS es su capacidad para gestionar grandes volúmenes de datos y evitar la fragmentación, algo que puede beneficiar significativamente a las bases de datos SQL Server que requieren muchas operaciones de lectura y escritura. Sin embargo, cuando hablamos de bases de datos, no es recomendable aprovechar la característica de integridad de datos automática de ReFS, ya que Microsoft sugiere desactivarla en estos entornos. El motivo es que SQL Server ya gestiona su propia integridad de datos mediante transacciones ACID y checksums, y permitir que ReFS realice correcciones automáticas podría interferir con estos mecanismos. Por tanto, la función de integridad de ReFS, que es una de sus principales fortalezas, no debe utilizarse en bases de datos SQL Server, limitando su aplicación en estos escenarios.

Consumo de recursos en ReFS

Otra consideración importante al usar ReFS es su mayor consumo de recursos en comparación con NTFS. Debido a las funcionalidades avanzadas de corrección de errores y gestión de volúmenes, ReFS tiende a utilizar más CPU y memoria. En entornos de bases de datos con cargas de trabajo intensivas, como es común en SQL Server, este mayor consumo puede reducir el rendimiento general del sistema, especialmente en servidores que ya están bajo una alta carga de procesamiento.

Si bien ReFS ofrece una mejor gestión de volúmenes grandes, debemos sopesar si el mayor uso de recursos del sistema compensa las mejoras en la resistencia y la fragmentación. En muchos casos, NTFS sigue siendo más eficiente, especialmente en servidores donde el hardware no es de última generación o donde el coste de la memoria y CPU es una preocupación.

¿Afecta a SQL Server la deduplicación de datos de ReFS?

La deduplicación de datos es una técnica de almacenamiento que consiste en identificar y eliminar bloques de datos duplicados para reducir el espacio necesario. En lugar de almacenar múltiples copias de la misma información, la deduplicación guarda una única versión de los bloques repetidos y crea referencias a estos desde otros archivos o ubicaciones.

En cuanto a la deduplicación de datos para SQL Server, es importante aclarar que SQL Server no se beneficia directamente de esta funcionalidad. Esto es porque las bases de datos de SQL almacenan información en bloques (páginas) con identificadores únicos, lo que implica que no hay bloques redundantes que puedan ser eliminados sin afectar la integridad de los datos. Por tanto, la deduplicación no se aplica a los archivos de bases de datos.

Sin embargo, es posible que en algunos escenarios se intente utilizar la deduplicación de ReFS para las copias de seguridad de bases de datos. En este contexto, la deduplicación podría ser útil para reducir el espacio de almacenamiento utilizado por las copias de seguridad, pero también introduce riesgos. Un entorno con deduplicación puede generar un único punto de fallo (SPoF), ya que si el mecanismo de deduplicación falla o se corrompe, podríamos perder acceso a múltiples copias de seguridad que dependen de los mismos bloques deduplicados. Por esta razón, no se recomienda utilizar deduplicación en entornos de SQL Server para los archivos de base de datos, y su uso en archivos de copia de seguridad debe evaluarse con cautela.

Comparativa final: NTFS vs ReFS

NTFS sigue siendo una opción sólida para la mayoría de entornos SQL Server, especialmente en servidores que manejan bases de datos de tamaño medio o pequeño. Su menor consumo de recursos, la compatibilidad con un amplio abanico de herramientas de terceros y su fiabilidad hacen que sea preferido en muchos casos. Aunque la fragmentación y la necesidad de mantenimiento son factores a tener en cuenta, NTFS ofrece un equilibrio robusto entre rendimiento y estabilidad, sin requerir un hardware excepcionalmente avanzado.

ReFS, por otro lado, tiene claras ventajas cuando gestionamos grandes volúmenes de datos en sistemas avanzados de almacenamiento, como en configuraciones con Storage Spaces. Su diseño reduce la fragmentación y permite una gestión más eficiente de los datos, lo que es útil en entornos con grandes archivos o volúmenes masivos de información. No obstante, la necesidad de desactivar su función de integridad de datos en bases de datos SQL Server y su mayor consumo de recursos limitan su aplicabilidad en escenarios de bases de datos tradicionales.

Para bases de datos críticas o transaccionales, donde la carga de trabajo y los recursos del servidor ya están optimizados para SQL Server, NTFS sigue siendo la opción preferida. Si bien ReFS puede mejorar el rendimiento en algunos aspectos, su configuración más compleja y mayor uso de CPU y memoria lo convierten en una opción menos atractiva a menos que se trate de un entorno con necesidades específicas de almacenamiento masivo.

Conclusión

La elección entre NTFS y ReFS para SQL Server no tiene una respuesta única, ya que depende de las necesidades de cada entorno. NTFS sigue siendo la opción más estable y eficiente en términos de recursos, y es especialmente recomendable cuando se prioriza la compatibilidad y la menor sobrecarga en el servidor. ReFS, aunque potente en la gestión de grandes volúmenes de datos, requiere una configuración más cuidadosa, especialmente al desactivar sus funciones de integridad de datos, lo que puede reducir algunas de sus ventajas teóricas.

El consumo de recursos de ReFS y su necesidad de ajustes adicionales hacen que, en la mayoría de los escenarios, NTFS siga siendo una opción más práctica para bases de datos de producción en SQL Server. La clave está en evaluar los requisitos de almacenamiento y recursos de cada proyecto y elegir el sistema de archivos que mejor se adapte a nuestras necesidades.

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

Migrar SQL 2019 a 2022 con el menor tiempo de inactividad

El fin de soporte de SQL Server 2019 está a la vuelta de la esquina, eso ya lo sabemos. También hemos hablado en esta casa de cómo planificar una migración y, cuando lo hicimos, comentamos la posibilidad de valorar métodos para una migración Online, sin tiempo de inactividad o con el mínimo posible. Y, eso es justo de lo que os quiero contar hoy, esos métodos de migración casi transparentes para el usuario por su nula o baja inactividad.

Preparar una migración

Antes de entrar en las opciones de migración online, es fundamental preparar adecuadamente el entorno. La planificación es clave. Sin entrar mucho en detalle, que ya le dedicamos un artículo entero a este tema, debemos asegurarnos de que todas las aplicaciones que interactúan con la base de datos sean compatibles con SQL Server 2022. Una buena práctica es clonar el entorno de producción en un entorno de pruebas donde podamos simular la migración. Este paso extra nos permitirá identificar posibles inconvenientes y corregirlos antes de afectar el entorno productivo.

También es crucial realizar una evaluación de los requisitos de hardware y software, ya que SQL Server 2022 puede requerir actualizaciones en los sistemas operativos o en el hardware para aprovechar todas sus nuevas características. Una vez que hemos cubierto estos aspectos, estamos listos para explorar las opciones de migración online que nos ayudarán a reducir el tiempo de inactividad.

Migraciones Online (sin inactividad)

Una migración en caliente, también conocida como migración online, es el proceso en el que la base de datos se migra a un nuevo servidor o versión sin interrumpir el servicio o con una interrupción mínima. En lugar de detener las operaciones para realizar la migración, la base de datos permanece activa, y los usuarios pueden seguir accediendo a los datos mientras se lleva a cabo el proceso. Esto es especialmente crítico en entornos donde la disponibilidad continua es esencial, como en sistemas de comercio electrónico, fábricas que no pueden parar la producción o cualquier otro sistema que opere en tiempo real.

Un concepto clave asociado a las migraciones en caliente es el RTO, o «Recovery Time Objective» (Objetivo de Tiempo de Recuperación). El RTO se refiere al tiempo máximo tolerable durante el cual un sistema, aplicación o proceso puede estar inactivo antes de que se produzca un impacto significativo en la organización. En el contexto de una migración, el RTO define cuánto tiempo podemos permitir que la base de datos esté inaccesible durante el cambio, y es un factor crucial para determinar la estrategia de migración.

Cuando hablamos de minimizar el tiempo de inactividad, estamos trabajando directamente para cumplir con el RTO definido. Un RTO corto, como por ejemplo de unos pocos minutos, implica que necesitamos utilizar métodos avanzados de migración en caliente, como Always On, Database Mirroring o Log Shipping, que permiten que el tiempo de transición sea prácticamente imperceptible para los usuarios. De esta manera, podemos asegurar que la migración no solo sea efectiva, sino que también cumpla con las expectativas y requisitos de disponibilidad de la organización.

Migración con Always On: Alto coste, cero inactividad

Always On Availability Groups es, sin duda, una de las tecnologías más potentes y flexibles para lograr una migración con tiempo de inactividad cero o cercano a cero. La idea detrás de Always On es crear un grupo de disponibilidad que replique las bases de datos seleccionadas en uno o más nodos secundarios. Esto no solo ofrece alta disponibilidad y recuperación ante desastres, sino que también facilita las migraciones.

Always On existente

En el mejor de los casos, ya dispondremos de un Always On con dos o más servidores SQL Server 2019. En este caso, para aprovechar Always On en la migración a SQL Server 2022, lo primero que haremos será agregar un nuevo nodo (o varios) con SQL Server 2022 a nuestro grupo de disponibilidad actual. Es importante que el nodo con SQL Server 2022 tenga configurada una replicación síncrona para garantizar que no tendremos pérdida de datos. 

Una vez que el nodo 2022 esté sincronizado y funcionando correctamente, podemos proceder a realizar un failover manual al nuevo nodo. Durante este proceso, la mayoría de las conexiones se mantendrán activas y la interrupción será mínima (de pocos milisegundos).

Con el servicio balanceado al nodo SQL Server 2022, los nodos con SQL Server 2019 perderán la conexión, ya que no podrán alojar bases de datos de un servidor con una versión superior, por lo que tendremos que sacarlos del grupo de disponibilidad y actualizarlos a SQL 2022 o desmontarlos. En este punto, es el momento de añadir el resto de nodos con SQL Server 2022, si aún no lo habíamos hecho, para mantener la alta disponibilidad.

Si nuestro anterior Always On disponía de uno o varios Listener no tendremos que hacer nada más y no habrá ninguna pérdida de servicio. En caso contrario, las aplicaciones y usuarios deberán apuntar al nuevo servidor, con el tiempo de inactividad que conlleve el cambio por su lado.

Sin Always On anteriores

Si no disponemos de un grupo de alta disponibilidad Always On anterior la cosa se complica. Primero tenemos que asegurarnos de cumplir los requisitos para montar el Always On como disponer de una licencia SQL Server Enterprise o una sola base de datos (es la limitación de los Always On básicos con licencia estándar). Si cumplimos con estos requisitos, estamos listos para el siguiente paso, la configuración del Always On. Es importante destacar que este paso necesita de la instalación y configuración del servicio de clúster de Windows (WSFC) lo que nos puede requerir de uno o varios reinicios, con las consecuentes pérdidas de inactividad del servicio de base de datos.

Con el Always On ya configurado los pasos son los descritos en el apartado anterior: asegurarnos de que la replicación es correcta, balancear el servicio, modificar las conexiones de las aplicaciones para que apunten al nuevo servidor y desmontar el AG y apagar el servidor SQL Server 2019.

Migración con DB Mirroring: menor coste, baja inactividad

Database Mirroring es una antigua solución de alta disponibilidad anterior a la implementación de Always On pero que, hasta el día de hoy, se mantiene por compatibilidad. Además, no requiere de WSFC ni de licencia enterprise para funcionar lo que lo hace una solución ideal para nuestra migración con baja inactividad. 

Estos son los pasos a seguir para una migración de baja inactividad con DB Mirroring:

En el servidor SQL Server 2019:

  1. Hacer una copia completa de la base de datos.
  2. Hacer una copia de log de la base de datos.

En el servidor SQL Server 2022:

  1. Restaurar con No Recovery la copia completa de la base de datos
  2. Restaurar con No Recovery la copia de log de la base de datos.

Configurar el DB Mirroring:

  1. En el SQL Server 2019:
  1.  En el SQL Server 2012:
  1. Verifica que la configuración es correcta y que se está replicando en tiempo real. Puedes usar este script:

Migración:

  1. Detén las conexiones de los usuarios y balancea el DB Mirroring para convertir el servidor SQL Server 2022 en principal. Ejecuta este comando en el SQL Server 2022:
  1. Modifica las conexiones de tus aplicaciones y usuarios para que apunten al servidor SQL Server 2022 y restablece la conexión
  2. Elimina el DB Mirroring

 

Como puedes ver, gracias a este método de migración la pérdida de servicio ha sido mínima, sin embargo, sí que llega a existir. Además cuantas más bases de datos tengas más se va a alargar el proceso que se tiene que repetir manualmente por cada una de ellas.

Migración con Log Shipping: bajo coste, inactividad moderada

El Log Shipping es otra alternativa para realizar la migración de SQL Server 2019 a 2022, especialmente en entornos donde el presupuesto es limitado o donde necesitemos una solución más sencilla. Aunque el Log Shipping no nos ofrezca las mismas ventajas que Always On o Database Mirroring en términos de disponibilidad continua, sigue siendo una herramienta efectiva para minimizar el tiempo de inactividad.

Para el proceso de migración con Log Shipping, configuraremos la copia y restauración periódica de los archivos de registro de transacciones desde el servidor principal con SQL Server 2019 a un servidor secundario con SQL Server 2022. A diferencia de los otros métodos, el Log Shipping requiere un breve tiempo de inactividad al momento de realizar el balanceo final al nuevo servidor.

Para llevar a cabo este balanceo, debemos asegurarnos de que todos los logs pendientes se hayan restaurado en el servidor con SQL Server 2022. Una vez hecho esto, deshabilitaremos el servidor principal y configuraremos el nuevo servidor como el principal. Aunque este método requiere un breve tiempo de inactividad, sigue siendo una opción viable para entornos donde la alta disponibilidad no es crítica o donde la simplicidad y el bajo coste son prioritarios.

Conclusión

Migrar de SQL Server 2019 a 2022 sin inactividad es un proceso que puede parecer difícil, pero con las herramientas y estrategias adecuadas, podemos minimizar significativamente el tiempo de inactividad necesario. Always On, Database Mirroring y Log Shipping ofrecen soluciones adaptadas a diferentes necesidades y presupuestos. Always On es la opción más completa para entornos que no pueden permitirse ningún tipo de interrupción. Database Mirroring ofrece una buena combinación de seguridad y simplicidad, mientras que Log Shipping es ideal para aquellos que buscáis una solución económica y efectiva.

Cada uno de estos métodos tiene sus particularidades y ventajas, y la elección entre ellos dependerá de las características y requisitos específicos de nuestro entorno. Lo que es innegable es que, con la planificación adecuada y el uso de estas tecnologías, podemos llevar a cabo una migración exitosa a SQL Server 2022, garantizando así la continuidad de nuestras operaciones y aprovechando las ventajas de la nueva versión con el mínimo impacto en nuestros usuarios.

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

Buenas prácticas en Power BI Report Server (PBIRS)

Continuamos con los artículos sobre Power BI Report Server, ya hemos visto tanto sus características principales como los consejos de implantación y mantenimiento y hoy, y para cerrar esta semana temática, vamos a hablar de buenas prácticas. Lo primero que tenemos que recordar es que Power BI Report Server (PBIRS) está construido sobre la base de SQL Server Reporting Service (SSRS), una herramienta de reporte de BI de Microsoft con más de 15 años en el mercado. Con esto quiero decir que la mayoría de las cosas que vamos a ver ahora os sonarán familiares si ya habéis administrado SSRS pero si no es así no os preocupéis que para eso lo vamos a ver.

Configuración avanzada de Report Server

Cuando instalamos PBIRS tendremos a nuestra disposición una herramienta de configuración calcada a la de SSRS donde podremos realizar las configuraciones más básicas de este servicio. Sin embargo, esto no es todo,habrá aspectos que configuraremos en el propio servicio web y otros, los más avanzados, para los que necesitaremos un SSMS. Y, en concreto, son tres de estas configuraciones de las que vamos a hablar en este apartado. Configuraciones que, para la mayoría de las empresas pueden funcionar pero, para otras igual no tanto.

Para acceder a estas configuraciones nos conectaremos a nuestro PBIRS desde nuestro Management Studio (SSMS) usando la opción de conexión a SQL Server Reporting Service (SSRS). Una vez conectados abriremos las propiedades de la instancia y accederemos a las propiedades avanzadas. Aquí, entre otras, podremos encontrar la siguientes configuraciones:

Power BI Report Server Advanced Config

EnableMyReports

La configuración “Enable and disable My Reports» nos permite a los administradores activar o desactivar la funcionalidad de «Mis informes». Esta función, desactivada por defecto, ofrece a los usuarios la posibilidad de crear un espacio personal dentro del servidor donde pueden guardar y gestionar sus propios informes. Esto es similar al concepto Mi espacio de trabajo que tienen los usuarios dentro del servicio Power BI. Habilitar Mis informes es una excelente manera de fomentar la BI de autoservicio y puede ser beneficioso para fomentar la personalización y la autonomía de los usuarios, permitiéndoles trabajar de manera más eficiente sin sobrecargar los espacios compartidos del servidor. No obstante, dejarlo desactivado puede ser preferible en entornos donde la uniformidad y el control sobre los informes es una prioridad.

ExecutionLogDaysKept

ExecutionLogDaysKept es otra configuración importante que define cuántos días se conservan los registros de ejecución de informes en el servidor. Estos logs son fundamentales para el análisis de rendimiento y la solución de problemas, ya que contienen información detallada sobre cada ejecución de informes. Ajustar esta configuración nos permite a los administradores balancear entre la retención de información suficiente para análisis detallados y la gestión eficiente del espacio de almacenamiento. Por defecto esta propiedad está establecida en 60 días, un periodo de retención más largo puede ser útil para auditorías y análisis históricos, sobre todo si tienes informes que se ejecutan sólo una vez al mes o menos. Por otro lado, un periodo más corto puede ayudar a optimizar el rendimiento del servidor. 

EnablePowerBIReportExportUnderlyingData

Por último, la configuración EnablePowerBIReportExportUnderlyingData controla si los usuarios tienen permiso para exportar los datos subyacentes de los informes de Power BI. Esta opción es crucial para mantener la seguridad y privacidad de los datos. Permitir la exportación puede ser necesario para usuarios que requieran analizar la información fuera de la plataforma, pero también puede suponer un riesgo si los datos son sensibles. Por ello, esta configuración debe ser ajustada con cuidado, asegurando que solo los usuarios adecuados tengan acceso a esta funcionalidad y que se cumplan las políticas de seguridad de la organización. 

Si me preguntáis por mi opinión, yo soy totalmente partidario de deshabilitar esta opción. Además, un abuso de la descarga de información en horas de mucha actividad de usuarios puede suponernos un verdadero quebradero de cabeza.

Seguridad a nivel de carpetas en Report Server

Llegamos a una de las principales diferencias entre Power BI Report Server y el servicio en la nube de Power BI. Mientras en el cloud tenemos Workspaces que sirven como entornos aislados colaborativos para que los equipos desarrollen contenido de Power BI al unísono. Después creamos aplicaciones para facilitar la entrega del contenido a los usuarios. Estos conceptos no existen en Power BI Report Server. En PBIRS tendremos que usar carpetas.

Las carpetas dentro de Power BI Report Server (y SSRS) se comportan como carpetas dentro de un sistema de archivos. La seguridad a nivel de carpeta se puede aplicar para restringir el acceso a todo el contenido de la carpeta. Además, al igual que un sistema de archivos, se puede crear una jerarquía de carpetas. Esto es diferente a la naturaleza aplanada de App Workspaces dentro del servicio Power BI. 

Gestión de los permisos

Estemos alojando informes en el servicio o en PBIRS, debemos realizar una planificación cuidadosa desde el principio para proteger adecuadamente su contenido. Normalmente, tiene sentido crear carpetas para diferentes departamentos o equipos de la empresa como, por ejemplo, ventas, contabilidad, marketing, etc…

Aunque en Power BI Report Server (PBIRS), también podemos definir la seguridad en elementos individuales (por ejemplo, un único informe), normalmente no es una práctica. En implementaciones grandes, podemos encontrarnos con decenas o cientos de informes y mantener individualmente los permisos sería una pesadilla. Del mismo modo tenemos que huir de los permisos a usuarios individuales y, siempre que sea posible, utilizar grupos de usuarios. Si llevamos esto a rajatabla, podremos proteger múltiples informes relacionados y habilitar su uso para un subconjunto de usuarios sin complicaciones. 

En la mayoría de los casos, también recomiendo que os ciñais a una estructura de carpetas plana. De este modo, no solo será más fácil proteger las carpetas, también PBIRS coincidirá lógicamente con la estructura plana de Workspaces en el servicio Power BI. Esto nos facilitará la tarea de migración o  transferencia del contenido de Power BI Report Server (PBIRS) al servicio Power BI en la nube si alguna vez queremos hacerlo.

Reutilizar un modelo de datos en Report Server

Una de las limitaciones de Power BI Report Server (PBIRS) frente al servicio de Power BI en la nube es la capacidad de utilizar un mismo modelo de datos para diferentes informes. Así, mientras que en Power BI en la nube todos nuestros informes pueden acceder a un mismo modelo, si tenemos 12 informes que usan el mismo modelo de datos, en Power BI Report Server (PBIRS) tendremos que mantener 12 copias del modelo de datos. Esto, no hace falta que os lo diga, es un problema a la hora de actualizar los modelos y puede generar una discrepancia de datos entre los informes, que, en el mejor de los casos, nos provocará una reprimenda por parte de los usuarios. 

Sin embargo, nosotros que somos DBAs y sabemos de bases de datos y, sobre todo, de servicios de SQL Server, sabemos que podemos aprovecharnos de las capacidades de SQL Server Analysis Services para almacenar nuestras bases de datos dimensionales y, desde los informes de Power BI simplemente acceder a ese único origen de datos compartido para todos los reportes.

Analysis Services es una excelente opción si ya tenemos una inversión en SQL Server y sus componentes de BI, que la tendremos si hemos licenciado PBIRS con la licencia de SQL Server Enterprise. Sin embargo, si estamos implementando Power BI Report Server gracias al licenciamiento de Power BI Premium, también podemos aprovechar los conjuntos de datos que residen en la capacidad Premium como modelos de datos reutilizables.

Podemos establecer una conexión desde nuestros informes de Power BI a un conjunto de datos Premium como si fuera un modelo de Analysis Services. Para ello, debemos asegurarnos de que nuestra capacidad Premium tenga habilitada la lectura en la configuración del extremo XMLA.

Conclusión

En resumen, Power BI Report Server (PBIRS) es una herramienta muy potente, que, si se configura y gestiona adecuadamente, puede convertirse en un pilar fundamental para la inteligencia de negocio en tu organización. Desde la configuración avanzada para habilitar funciones como «Mis informes» o controlar la exportación de datos subyacentes, hasta la gestión cuidadosa de la seguridad a nivel de carpetas y la reutilización de modelos de datos, podemos optimizar cada aspecto de PBIRS para alinearlo con las necesidades y políticas de nuestra empresa. Implementar estas buenas prácticas no solo mejorará el rendimiento y la seguridad de nuestro entorno de reportes, sino que también facilitará futuras migraciones al servicio Power BI en la nube, asegurándonos que nuestra infraestructura de BI está preparada para el crecimiento y el cambio.

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, Power BI, Rendimiento, 0 comentarios