Extender un grupo de disponibilidad Always On a Azure SQL Managed Instance (vista previa)

Se aplica a:Azure SQL Managed Instance

Este artículo te enseña cómo ampliar un grupo de disponibilidad Always On con múltiples bases de datos entre SQL Server y Azure SQL Managed Instance mediante el enlace Instancia administrada utilizando SQL Server Management Studio (SSMS), PowerShell o CLI de Azure.

Este artículo trata sobre el modo de enlace de múltiples bases de datos, que replica todas las bases de datos de un grupo de disponibilidad a través de un solo enlace. El modo de enlace de base de datos única replica una base de datos por enlace.

Note

El soporte para vincular múltiples bases de datos en un grupo de disponibilidad Always On entre SQL Server y Azure SQL Managed Instance está actualmente en fase de vista previa.

Overview

Cuando extiendes un grupo de disponibilidad Always On entre SQL Server y Azure SQL Managed Instance, creas un enlace que replica varias bases de datos de un grupo de disponibilidad hacia la réplica objetivo. El enlace utiliza un grupo de disponibilidad distribuido para replicar cambios en casi tiempo real desde la réplica primaria actual hasta las copias de la base de datos de solo lectura en la réplica secundaria. Esto asegura que las copias de solo lectura en el secundario permanezcan actualizadas respecto al primario.

Puedes usar un grupo de disponibilidad existente o empezar con bases de datos independientes. Cuando seleccionas bases de datos independientes en SSMS, el asistente crea un grupo de disponibilidad de un solo nodo en el primario inicial y replica las bases de datos seleccionadas a través de un enlace.

Tanto SQL Server como Azure SQL Managed Instance pueden ser los principales iniciales. Crear el enlace desde SQL Managed Instance requiere SQL Server 2022 o SQL Server 2025 con la actualización acumulativa requerida y una política de actualización de SQL Managed Instance correspondiente. Los ejemplos de creación en este artículo comienzan desde SQL Server. No explican paso a paso la creación a partir de SQL Managed Instance. Se soporta conmutación por fallo con inversión de roles entre SQL Server y Azure SQL Managed Instance para instancias configuradas con políticas de actualización coincidentes.

Compatibilidad

Los siguientes requisitos se aplican para extender un grupo de disponibilidad mediante un enlace de múltiples bases de datos durante la vista previa. Se soporta SQL Server tanto en Windows como en Linux. Debes instalar la actualización acumulativa (CU) requerida. Las versiones anteriores no soportan esta función.

Versión de SQL Server Se requiere una actualización Ediciones compatibles
SQL Server 2022 (16.x) CU27 o una versión posterior Empresas y desarrolladores
SQL Server 2025 (17.x) CU9 o posterior Empresa y desarrollo

Tenga en cuenta lo siguiente.

  • La edición estándar no está soportada porque los grupos de disponibilidad básica solo admiten una base de datos.
  • SQL Server 2019 y versiones anteriores no son compatibles con el modo de enlace de múltiples bases de datos porque carecen de la tecnología necesaria introducida en SQL Server 2022.
  • Para crear el vínculo desde SQL Managed Instance o invertir los roles para volver a SQL Server, la instancia administrada de SQL debe usar la directiva de actualización que coincida con la versión de SQL Server. Para la replicación unidireccional y el cambio desde SQL Server, la política de actualización de destino debe coincidir o ser superior a la versión de tu SQL Server.
    • SQL Server 2022 soporta replicación a instancias configuradas con las políticas de SQL Server 2022, SQL Server 2025 y Always-up-to-date.
    • SQL Server 2025 soporta la replicación a instancias configuradas con las directivas SQL Server 2025 y Always-up-to-date, pero no la SQL Server 2022. No puedes replicar datos ni volver a SQL Server después del cambio si las políticas no coinciden.

Para las versiones y ediciones de SQL Server que admiten vínculos a una sola base de datos, consulte Compatibilidad de versiones de Instancia administrada Link.

Caution

Cada réplica de SQL Server en tu grupo de disponibilidad debe usar la misma versión compatible de SQL Server, tener instalada la actualización acumulativa requerida o posterior, y tener activado el modo de enlace de múltiples bases de datos. No mezcles réplicas que soportan modo enlace de múltiples bases de datos con réplicas de versiones anteriores o con la función desactivada. Mezclar estas configuraciones puede hacer que SQL Server se comporte de forma impredecible.

Prerequisites

Para ampliar tu grupo de disponibilidad entre SQL Server y Azure SQL Managed Instance, necesitas los siguientes requisitos previos:

  • Una suscripción de Azure activa. Si no tiene una, cree una cuenta gratuita.
  • Una versión y edición de SQL Server soportada con la actualización de servicio requerida instalada. Puedes usar un grupo de disponibilidad Always On existente o bases de datos independientes que SSMS coloque en un nuevo grupo de disponibilidad de un solo nodo. No se admiten grupos de disponibilidad contenidos.
  • Azure SQL Managed Instance con una política de actualización adecuada para tu escenario. Se requiere una política de emparejamiento cuando SQL Managed Instance es la primaria inicial o para la inversión de roles. Empieza si no tienes una instancia gestionada por SQL.
  • SQL Server Management Studio (SSMS) 22.10.2 o posterior.
  • Para la configuración guionizada, Azure PowerShell con el módulo Az versión 16.3.0 o posterior y Az.SQL versión 7.1.0 o posterior, o CLI de Azure versión 2.90.0 o posterior. También puede usar Azure Cloud Shell. Verifica que los módulos instalados o la CLI cumplan con estos requisitos de versión.
  • Un entorno preparado correctamente.
  • Para un grupo de disponibilidad de varios nodos, un agente de escucha del grupo de disponibilidad configurado. Utiliza la dirección IP del oyente al configurar el enlace, no la dirección IP de una réplica individual de SQL Server. Usar el agente de escucha permite que el vínculo siga funcionando después de una conmutación por error del grupo de disponibilidad local.
  • No hay enlaces existentes en ninguna réplica de SQL Server cuando activas el modo de enlace de múltiples bases de datos. Antes de empezar, elimina todos los enlaces que usen el antiguo modo de enlace de base de datos única.
  • Capacidad de base de datos y almacenamiento disponibles suficientes en la instancia administrada de destino para todas las bases de datos de su grupo de disponibilidad. Revisa los límites de recursos.

Permissions

Para SQL Server, necesita permisos sysadmin.

Para Azure SQL Managed Instance, debe ser miembro del rol Colaborador de instancia administrada de SQL o tener los siguientes permisos de rol personalizados:

Recurso Microsoft.Sql/ Permisos necesarios
Microsoft.Sql/managedInstances /leer, /escribir
Microsoft.Sql/managedInstances/hybridCertificate /acción
Microsoft.Sql/managedInstances/databases /leer, /eliminar, /escribir, /completarRestauración/acción, /leerRespaldo/acción, /detallesRestauración/leer
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /leer, /escribir, /eliminar, /asignarRol/acción
Microsoft.Sql/managedInstances/endpointCertificates /lectura
Microsoft.Sql/managedInstances/hybridLink /leer, /escribir, /eliminar
Microsoft.Sql/managedInstances/serverTrustCertificates /escribir, /borrar, /leer

El soporte para el modo de enlace de múltiples bases de datos está desactivado por defecto durante la vista previa. Utiliza el procedimiento almacenado integrado sys.sp_multidb_milink para habilitarlo en cada réplica de SQL Server en el grupo de disponibilidad, o en la instancia de SQL Server donde planeas crear un grupo de un solo nodo.

Warning

Elimina todos los enlaces existentes antes de activar o desactivar el modo de enlace de múltiples bases de datos. Cambiar la configuración mientras los enlaces están activos puede resultar en un comportamiento impredecible de SQL Server. No mezcles enlaces de base de datos única y de múltiples bases de datos. Al cambiar de modo, elimina primero los enlaces, cambia la configuración en cada réplica de SQL Server y luego crea nuevos enlaces.

Ejecuta el siguiente comando en cada réplica de SQL Server para habilitar el modo de enlace de múltiples bases de datos:

EXEC sys.sp_multidb_milink 1;

La configuración persiste durante los reinicios de SQL Server, así que solo necesitas activarla una vez en cada réplica.

Para comprobar la configuración, ejecuta el procedimiento almacenado sin un parámetro en cada réplica. Vuelve 1 cuando está habilitado y 0 cuando está desactivado:

EXEC sys.sp_multidb_milink;

Si el procedimiento almacenado no está disponible, verifica que la réplica tenga una versión compatible de SQL Server y una actualización acumulativa instalada.

Para desactivar el modo de enlace de múltiples bases de datos, primero elimina todos los enlaces y luego ejecuta el siguiente comando en cada réplica de SQL Server:

EXEC sys.sp_multidb_milink 0;

Prepara las bases de datos de grupos de disponibilidad

Configura cada base de datos de SQL Server que quieras replicar al modelo de recuperación completo y luego crea una copia de seguridad completa. Tanto las bases de datos existentes de grupos de disponibilidad como las bases de datos independientes requieren esta preparación. Utiliza el procedimiento de copia de seguridad SSMS en la guía de configuración de enlaces.

Caution

Si tus bases de datos utilizan Cifrado de datos transparente (TDE), prepara los certificados o claves de cifrado en el destino antes de crear el enlace. Sin ellos, el enlace no puede replicar las bases de datos cifradas.

Para bases de datos de SQL Server, migra el certificado TDE a SQL Managed Instance. Para bases de datos cifradas de SQL Managed Instance vinculadas a SQL Server, utiliza una clave gestionada por el cliente accesible desde el SQL Server de destino. Revisa la preparación de TDE para el enlace para ver los requisitos en ambos sentidos.

El enlace replica todas las bases de datos del grupo de disponibilidad seleccionado. No puedes elegir un subconjunto, así que comprueba la capacidad disponible de la instancia SQL gestionada de destino antes de crear el enlace. El destino no debe contener bases de datos con los mismos nombres que las bases de datos que quieres replicar. Se permiten bases de datos existentes con diferentes nombres, sujetas a los límites de capacidad de la instancia.

El vínculo solo admite replicar las bases de datos de usuario. No se admite la replicación de bases de datos del sistema. Para replicar objetos de nivel de instancia almacenados en master o msdb, desindíquelos y ejecute scripts de T-SQL en la instancia de destino.

Configurar el oyente y los certificados

Para un grupo de disponibilidad de varios nodos, utiliza la dirección IP del oyente al configurar el enlace, tanto en SSMS como en scripts. El oyente dirige las conexiones a la réplica primaria actual. No uses la dirección IP de una réplica individual de SQL Server como punto final asociado del enlace. Sin el listener, el enlace no sigue funcionando tras un error de grupo de disponibilidad local. Para un grupo de disponibilidad de un solo nodo, incluyendo uno creado por el asistente SSMS para bases de datos independientes, utiliza el punto IP de esa instancia de SQL Server.

El asistente SSMS intercambia certificados entre Azure SQL Managed Instance y solo la réplica principal actual de SQL Server. No configura la confianza de certificados en las otras réplicas de SQL Server. Debes copiar y configurar manualmente los certificados requeridos en cada otra réplica de SQL Server para que el enlace pueda seguir funcionando tras una conmutación por error del grupo de disponibilidad local. Este paso manual se aplica tanto a SSMS como a configuraciones scriptadas. Revisa : Establece confianza entre instancias para los pasos de intercambio de certificados.

Usa SSMS para la experiencia recomendada de configuración. El asistente automatiza muchos pasos de configuración. Si no necesitas automatización por script, salta esta sección y continúa a la pestaña SSMS en Extender el grupo de disponibilidad.

La configuración guionizada es una opción avanzada que requiere experiencia configurando grupos de disponibilidad, endpoints y confianza de certificados. Completa estos pasos solo si usas PowerShell o CLI de Azure con SQL Server como principal inicial.

La lista de verificación cubre tanto grupos de disponibilidad existentes como bases de datos independientes. Después de preparar las bases de datos, el trust y el endpoint, reutiliza tu grupo de disponibilidad existente o crea uno en el paso 4. Luego crea el grupo de disponibilidad distribuida. Los comandos de creación de enlace de PowerShell y CLI de Azure no generan el grupo de disponibilidad para ti.

Para un script adaptado a tu entorno, utiliza el asistente de enlace SSMS y selecciona Script en su página de Resumen . Revisa el script generado y ejecútalo por separado.

  1. Activa el modo de enlace de múltiples bases de datos en cada réplica de SQL Server, o en la instancia independiente de SQL Server, y prepara las bases de datos.
  2. Establecer la confianza entre instancias. Sigue los pasos de creación de certificados, intercambio de claves públicas, importación de certificados raíz y validación de la cadena de certificados. Para un grupo de varios nodos, aplica los requisitos del certificado a cada réplica de SQL Server, no solo a la principal actual.
  3. Proteja el extremo de duplicación de la base de datos. Si tu grupo de disponibilidad ya tiene un endpoint, usa Alterar un endpoint existente en lugar de crear otro. Conserva el puerto final configurado para el comando de creación de enlace.
  4. Prepara el grupo de disponibilidad. Si ya tienes un grupo de disponibilidad que contiene todas las bases de datos que quieres replicar, reutilízalo y sáltate crear un nuevo grupo. Si empiezas con bases de datos independientes, primero crea un grupo de disponibilidad en SQL Server. En la pestaña primaria inicial de SQL Server, use el ejemplo de un solo nodo CREATE AVAILABILITY GROUP con CLUSTER_TYPE = NONE, pero reemplace FOR DATABASE [<DatabaseName>] por la lista completa de la base de datos, como FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Establece <AGNameOnSQLServer> como el nombre que quieres dar al nuevo grupo. Ejecuta este script antes de continuar con la creación de grupos de disponibilidad distribuida. No lo ejecutes contra un grupo existente ni cambies la configuración del clúster de un grupo existente.
  5. Crea el grupo de disponibilidad distribuida en SQL Server. Utiliza la pestaña primaria inicial de SQL Server y comienza en las instrucciones de creación del grupo de disponibilidad distribuida. Configura <AGNameOnSQLServer> en el grupo de disponibilidad que reutilizaste o creaste en el paso anterior. Para un grupo de varios nodos, se utiliza la dirección IP del oyente para <SQLServerIP>. Para un grupo de un solo nodo, utiliza el endpoint de la instancia de SQL Server. Conserva <DAGName> como nombre de enlace y <AGNameOnSQLMI> como nombre del grupo de disponibilidad de instancias gestionadas para el comando de creación que aparece a continuación.
  6. Verifica los grupos de disponibilidad en SQL Server. Confirma que tanto el grupo de disponibilidad Always On como el grupo de disponibilidad distribuida están presentes. Luego vuelve a Extender el grupo de disponibilidad, selecciona PowerShell o CLI de Azure, y ejecuta el comando de creación de múltiples bases de datos en este artículo en lugar del comando de base de datos única de la otra guía.

Ampliar el grupo de disponibilidad

Para conservar los registros del registro de transacciones necesarios para la inicialización, el enfoque recomendado es habilitar la marca de seguimiento 12381 en versiones compatibles de SQL Server antes de crear vínculos, especialmente en bases de datos grandes o cuando haya un gran número de bases de datos en el modo de vínculo de varias bases de datos. Sin embargo, la bandera no es necesaria y existen mitigaciones alternativas, listadas en el error de solución de problemas 1412. Con la bandera activada, las copias de seguridad de los registros pueden continuar, pero los registros de registro retenidos no se pueden reutilizar. Monitoriza el crecimiento de los registros de SQL Server y el espacio libre en disco, y desactiva la bandera tan pronto como termine la siembra de todos los enlaces que se creen.

Usa SSMS para automatizar la creación de enlaces, o elige PowerShell o CLI de Azure para una configuración avanzada con scripts. Los siguientes ejemplos utilizan SQL Server como el principal inicial. También puedes empezar desde SQL Managed Instance con una política de actualización correspondiente, pero ese flujo de trabajo de creación no se cubre aquí.

Para la configuración scripted, completa los pasos de configuración scripted para reutilizar o crear un grupo de disponibilidad que contenga todas las bases de datos que quieras replicar, y luego crea el grupo de disponibilidad distribuido antes de ejecutar el comando de creación de PowerShell o CLI de Azure. Alternativamente, si se inicia con bases de datos independientes, el procedimiento SSMS en esta sección crea automáticamente el grupo de disponibilidad de un solo nodo como parte de la configuración del enlace.

Para el modo de enlace de varias bases de datos, especifique MultiDatabase explícitamente en los scripts e incluya todos los nombres de las bases de datos en el grupo de disponibilidad. PowerShell por defecto pone SingleDatabase si -LinkMode se omite. Úsalo -LinkMode MultiDatabase en PowerShell o --link-mode MultiDatabase en CLI de Azure.

Warning

No cree un vínculo con el modo de vínculo MultiDatabase a menos que cada réplica de SQL Server tenga instalada la actualización acumulativa necesaria y habilitado el modo de vínculo de varias bases de datos mediante el procedimiento almacenado sys.sp_multidb_milink. Usar este modo con compilaciones de SQL Server que no lo soportan puede hacer que SQL Server se comporte de forma impredecible. Revise primero Compatibilidad y Habilitar el modo de vínculo de varias bases de datos.

Utiliza el asistente New SQL Managed Instance link en SSMS para crear un vínculo entre un grupo de disponibilidad existente o bases de datos independientes y Azure SQL Managed Instance.

  1. Abre SSMS y conéctate a SQL Server. Para un grupo de disponibilidad de varios nodos, conéctate a través de la dirección IP del oyente. Para bases de datos independientes o un grupo de un solo nodo, conéctate a la instancia de SQL Server.

  2. En Explorador de objetos, haz clic derecho en una base de datos que quieres replicar, pasa el cursor sobre el enlace de Azure SQL Managed Instance y selecciona Nuevo... para abrir el asistente de enlace New SQL Managed Instance.

    Captura de pantalla del menú contextual de la base de datos en SSMS con el comando New Instancia administrada link seleccionado.

  3. En la página Introduction (Introducción) del asistente, seleccione Next (Siguiente).

  4. En la página Especificar Opciones de Enlace , verifica que el modo de enlace de múltiples bases de datos esté activado y proporciona un nombre para tu enlace. La casilla de verificación del modo es de solo lectura: refleja la configuración sys.sp_multidb_milink de SQL Server. No puedes activar el modo seleccionando la casilla. Si el modo no está activado, revisa la versión de SQL Server y la actualización acumulativa, y activa la función en todas las réplicas antes de continuar. Usa letras minúsculas para el nombre del enlace. Se permiten guiones excepto al principio o al final. Seleccione Siguiente.

    Captura de pantalla de Especificar opciones de enlace mostrando el nombre del enlace y la casilla de verificación activada en modo de solo lectura para múltiples bases de datos.

  5. En la página Requisitos, el asistente valida los requisitos para establecer un vínculo con su secundario. Seleccione Siguiente después de validar todos los requisitos, o resuelva los requisitos que no se cumplen y, a continuación, seleccione Volver a ejecutar validación.

  6. En la página de Seleccionar bases de datos , elige un grupo de disponibilidad existente o bases de datos independientes:

    • Seleccione AG01 para replicar todas sus bases de datos, como DB01, DB03, DB05 y DB07.
    • O selecciona DB10 y DB11 independientes. Con el modo de enlace de múltiples bases de datos activado, SSMS crea un grupo de disponibilidad de un solo nodo en la instancia actual de SQL Server, coloca ambas bases de datos en él y las replica a través de un solo enlace.

    Revisa la selección y luego selecciona Siguiente.

    Captura de pantalla de Bases de Datos Seleccionadas que ofrecen el grupo AG01 existente o bases de datos independientes DB10 y DB11.

  7. En la página Especificar réplica secundaria , selecciona Añadir réplica secundaria. Si la instancia gestionada por SQL es tu secundaria, inicia sesión en Azure y elige la suscripción, el grupo de recursos y la instancia gestionada secundaria de SQL para conectarte a tu instancia.

    Captura de pantalla de Specify Secondary Replica mostrando SQL Server como primario y SQL Managed Instance como secundario.

  8. Revisa la configuración del endpoint y completa los pasos restantes de validación tal como se describe en Configurar enlace con SSMS.

  9. En la página Resumen, revise la configuración una vez más. Opcionalmente, selecciona Script para generar un script. Seleccione Finalizar cuando esté listo para crear el vínculo.

  10. Una vez finalizados todos los pasos, en la página Results (Resultados) se muestran marcas de comprobación junto a las acciones completadas correctamente. Ahora puede cerrar la ventana.

El modo de múltiples bases de datos replica las bases de datos de tu grupo de disponibilidad a través de un solo enlace. Este enfoque difiere de seleccionar múltiples bases de datos en modo de base de datos única, que crea un enlace separado para cada base de datos.

Verificar replicación

Después de crear el enlace o añadir bases de datos, los datos se replican desde la réplica primaria actual hasta la secundaria actual. Tanto SQL Server como Azure SQL Managed Instance pueden ser los principales iniciales. Tras la inversión de roles, los datos se replican en la dirección opuesta. Dependiendo del tamaño de la base de datos y la velocidad de la red, cada base de datos podría estar inicialmente en estado de Restauración en la réplica secundaria. Una vez completada la inicialización, la base de datos se restaura en la réplica secundaria y está lista para cargas de trabajo de solo lectura.

En cualquiera de las réplicas, utiliza Explorador de objetos en SSMS para ver el estado sincronizado de cada base de datos replicada. Expanda Always On High Availability y los Grupos de disponibilidad para mostrar el grupo de disponibilidad distribuida creado para el vínculo.

Cuando SQL Server es el servidor principal, puede seguir realizando copias de seguridad del registro de transacciones durante la inicialización si el indicador de seguimiento 12381 está habilitado en una compilación compatible. Si pausas las copias de seguridad de los registros para evitar truncamientos prematuros, retómalas después de que termine la siembra inicial. Para cada base de datos sin un calendario de copia de seguridad de log, realiza la primera copia de seguridad de log de transacciones solo después de que termine la siembra inicial, no durante la siembra. Una vez que se complete la siembra para todos los enlaces creados, desactiva la bandera si la activaste y haz copias de seguridad de los registros de transacciones de SQL Server regularmente mientras SQL Server siga siendo la principal. Cuando Azure SQL Managed Instance es principal, toma copias de seguridad de los registros de transacciones automáticamente. No es necesario hacer copias de seguridad manuales del registro de transacciones de SQL Server para estas bases de datos mientras SQL Server esté como secundario.

El truncamiento prematuro del registro durante la inicialización puede provocar los errores 1408 y 1412 en el registro de errores de SQL Managed Instance. En las compilaciones que lo admiten, la marca de seguimiento 12381 evita este truncamiento. Desactívalo una vez que termine la siembra de todos los enlaces que se creen, y monitoriza el uso del registro de transacciones, la tasa de crecimiento y el espacio libre en disco mientras esté activado. Las copias de seguridad de los registros pueden continuar mientras se conservan los registros necesarios. Esta retención no sustituye las copias de seguridad periódicas de los registros después de la inicialización. Véase Evitar el truncamiento prematuro del registro.

Agregar bases de datos

Usa el asistente SSMS para añadir bases de datos desde el principal actual, ya sea SQL Server o SQL Managed Instance. El asistente automatiza los cambios necesarios. Para automatización avanzada, usa PowerShell o la CLI de Azure. Añadir una base de datos es una única operación en el lado principal.

Antes de añadir bases de datos, verifica que el enlace existente utilice el modo de enlace de múltiples bases de datos y que el destino tenga suficiente capacidad y almacenamiento disponible en la base de datos, sin nombres de base de datos existentes que entren en conflicto con las nuevas bases de datos. Cuando SQL Server sea el principal, configura cada nueva base de datos que no esté ya en el grupo de disponibilidad al modelo de recuperación completo y crea una copia de seguridad completa usando el procedimiento de copia de seguridad SSMS.

Añadir bases de datos con SSMS

Use el asistente Agregar base de datos al vínculo de Azure SQL Managed Instance para agregar bases de datos a un vínculo existente de varias bases de datos:

  1. Conéctese a la instancia principal actual en SSMS. En Explorador de objetos, expande siempre en grupos de alta disponibilidad y disponibilidad.

  2. Haz clic derecho en el grupo de disponibilidad distribuida de tu enlace, pasa el cursor por el enlace de Azure SQL Managed Instance y selecciona Añadir base de datos....

    Captura de pantalla del menú contextual del grupo de disponibilidad distribuida en SSMS mostrando los comandos Añadir base de datos y Eliminar base de datos.

  3. Continúa por Introducción y Azure Login, y luego selecciona tu enlace de múltiples bases de datos en la página de Seleccionar Enlace.

  4. En la página de Seleccionar bases de datos , selecciona las bases de datos que quieres añadir. Solo puedes añadir bases de datos con un estado Listo . Las bases de datos ya en el enlace se muestran como Ya parte del enlace seleccionado. Resuelve cualquier problema de elegibilidad antes de continuar.

    Captura de pantalla del asistente para añadir base de datos con DB10 y DB11 seleccionados y los miembros existentes del enlace conservados.

  5. Completa Validación y revisa Resumen. Selecciona Finalizar para ejecutar el cambio, o selecciona Script para generar un script sin ejecutar el cambio, así puedes revisarlo, personalizarlo y ejecutarlo por separado. Si ejecutas el cambio en el asistente, revisa los Resultados antes de cerrarlo.

Añadir bases de datos con scripts

Ejecuta la adición en el principal actual. Sigue las instrucciones para esa instancia.

Cuando SQL Server es principal

Utiliza T-SQL para añadir cada base de datos al grupo de disponibilidad. El enlace propaga la adición a SQL Managed Instance. No se necesita ninguna acción adicional en SQL Managed Instance. No ejecutes una actualización de PowerShell o CLI de Azure para esta adición.

Cuando SQL Managed Instance es la principal

Utiliza PowerShell o CLI de Azure para actualizar el enlace en SQL Managed Instance. El enlace propaga automáticamente las bases de datos añadidas al grupo de disponibilidad. No se requiere ningún paso separado en SQL Server. Proporciona la membresía completa prevista, incluyendo todas las bases de datos existentes que quieras conservar y las nuevas bases de datos. La lista proporcionada reemplaza a la membresía actual. Omitir una base de datos la elimina de la membresía del enlace.

Por ejemplo, para añadir DB09 cuando el enlace ya contiene DB01, DB03, DB05, y DB07, conservar esos cuatro nombres en la lista, y también añadir DB09 a la lista. Sustituye los nombres de recursos y bases de datos por tus valores.

Variable de PowerShell variable de la CLI de Azure Descripción
$ResourceGroup ResourceGroupName Grupo de recursos que contiene la instancia gestionada de SQL.
$ManagedInstanceName ManagedInstanceName Nombre de la instancia gestionada por SQL que aloja el enlace.
$DAGName DAGName Nombre del enlace existente, que coincide con el nombre del grupo de disponibilidad distribuida usado durante la creación.
$DatabaseNames DatabaseNames Lista completa de bases de datos existentes para conservar y nuevas bases de datos para añadir. El ejemplo conserva DB07, DB09, DB05 y DB03, y añade DB01.

Usa Update-AzSqlInstanceLink en PowerShell. Reutiliza $ResourceGroup, $ManagedInstanceName, y $DAGName desde la creación, o configúralos al grupo de recursos, instancia y enlace que quieras actualizar:

# Include every existing database to retain and each new database to add.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

Repite los pasos de verificación de replicación para cada base de datos añadida. Sigue los pasos manuales de la copia de seguridad de registros solo cuando SQL Server sea el principal.

Quitar bases de datos

Usa el asistente SSMS en la primaria actual para automatizar la eliminación en ambos lados. Eliminar una base de datos requiere eliminarla del enlace en SQL Managed Instance y del grupo de disponibilidad. Quitarla solo de un lado no completa la operación.

Warning

Si eliminas una base de datos del enlace en SQL Managed Instance pero la dejas en el grupo de disponibilidad, el grupo de disponibilidad se vuelve poco saludable. Eliminación completa en ambos lados. Para la desinstalación mediante script, consulta la sección correspondiente a tu instancia principal actual.

Eliminar bases de datos con SSMS

Los siguientes pasos se aplican tanto si la principal es SQL Server como si lo es SQL Managed Instance:

  1. Conéctese a la instancia principal actual en SSMS. En Explorador de objetos, expande siempre en grupos de alta disponibilidad y disponibilidad.

  2. Haz clic derecho en el grupo de disponibilidad distribuida para el enlace, pasa el cursor sobre el enlace de Azure SQL Managed Instance y selecciona Eliminar base de datos....

    Captura de pantalla del menú del grupo de disponibilidad distribuida con el comando Eliminar base de datos seleccionado.

  3. En el asistente para quitar la base de datos de Azure SQL Managed Instance Link, avanza por Introducción y Inicio de sesión de Azure, y selecciona el vínculo en Seleccionar vínculo.

  4. En Seleccionar Bases de Datos, selecciona las bases de datos que quieres eliminar. Por ejemplo, selecciona DB05 para eliminarlo del enlace y luego selecciona Siguiente.

    Captura de pantalla del asistente para quitar la base de datos, con DB05 seleccionado para quitarlo del vínculo.

  5. Completa la validación, revisa el Resumen y selecciona Terminar para ejecutar la eliminación o Script para revisar primero los comandos generados. Compruebe Resultados para confirmar que la operación se ha completado correctamente antes de cerrar el asistente.

Eliminar bases de datos con scripts

Elimina las bases de datos en ambas instancias. El primario actual determina qué instancia se actualiza primero.

Los ejemplos de PowerShell y CLI de Azure utilizan las siguientes variables:

Variable de PowerShell variable de la CLI de Azure Descripción
$ResourceGroup ResourceGroupName Grupo de recursos que contiene la instancia gestionada de SQL.
$ManagedInstanceName ManagedInstanceName Nombre de la instancia gestionada por SQL que aloja el enlace.
$DAGName DAGName Nombre del enlace existente, que coincide con el nombre del grupo de disponibilidad distribuida usado durante la creación.
$DatabaseNames DatabaseNames Lista completa de bases de datos a conservar, excluyendo aquellas que hay que eliminar. Los ejemplos excluyen DB05 y conservan DB01, DB03, DB07, y DB09.

Cuando SQL Server es principal

  1. Usa T-SQL para eliminar las bases de datos del grupo de disponibilidad.
  2. Utiliza PowerShell o CLI de Azure para eliminar las bases de datos del enlace en SQL Managed Instance, como se muestra en esta sección.

Para el paso de SQL Managed Instance, proporciona la lista completa de bases de datos que debes conservar, omitiendo solo aquellas que quieras eliminar. Por ejemplo, si el enlace contiene DB09, DB05, DB07, DB05 y DB03, el siguiente comando elimina DB01 y conserva los otros cuatro. Sustituye los nombres de recursos y bases de datos por tus valores.

Usa Update-AzSqlInstanceLink. Reutiliza $ResourceGroup, $ManagedInstanceName, y $DAGName desde la creación, o configúralos al grupo de recursos, instancia y enlace que quieras actualizar:

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

Cuando SQL Managed Instance es la principal

  1. Utiliza PowerShell o CLI de Azure para eliminar las bases de datos del enlace en SQL Managed Instance, como se muestra en esta sección.
  2. Utiliza T-SQL en SQL Server para eliminar las bases de datos de su grupo de disponibilidad. La eliminación no está completa hasta que termines este paso.

Para el paso de SQL Managed Instance, proporciona la lista completa de bases de datos que debes conservar, omitiendo solo aquellas que quieras eliminar. Por ejemplo, si el enlace contiene DB09, DB05, DB07, DB05 y DB03, el siguiente comando elimina DB01 y conserva los otros cuatro. Sustituye los nombres de recursos y bases de datos por tus valores.

Usa Update-AzSqlInstanceLink. Reutiliza $ResourceGroup, $ManagedInstanceName, y $DAGName desde la creación, o configúralos al grupo de recursos, instancia y enlace que quieras actualizar:

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

Confirma que las bases de datos eliminadas ya no pertenecen al enlace ni al grupo de disponibilidad. Eliminar una base de datos de la replicación no es lo mismo que borrar su copia conservada. Revisa las bases de datos de ambas instancias antes de decidir si eliminar una copia que ya no necesitas.

Conmutar por error o cambiar a Azure

Utiliza los procedimientos de conmutación por error existentes en SSMS o mediante scripts para intercambiar los roles entre SQL Server y Azure SQL Managed Instance. La inversión de roles requiere que la instancia gestionada de SQL utilice la política de actualización que coincida con tu versión de SQL Server. Para la replicación unidireccional y el cambio a Azure SQL Managed Instance, su política de actualización debe coincidir o ser superior a la versión de tu SQL Server. No puedes replicar datos ni volver a SQL Server después si las políticas no coinciden. Revisa las combinaciones soportadas. Para orientaciones sobre migración y salto, consulta Migrar con el enlace.

Supervisión y solución de problemas de replicación

Utiliza las siguientes vistas de gestión dinámica (DMV) y la vista de catálogo en SQL Server para comprobar el grupo principal de disponibilidad, la conectividad de réplicas y el estado de replicación de cada base de datos:

View Información
sys.availability_groups Grupos de disponibilidad, excluyendo grupos internos de replicación por base de datos.
sys.dm_hadr_availability_replica_states Función, conectividad y salud de sincronización para el grupo principal y los grupos internos de replicación por base de datos.
sys.dm_hadr_database_replica_states Estado de replicación a nivel de base de datos y salud de sincronización.
sys.dm_hadr_internal_availability_groups Grupos internos de replicación creados para bases de datos individuales en modo enlace de múltiples bases de datos.
sys.dm_hadr_internal_availability_replicas Réplicas que pertenecen a los grupos internos de replicación por base de datos en modo de enlace de varias bases de datos. 
SELECT * FROM sys.availability_groups;
SELECT * FROM sys.dm_hadr_availability_replica_states;
SELECT * FROM sys.dm_hadr_database_replica_states;
SELECT * FROM sys.dm_hadr_internal_availability_groups;
SELECT * FROM sys.dm_hadr_internal_availability_replicas;

Si las DMV internas de replicación no están disponibles, o si al ejecutar el procedimiento almacenado sys.sp_multidb_milink se indica que no está disponible, verifica la versión instalada de SQL Server y la actualización acumulativa de esa réplica. Para problemas generales de conectividad y replicación, véase Troubleshoot the Instancia administrada link.

Limitations

Considera las siguientes limitaciones al extender un grupo de disponibilidad a través de un enlace de múltiples bases de datos:

  • Los nombres de los enlaces deben usar letras minúsculas. Se permiten guiones, pero un nombre no puede empezar ni terminar con un guion.
  • No degradas ninguna réplica de SQL Server por debajo de SQL Server 2022 CU27 o de SQL Server 2025 CU9, según corresponda, mientras haya un enlace en modo de múltiples bases de datos activo. Degradar por debajo de la CU mínima requerida puede causar problemas impredecibles incluso sin una conmutación por error.
  • No se admiten grupos de disponibilidad contenidos.
  • Los enlaces de una sola base de datos y los enlaces de múltiples bases de datos no pueden coexistir en la misma instancia de SQL Server.
  • No puedes cambiar directamente el modo de un enlace. Para cambiar entre modos de enlace de base de datos única y múltiples bases de datos, elimina todos los enlaces existentes, cambia el modo en cada réplica de SQL Server y luego recrea los enlaces en el nuevo modo.
  • Cuando creas un enlace para un grupo de disponibilidad existente, todas las bases de datos de ese grupo deben replicarse. No puedes seleccionar solo un subconjunto de las bases de datos de ese grupo.
  • La capacidad restante de la base de datos en la instancia SQL gestionada de destino limita el número de bases de datos que puedes replicar. General Purpose y Business Critical soporta hasta 100 bases de datos por instancia, y la General Purpose de próxima generación soporta hasta 500. Las bases de datos existentes se contabilizan para estos límites. Por ejemplo, una instancia con un límite de 100 bases de datos y 10 bases de datos existentes tiene capacidad para 90 bases de datos adicionales. Para más información, consulte límites de recursos.
  • Agregar bases de datos al grupo de disponibilidad superando la capacidad disponible para bases de datos de la instancia administrada de SQL de destino puede realizarse correctamente en SQL Server, pero la replicación a SQL Managed Instance falla. Esta condición puede dejar el enlace en un estado inconsistente que requiere la eliminación manual de las bases de datos no replicadas del grupo de disponibilidad.
  • Añadir bases de datos se propaga a través del enlace, pero eliminar una base de datos en un lado no la elimina automáticamente en el otro. Si eliminas una base de datos del grupo de disponibilidad, su copia permanece en SQL Managed Instance. Si eliminas una base de datos del enlace en SQL Managed Instance, la base de datos permanece en el grupo de disponibilidad sin replicación a través del enlace y requiere limpieza manual.
  • Al añadir bases de datos a un enlace existente a través de SSMS, solo puedes añadir bases de datos con estado Listo . No puedes añadir bases de datos que pertenezcan a otro grupo de disponibilidad o que tengan un nombre que ya exista en el destino.

Contenido relacionado

  • Last updated on