Infra

Políticas de SQL. Creando servidores Autoadministrados

Una de las mejores características de un buen profesional es que siempre busca formas de hacer su trabajo más eficiente y efectivo. Los administradores de base de datos no estamos exentos de esta norma y, una de las herramientas que tenemos a nuestra disposición para lograr esto es el uso de políticas en SQL Server. Si no habías oído hablar antes de esto no te preocupes, es una opción de SQL Server a menudo subestimada pero al final de este artículo vas a poder ver su gran potencial. Durante las próximas líneas explicaremos cómo las políticas pueden facilitarnos la vida a la hora de gestionar nuestras bases de datos, garantizando tanto el cumplimiento de normas como la eficiencia y el buen rendimiento.

Imaginemos un escenario donde gestionamos múltiples instancias de SQL Server, cada una con sus propias configuraciones, niveles de seguridad y requisitos de rendimiento. No es dificil verdad, es nuestro pan de cada día. Sabrás entonces que mantener la coherencia y el cumplimiento normativo en un entorno así puede ser una tarea exigente. Pues bien, aquí es donde las políticas de administración de SQL Server entran en juego y nos permiten definir, aplicar y automatizar reglas y directrices de una manera estructurada y eficiente.

¿Qué son las Políticas en SQL Server?

Las políticas en SQL Server son un componente del Policy-Based Management (PBM), introducido por primera vez en SQL Server 2008. Esta funcionalidad nos permite definir reglas y condiciones para nuestros servidores y bases de datos, asegurando que cumplan con ciertos estándares de configuración y rendimiento. En términos simples, una política es un conjunto de reglas que se aplican a los objetos de SQL Server para garantizar que se comporten de una manera específica. Estas reglas pueden abarcar desde la configuración del servidor hasta el diseño de la base de datos, y pueden ayudarnos a mantener un alto nivel de calidad y consistencia en nuestras bases de datos.

Por ejemplo, podríamos crear una política que fuerce a que todas las tablas tengan una PK (clave primaria). Esta política se aplicaría a todas las bases de datos en el servidor, y cualquier usuario intente crear una tabla sin PK recibiría un bonito error.

Otra política común es obligar a que todas las bases de datos tengan copias de seguridad regulares. Esta política la podremos configurar para verificar que se haya realizado un backup en las últimas 24 horas, y si no es así, que genere una alerta (que nos envía un correo) para que nosotros como administradores de la base de datos tomemos medidas.

Las políticas también nos pueden ser útiles para mantener la seguridad de nuestras bases de datos. Podríamos tener una política que fuerce a que todas las conexiones al servidor se realicen a través de una conexión segura, o que todas las contraseñas cumplan con ciertos requisitos de complejidad

Componentes Clave de una Política

Antes de ver cómo tenemos que hacer para crear una política personalizada tenemos que tener claros una serie de conceptos que vamos a necesitar. En concreto vamos a estar trabajando con condiciones, facetas y modos de evaluación además de las propias políticas. Veamos que son cada uno de ellos.

  • Condición (Condition): Una condición es un conjunto de expresiones que definen un estado deseado o un comportamiento que queremos comprobar. Por ejemplo, podríamos tener una condición que verifique si la recuperación de base de datos está configurada como «FULL».
  • Facetas (Facets): Las facetas son conjuntos predefinidos de propiedades de los objetos de SQL Server. Por ejemplo, hay facetas para bases de datos, servidores, procedimientos almacenados, entre otros. Cada faceta contiene varias propiedades que podemos utilizar en nuestras condiciones.
  • Política (Policy): Una política combina una condición con una faceta y define cómo y cuándo se debe evaluar esta combinación. Las políticas pueden ser evaluadas bajo demanda, de forma programada o en respuesta a eventos específicos.
  • Modo de Evaluación (Evaluation Mode): Este define cuándo y cómo se evaluará una política. Existen varios modos, incluyendo «On Demand», «On Schedule», «On Change – Prevent» y «On Change – Log Only».

Creando y Administrando Políticas

Para implementar políticas en SQL Server, utilizamos la característica de Administración Basada en Políticas (PBM, por sus siglas en inglés). Como ya hemos visto, PBM nos permite definir políticas, verificar su cumplimiento y aplicarlas automáticamente. Lo primero que deberemos hacer es definir una condición. Una vez que hayamos definido una condición, ya podremos crear una política que utilice esa condición. Por último definiremos su modo de evaluación.

Paso 1: Definir una Condición

El primer paso para crear una política es definir una condición. Supongamos que queremos asegurarnos de que todas nuestras bases de datos estén en modo de recuperación FULL. Para ello, primero definimos una condición:

Abrimos SQL Server Management Studio (SSMS) y navegamos hasta «Management» -> «Policy Management». Hacemos clic derecho en «Conditions» y seleccionamos «New Condition». Le damos un nombre a nuestra condición, por ejemplo, «Database Recovery Full». En «Facet», seleccionamos «Database». En «Expression», añadimos una nueva condición: @RecoveryModel = ‘FULL’.

Paso 2: Crear la Política

Con la condición definida, procedemos a crear la política que la usará:

Hacemos clic derecho en «Policies» y seleccionamos «New Policy». Le damos un nombre, como «Ensure Full Recovery Mode». Asignamos la condición «Database Recovery Full» que creamos anteriormente. En «Against Targets», especificamos los objetos a los que se aplicará esta política, en este caso, todas las bases de datos. Elegimos el modo de evaluación. Para este ejemplo, seleccionamos «On Change – Log Only» para registrar cualquier incumplimiento sin impedir cambios.

Paso 3: Evaluar y Aplicar la Política

Una vez creada la política, podemos evaluarla inmediatamente:

Hacemos clic derecho en la política y seleccionamos «Evaluate». SQL Server nos mostrará todas las bases de datos que no cumplen con la política. Podemos tomar acciones correctivas directamente desde el cuadro de diálogo de evaluación si es necesario.

Paso Extra: Exporta tus políticas

Cuando ya tengas todas tus políticas creadas en uno de tus servidores, no es necesario que las recrees en el resto, simplemente podemos exportarlas y volverlas a importar en tantos servidores como queramos. Para ello solo tendremos que dar clic derecho sobre nuestra política y dar a exportar. Para importar haremos clic derecho sobre la carpeta políticas en nuestro SSMS y le daremos a importar política.

Beneficios del Uso de Políticas

Como venimos comentando, las políticas nos permiten estandarizar configuraciones y prácticas en todas nuestras instancias de SQL Server. De esta manera vamos a lograr asegurar el cumplimiento de normas corporativas y regulatorias. Esto es especialmente importante en entornos que deben cumplir estándares y leyes como GDPR, HIPAA o SOX.

Además, al definir políticas que se evalúan automáticamente, podemos reducir nuestra carga de trabajo y minimizar el riesgo de errores humanos. Por ejemplo, podemos programar evaluaciones periódicas para asegurar que todas nuestras configuraciones de seguridad y rendimiento se mantengan conforme a las políticas definidas.

Pero esto no es todo, las políticas también nos ayudan a identificar y corregir problemas potenciales antes de que se conviertan en problemas mayores. Al tener visibilidad continua de cómo se comportan nuestros servidores y bases de datos en relación con nuestras políticas, podemos ser proactivos en la gestión y el mantenimiento.

Conclusión

El uso de políticas para administrar SQL Server es una práctica que nos permite mantener el control y la coherencia en nuestros entornos de bases de datos. Al definir y aplicar políticas claras, podemos asegurar el cumplimiento normativo, automatizar tareas administrativas y mantener un alto nivel de rendimiento y seguridad. En resumen, las políticas no solo simplifican la administración de SQL Server, sino que también nos permiten ser más eficientes en nuestro trabajo como DBAs. Así que, no esperes más. Pruébalo y considera aprovechar el poder de las políticas para facilitarte la vida.

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, 1 comentario

¡Adiós al error 0x851A001A! Instala SQL sin problemas en Windows 11

¿Te encuentras con el error 0x851A001A al instalar SQL en tu nuevo equipo con Windows 11? ¡No te preocupes! Este error es común y tiene una solución sencilla. En este artículo te explico qué es lo que lo provoca y cómo puedes solucionarlo para poner en marcha tu instancia de SQL en cuestión de minutos.

El error 0x851A001A: un obstáculo común

En varias ocasiones me he topado con clientes que presentaban problemas con sus instalaciones de SQL al tratar de realizarlas sobre equipos nuevos en los que se había instalado Windows 11. El error en cuestión se trata del 0x851A001A, y es un error contemplado por Microsoft.

0x851A001A

Este fallo se produce durante la instalación de cualquier versión de SQL, debido a que el instalador de SQL no es capaz de realizar ciertas acciones de configuración. Como os digo, este error suele producirse en los equipos con sistemas operativos Windows 11, pero os diré que, en alguna ocasión poco habitual, me he visto en la misma situación con otros sistemas.

¿Qué es el tamaño de sector de disco y por qué es importante?

El tamaño del sector de un disco duro hace referencia a la cantidad de información que puede almacenar cada una de las secciones lógicas en las que se divide. Ya hablamos de este tema sin profundizar tanto en este artículo. Este tamaño es importante ya que afecta a distintos factores:

  • Eficiencia de almacenamiento: Un sector más grande será capaz de almacenar una cantidad de información mayor, necesitando menos espacio en el disco para guardarla, y, por tanto, optimizando el espacio.
  • Rendimiento: En general, cuanto mayor sea el tamaño del sector, más rápido realizará las operaciones de lectura y escritura de datos.
  • Compatibilidad: No todos los sistemas operativos ni todos los programas son compatibles con todos los tamaños de sector.

¿Por qué se produce el error 0x851A001A?

En muchos de los discos actuales podemos encontrar tamaños de sector de 4096 bytes, pero en discos más antiguos podemos encontrar sectores de 512 bytes. Aunque según Microsoft estos tamaños deberían ser compatibles con SQL, es en estos casos cuando nos topamos con nuestro error 0x851A001A.

En este punto, vamos a entrar en el terreno de lo que llamaremos “especulación responsable”, para tratar de explicar qué es lo que está sucediendo en estos casos, ya que he buscado información al respecto, pero no he encontrado ninguna causa concreta. En mi opinión, creo que los discos duros más nuevos, que permiten trabajar con tamaños de sector de disco mayores, en algún punto de la instalación de Windows 11 pasan a emular un tamaño de sector menor, como por ejemplo 4096 bytes, que es compatible con SQL. Sin embargo, debe haber algún error en esta emulación que provoca que SQL detecte que el tamaño del sector del disco, es mayor, y por tanto nos devuelve el error de compatibilidad.

¿Por qué creo esto? Porque de momento no me he topado con este error en equipos que ya estaban en funcionamiento, por ejemplo con un Windows 10 y se han actualizado a Windows 11; y si me ha pasado con equipos nuevos en los que se había instalado Windows 11, donde los discos son más modernos.

En cualquiera de los casos, seguro que estás pensando, todo esto está muy bien, pero ¿cómo lo soluciono? Pues vamos a verlo.

Solución rápida y efectiva

Para solucionar este problema y disfrutar de SQL en tu Windows 11, o cualquier otro sistema, tendrás que modificar el Registro de Windows. Para hacerlo de una forma sencilla, solo tienes que abrir una ventana de Powershell como administrador y seguir estos pasos:

  1. Comprueba el tamaño del sector de tu disco:

* Recuerda reemplazar C: con la letra de tu unidad de disco.

  1. Modifica el tamaño del sector:
  1. Comprueba el cambio:
  1. Reinicia tu equipo.

¡Instalación de SQL sin errores!

Una vez completado este proceso, podrás instalar SQL en tu Windows 11 sin problemas, y el error 0x851A001A será cosa del pasado.

Recursos adicionales:

Por último, te dejo algunos enlaces con más información al respecto:

https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-os-4kb-disk-sector-size?WT.mc_id=DP-MVP-5440

https://www.zentinels.net/solucion-al-error-0x851a001a-al-instalar-sql-server

https://learn.microsoft.com/en-us/answers/questions/1367064/unable-to-install-sql-server-2019-on-windows-11-ex

Espero humildemente que este pequeño artículo te ayude a resolver este error, y por supuesto, si tienes alguna recomendación adicional, o quieres hacer alguna aportación; te invito a sumarte en los comentarios para que así podamos seguir aprendiendo como comunidad

#SQLServer #Windows11 #Error0x851A001A #InstalacionSQL #SolucionProblemas #Aprendizaje #Somoscomunidad #Tecnología

El conocimiento es poder. El aprendizaje es el camino hacia el poder

John F. Kennedy
Publicado por Sergio Isidro García en SQL Server, 0 comentarios

Reducir el tamaño de bases de datos SQL

En esta ocasión vengo a explicaros como puedes hacer para reducir el espacio que ocupan nuestras bases de datos liberando el espacio libre que hay en los ficheros. Para ello, tendremos que hacer un Shrink de los ficheros de base de datos. Tendrás que hacerlo tanto en el ficheros de datos como en el de log (o en el que sepamos que existe un problema).

Evita siempre que puedas la operación de reducir de ficheros, sobre todo en los ficheros de datos, ya que consume muchos recursos del servidor y además va a empeorar el rendimiento de nuestra base de datos. Si no queda más remedio o si has eliminado tanta información que merezca la pena hacerlo, ten la precaución de programarlo fuera de horas de trabajo y de reconstruir los índices fragmentados una vez termines.

En los ficheros de log, como en los de TempDB no vas a tener los problemas de fragmentación pero si de consumo de recursos por lo que aunque no tengamos que ser tan estrictos si debemos intervenir con la debida precaución.

Puedes encontrar los script que he usado en el video aquí. Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

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

Migrar de Azure SQL DB a Azure Managed Instance

Te pongo en situación, tu empresa decidió hace tiempo empezar a desplegar servicios en la nube de azure. En una fase inicial del proyecto se decidió usar bases de datos de Azure SQL sin servidor, la gama de entrada a SQL en Azure. Ha pasado el tiempo y se ha descubierto que el proyecto no puede continuar debido a las limitaciones de esta solución SAAS. Hay que migrar las bases de datos.

¿Por qué migrar y donde?

Como ya te he adelantado en la descripción, el problema es que necesitas alguna de las características de SQL Server que no incluyen las bases de datos de Azure SQL. Sin embargo, sí que sigues convencido de que la mejor opción es un producto SaaS administrado en la nube, con un tiempo de disponibilidad del 99,99%, con actualizaciones automáticas, seguridad de datos avanzada y análisis de registros SQL de Azure. Básicamente no tener que administrar una máquina local o virtual IaaS.

Parece que la solución es clara, necesitas una instancia administrada de SQL en Azure. Las características de Azure MI que no tienen las bases de datos de Azure SQL son:

  • Consultas entre bases de datos 
  • Usar las bases de datos como publicadoras en replicación.
  • Copias de seguridad y restauraciones a petición por T-SQL.
  • Compatibilidad con .NET SQL CLR
  • Activadores de ámbito de servidor o triggers de inicio de sesión
  • Captura de datos modificados (CDC) 
  • Acceso a Resource Governor.
  • Agente de SQL.
  • Y más…

¿Cómo no migrar?

En este punto te piden a ti, DBA, llevar a cabo esta migración. Parece una tarea sencilla, ¿verdad? Pues vamos a ver que de eso nada. Como acabamos de ver en el apartado anterior, una de las limitaciones de las bases de datos de Azure SQL es que no permiten copias de seguridad por T-SQL. Aunque si tienen copias de seguridad automáticas por parte de Azure, estas solo se pueden restaurar como otra base de datos de Azure SQL, no las vas a poder llevar a una instancia.

Tampoco vas a poder usar una base de datos de Azure SQL como origen de datos en Azure Data Migration Service (DMS) ni en Data Migration Assistant (DMA). Y esto no es todo, tampoco admiten DB Mirroring, AlwaysOn, Log Shipping o Replicación. Estás perdido, solo te queda implementar una solución de copia de datos manual con T-SQL, SSIS o Azure Data Factory lo que te va a suponer mucho esfuerzo y una sobrecarga de trabajo difícil de asumir. Pero, no te preocupes, yo te voy a contar cómo hacerlo de manera fácil.

¿Qué opciones tienes?

Visto lo visto, partiendo de las premisas anteriores lo primero que tienes que asumir es que esto va a ser un proceso manual. Podrías automatizarlo con las alternativas que hemos mencionado antes de T-SQL, SSIS o Data Factory pero eso no es lo que buscas. Necesitas una solución simple, mover los datos y ya está. Para eso tenemos dos opciones o usar el asistente de Import/Export con SSIS en SSMS o usar el asistente para importar/exportar aplicaciones de capa de datos, también en SSMS.

Asume que durante la migración vas a tener un tiempo de inactividad total de las bases de datos. Realmente vas a poder seguir leyendo la base de datos Azure SQL de origen pero si haces cambios es posible que luego no los veas replicados en la Azure MI. 

Ahora bien, puedes reducir el tiempo de inactividad migrando las tablas por partes siempre que tu aplicación lo permita. Si tienes unos datos “frios”, una especie de diccionarios con pocos o ningún cambio puedes migrar esas primero sin parar la aplicación para luego reducir el tiempo al migrar solo el resto de tablas.

Migrar con el asistente de import/export de SSIS en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un paquete de SSIS básico para la copia de datos. OJO, solo para la copia de datos. Si las tablas no existen si que las va a crear pero no va a crear ningún otro objeto, ni siquiera los índices. No, ni los índices clustered ni las PK ni nada. Por supuesto tampoco va a crear vistas, triggers, funciones, procedimientos, etc…

Paso 1

Como este asistente solo copia datos lo primero que tienes que hacer es crear en tu instancia administrada de Azure la base de datos con todos los objetos de la base de datos. Sin embargo, en este punto no te recomiendo crear ni los triggers ni las Foreign Keys para evitar problemas con la copia de datos. Para generar los script de creación de objetos puedes usar el asistente que incluye el propio SSMS.

migrar 1

Paso 2

Ahora que ya tienes toda la estructura de tu base de datos creada en Azure MI puedes usar el asistente de importación y exportación para copiar los datos. No vamos a profundizar en este punto porque ya lo hemos explicado en este artículo y en este vídeo. Solo vas a tener que elegir el origen y el destino correctos.

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de crear los triggers y las FK que antes hemos dejado pendientes. También debes validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Migrar con el asistente de import/export de aplicaciones de capa de datos en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un archivo bacpac que luego vas a poder importar sobre la base de datos de tu instancia administrada usando el mismo asistente. Es muy parecido a una copia de seguridad tradicional aunque no es exactamente lo mismo. Vas a ver que los pasos son muy simples.

Paso 1

A diferencia del anterior, este asistente no solo copia datos sino que te va a migrar también los objetos. Además, para importarlo, solo vas a poder hacerlo sobre una base de datos nueva así que en este paso vas a exportar directamente los datos de origen en formato bacpac desde tu SSMS. Haz clic derecho sobre la base de datos, ve al menú tareas y ahí a la opción Exportar aplicación de capa de datos…

migrar 2

Paso 2

Es el momento de restaurar en el destino. Conectate con SSMS a tu instancia administrada de Azure y con clic derecho sobre “bases de datos” ve a restaurar aplicación de capa de datos. Sigue los pasos del asistente para importar tu archivo bacpac.

migrar 3

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Otras opciones

Existe un tercer método simple que no te había comentado hasta ahora pero que también te puede servir para migrar tus datos. Es bastante más sencillo que los anteriores pero su uso queda limitado a bases de datos realmente pequeñas. Esta tercera opción consiste en generar los scripts de base de datos igual que has hecho en el primer paso de la primera solución que te he enseñado pero, en las opciones avanzadas, seleccionar también que genere los script para migrar los datos. De esta manera te generará los scripts con un insert por cada registro de cada tabla que tengas. Como ves te va a mover los datos pero es del todo ineficiente y solo es para bases de datos con pocas tablas y muy pocos registros.

Conclusión

Has visto las formas sencillas de migrar tus datos de una base de datos de Azure SQL a una instancia administrada de Azure. Con estos métodos vas a poder salir airoso de esta difícil tarea. Ahora ya si te quieres complicar te recomiendo crear un paquete SSIS que copie los datos con un bucle por cada una de las bases de datos en tu servidor de bases de datos de Azure SQL y lo que se te ocurra. A mi es la solución que más me gusta pero, cierto es, que solo merece la pena si las que tienes que migrar son muchas 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 Cloud, 0 comentarios

Remote Dedicated Admin Conection (R DAC). Vas a querer habilitarlo en tus SQL Server.

¿Sabías que SQL Server implementa un sistema de conexiones de emergencia para cuando todo lo demás falla? Se llama DAC (Dedicated Admin Connection) y es una las puertas traseras que todo DBA tiene que habilitar en sus servidores SQL para poder acceder cuando el servidor está tan saturado que no responde. Más bien podríamos considerarlo una entrada de emergencia, si es que el término existe.

¿Qué es DAC y cómo funciona?

Como hemos comentado en la introducción DAC es una conexión dedicada para administradores que nos va a permitir acceder a nuestro servidor SQL Server aun cuando los problemas de rendimiento sean tan graves que nada más responda. Cuando habilitamos DAC y abrimos una conexión de esta manera, lo que realmente estamos haciendo es decirle a SQL Server que se reserve un hilo de proceso para nosotros, sea lo que sea que esté corriendo en otros procesos. Como habrás intuido, tiene un problema, no paraleliza, el hecho de reservar un único hilo de procesos va a hacer que si una consulta necesita paralelizar de error. Aun así, con un hilo de proceso va a ser suficiente para localizar la consulta o consultas que están saturando el servidor y poder detenerlas.

¿Tipos de DAC?

Antes de nada, DAC es un acrónimo común, en este artículo siempre nos referimos a las Dedicated Admin Connection. SQL Server también implementa una cosa llamada Aplicaciones de Capa de Datos que llama DAC Package pero no estamos hablando de eso, no tiene nada que ver con esto.

Ahora que tenemos esto claro, tenemos dos tipos de conexiones dedicadas para administradores y son en local o remotas. Cuando hablamos de conexiones DAC remotas vamos a verlo como RDAC o Remote Dedicated Admin Connection. DAC siempre está habilitado en SQL Server y no lo podemos deshabilitar, sin embargo, RDAC por defecto no lo está y tendremos que habilitarlo nosotros manualmente.

¿Por qué necesitas habilitar RDAC?

Como hemos visto, RDAC es lo mismo que DAC solo que de forma remota. Si podemos entrar al servidor de manera local y conectar por DAC, ¿por qué deberíamos habilitar RDAC? Muy fácil, estamos hablando de una puerta trasera para emergencias, casos en los que el servidor va a estar tan saturado que es posible que ni podamos conectar de manera local por terminal server. En esta situación, tener un endpoint a la escucha de manera remota que siempre está habilitado para acceder por muy mal que esté el servidor puede ser la diferencia entre tener que reiniciar el servidor o no. Y nunca querremos tener que llegar a reiniciar el servidor, ¿verdad?

Habilitar Remote DAC

A nivel de instancia, habilitar RDAC es tan sencillo como ejecutar el siguiente comando de configuración:

Sin embargo, depende de la seguridad de tu red es probable que tengas que hablar con el administrador de redes para que te permita estas conexiones. Como hemos comentado antes por encima, Remote DAC usa un endpoint específico, lo que significa que no está a la escucha por el mismo puerto que las conexiones normales. Normalmente usará el puerto 1434 en vez del 1433. Asegúrate que el administrador de red te permite esas conexiones en el firewall antes de que tengas que echar mano de ellas y no vayas a poder.

Limitaciones de DAC

Tanto DAC como RDAC tienen las mismas limitaciones, y es normal, en el fondo son el mismo tipo de conexión. Esta limitación básica es que solo reserva un hilo de procesamiento por lo que solo vamos a poder tener una conexión abierta y ejecutar consultas sin paralelismo. Puedes pensar que es un gran hándicap pero, te aseguro que no. DAC no está pensado para trabajar normalmente ni para ejecutar planes de mantenimiento ni nada parecido. Solo es un método de acceso de emergencia para casos puntuales y, en esos casos, aun con esta limitación, es más que suficiente.

Por último, otra limitación es que solo van a poder usar este tipo de conexiones los usuarios sysadmin. Es lógico también, otro tipo de usuarios, aunque pudiesen acceder, no iban a poder solucionar la incidencia.

¿Cómo conectar usando DAC?

Ya sabemos casi todo lo necesario sobre DAC y por qué lo necesitamos, ahora bien, nos falta lo más importante, ¿cómo se usa?. Primero de todo dejame decirte que ojalá tengas la suerte de no necesitarlo nunca pero, como esto no es un mundo de fantasía, vamos a ver cómo vamos a tener que conectarnos. En este sentido tanto para conexiones en local (DAC) como para remotas (RDAC) es exactamente igual. En principio esta solución está pensada para conectarse desde una ventana de comandos con SQLCMD y para ello en la cadena de conexión usaremos el modificador -A. Sin embargo, tenemos la posibilidad de conectar también desde el SSMS con el prefijo “Admin:” antes del nombre del servidor.

El uso de SSMS tiene sus pegas, por un lado, aunque no es una limitación real, queda prácticamente limitado a conexiones RDAC ya que con el servidor completamente saturado rara vez vamos a poder ejecutar SSMS en local en un tiempo razonable. La segunda pega del uso de SSMS tiene que ver con el límite de sólo una conexión DAC simultánea y es que, SSMS, en concreto el explorador de objetos, ya consume más de una conexión. Por este motivo, su uso queda limitado a una conexión de una ventana de consultas exclusivamente.

DAC

Para conectar por una ventana de comandos usaremos los siguientes comandos:

Local (DAC):

Remoto (RDAC):

Es importante tanto el modificador -A para usar la conexión DAC como el “-d master” para especificar que conecte a esta base de datos. Esto se debe a que si la base de datos por defecto del usuario está offline la conexión va a fallar. De esta manera nos aseguramos que conectemos a la master y nos evitamos ese problema.

Conclusión

Gracias a las conexiones dedicadas para administradores DAC y RDAC vamos a poder garantizarnos un acceso de emergencia a nuestros servidores en caso de que todo lo demás esté fallando. Dedica unos minutos a habilitar RDAC en tus servidores y a validar su funcionamiento, así como, a familiarizarte con su uso por SQLCMD. No esperes a tener un problema para probar porque, en ese caso, es probable que el estrés del momento te juegue una mala pasada.

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

¿Es bueno comprimir los backups de SQL?

Cuando tenemos un SQL Server con licencia standard o enterprise tenemos la opción de comprimir las copias de seguridad. Pero, ¿realmente es buena idea comprimir los backups? ¿se reduce mucho el tamaño? ¿afecta al rendimiento? Eso es justo lo que os trato de demostrar en este video con varias pruebas para que podamos comprobarlo juntos. Si quieres jugar déjame un comentario con lo que crees que va a pasar antes de reproducir el vídeo.

Como has visto, aunque los backups comprimidos van a requerir más recursos de CPU tanto para hacerse como para restaurarse terminan tardando mucho menos. El almacenamiento SIEMPRE es el hardware más lento y por tanto cualquier ahorro en ese recurso se va a notar sobre cualquier otro aspecto. Y esta prueba ha sido con la copia en local, imaginaos que se tiene que llevar por red a un NAS o a la nube dependiendo de nuestra tasa de subida de la conexión a internet, la diferencia sería mucho mayor.

A no ser que tengas problemas de consumo de CPU en tu máquina y el consumo de E/S de disco en el dispositivo de backup no sea un problema para ti mi recomendación es que comprimas los backups.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, Videos, 2 comentarios

Actualización Segura en Always On

Hoy vamos a aprovechar que recientemente se ha liberado SQL 2022 – CU13 para hablar de un proceso a simple vista trivial, pero que requiere de planificación, como es la actualización de SQL Server en los nodos de un grupo de disponibilidad Always On. No es la primera vez que comentamos en el blog la importancia de mantener nuestros SQL Server siempre actualizados para evitar vulnerabilidades graves como la que vimos aquí. En este sentido, nuestros Always On (que además suelen contener la información más crítica) son especialmente delicados. Y es que cualquiera puede ejecutar un parche de actualización y darle a siguiente hasta que termine pero, hacerlo bien, sobre todo en infraestructuras complejas como los Always On, requiere un cariño extra.

¿Qué es un Always On?

Si estás perdido en este punto no te preocupes, vamos a empezar por el principio, los grupos de disponibilidad Always On son una solución de alta disponibilidad que incorpora SQL Server en la que, por medio de un clúster de Windows (WSFC) varios servidores o nodos replican la información de nuestras bases de datos de manera síncrona o asíncrona. Esta es una breve pincelada (más bien un resumen a brocha gorda) de esta complejísima solución, si quieres saber más pásate por el artículo que le dedicamos a este tema.

El proceso de actualización

Cualquier proceso de actualización bien planeado debe constar de 3 fases principales, las pruebas previas (conocidas también como pre-checks), la actualización propiamente dicha y las pruebas finales o post-checks. Cuando hablamos de un Always On esto también va a ser así a grandes rasgos pero va a tener particularidades como pasos previos y posteriores específicos para cada uno de los nodos en función de su rol.

Pasos previos globales para la actualización

Antes de empezar a actualizar nuestros SQL Server del Always On, al igual que en cualquier proceso de actualización, deberemos revisar la documentación de la actualización en busca de errores conocidos o incompatibilidades que puedan hacer que abortemos el proceso antes de iniciarlo.

Una vez que sabemos que la actualización es teóricamente viable, vamos a verificar el entorno, en este punto verificaremos la salud de nuestro Always On (y su quórum) y comprobaremos que hay espacio suficiente en los discos para acometer con éxito el proceso de actualización. 

Con todas las comprobaciones finalizadas llega el momento de preparar el entorno, idealmente estaremos en un momento sin ninguna carga de trabajo aunque, en caso de los entornos críticos que requieren de un Always On, esto suele ser inviable. Igualmente nosotros haremos una copia de seguridad de los datos y deshabilitaremos los jobs no críticos para evitar en la medida de lo posible cualquier interferencia en el proceso. En este sentido, también es recomendable deshabilitar el balanceo automático durante todo el proceso.

Actualización paso a paso

Llega el momento de empezar a actualizar, empezaremos siempre por las réplicas secundarias externas de nuestro Always On (en caso de tenerlas) o por las que tengan replicación asíncrona. Estas réplicas tienen la ventaja de no estar sincronizadas en tiempo real con la réplica principal por lo que si algo sale mal el impacto será menor. Empezaremos validando nuevamente el estado de la sincronización (idealmente verificaremos el failover) y deteniendo la replicación de datos para las bases de datos de la réplica a actualizar. Con la replicación detenida aplicaremos el parche de actualización.Una vez aplicado el parche podremos reanudar la sincronización y verificar que todo ha salido bien. Repetiremos estos pasos por todas las réplicas secundarias. Comprobaremos que todas las réplicas tienen los datos actualizados y están sincronizando al finalizar el proceso.

Con todas las réplicas secundarias actualizadas y verificado que no ha habido ningún problema llega el momento más crítico: actualizar el nodo primario. Empezaremos verificando la replicación para garantizar que no haya pérdida de datos y realizando un failover (balanceo) del rol a otro nodo. En este momento el rol principal ya será uno de los actualizados por lo que podremos proceder en este como en los anteriores. Detendremos la replicación, aplicaremos el parche, reanudaremos la sincronización y verificaremos que todo está correcto. En caso de que sea necesario realizaremos otro failover para devolver el rol al nodo principal inicial.

Pasos posteriores a la actualización

Una vez que ya tenemos todos los nodos actualizados es el momento de las comprobaciones finales. Comprobaremos la versión de SQL y que todos los nodos están sincronizando. MUY IMPORTANTE, volveremos a habilitar los jobs que hayamos deshabilitado al inicio y el balanceo automático . Con esto ya habría finalizado el proceso, recuerda que debes prestar especial atención a que las aplicaciones vuelvan a conectar correctamente y al rendimiento global tras la actualización.

¿Por qué detener la sincronización durante la actualización?

Hemos comentado que cuando aplicas un parche a una réplica, ya sea sincrónica o asincrónica, es recomendable parar la replicación de esa réplica durante el proceso de actualización. Os he dicho que antes de aplicar el proceso de actualización de cada nodo debíamos detener la sincronización para habilitarla de nuevo después, justo al terminar ese nodo y antes de empezar con los siguientes. Esto se debe a que la aplicación de un parche puede causar cambios en la base de datos que podrían interrumpir la replicación si ésta sigue activa. Al parar la replicación, te aseguras de que cualquier cambio realizado por el parche no afecte a las otras réplicas hasta que hayas verificado que el parche se ha aplicado correctamente y que la réplica actualizada está funcionando como se espera.

Esto también tiene un punto negativo, cuando detienes la replicación de una base de datos, el nodo principal sigue acumulando los cambios en sus ficheros de log de transacciones por lo que asegúrate de tener suficiente espacio y mantén vigilado en todo momento el crecimiento de los ficheros.

Conclusión

Aplicar un parche de actualización a nuestros servidores siempre es una tarea delicada pero, con una buena planificación y siguiendo los pasos correctos podremos hacerlo sin mayor problema. Recuerda que lo que hemos comentado en este post son una guia de recomendaciones para una actualización perfecta en un entorno ideal, la vida real no siempre es tan idílica y puede que tengamos que prescindir de alguno de los pasos. Sin embargo hay que conocerlos y entender bien el por qué están en esta guía para poder valorar el riesgo de no acometerlos. Y si tienes tus SQL en la nube como bases de datos o instancias administradas de Azure, enhorabuena, te has ahorrado para siempre todos estos pasos.

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