Estenda um grupo de disponibilidade Always On para Instância Gerenciada de SQL do Azure (prévia)

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo ensina como expandir um grupo de disponibilidade Always On com múltiplos bancos de dados entre SQL Server e Instância Gerenciada de SQL do Azure com o link Instância Gerenciada usando SQL Server Management Studio (SSMS), PowerShell ou CLI do Azure.

Este artigo aborda o modo de link de múltiplos bancos de dados, que replica todos os bancos de dados em um grupo de disponibilidade por meio de um único link. O modo de link de banco de dados único replica um banco de dados por link.

Visão geral

Quando você estende um grupo de disponibilidade Always On entre SQL Server e Instância Gerenciada de SQL do Azure, cria um link que replica múltiplos bancos de dados em um grupo de disponibilidade para a réplica alvo. O link utiliza um grupo de disponibilidade distribuído para replicar alterações em tempo quase real da réplica primária atual para cópias de banco de dados somente leitura na réplica secundária. Isso garante que as cópias somente de leitura no secundário permaneçam atualizadas em relação ao primário.

Você pode usar um grupo de disponibilidade existente ou começar com bancos de dados independentes. Quando você seleciona bancos de dados independentes no SSMS, o assistente cria um grupo de disponibilidade de nó único no primário inicial e replica os bancos de dados selecionados usando um link.

Tanto o SQL Server quanto o Instância Gerenciada de SQL do Azure podem ser os primários iniciais. Criar o link a partir do Instância Gerenciada de SQL requer o SQL Server 2022 ou SQL Server 2025 com a atualização cumulativa necessária e uma política de atualização do Instância Gerenciada de SQL correspondente. Os exemplos de criação neste artigo começam no SQL Server. Eles não orientam você no processo de criação a partir da Instância Gerenciada de SQL. O failover com reversão de função entre o SQL Server e o Instância Gerenciada de SQL do Azure tem suporte para instâncias configuradas com políticas de atualização correspondentes.

Suportabilidade

Os requisitos a seguir se aplicam para estender um grupo de disponibilidade por meio de um link de múltiplos bancos de dados durante a versão prévia. SQL Server tanto no Windows quanto no Linux é suportado. Você deve instalar a atualização cumulativa () necessária. Versões anteriores não suportam esse recurso.

Considere o seguinte:

• A edição padrão não é suportada porque grupos de disponibilidade básica suportam apenas um banco de dados.
• O SQL Server 2019 e versões anteriores não são suportados para o modo de ligação de múltiplos bancos de dados porque não possuem a tecnologia necessária introduzida no SQL Server 2022.
• Para criar o link a partir da Instância Gerenciada de SQL ou reverter as funções de volta para o SQL Server, sua Instância Gerenciada de SQL deve usar a política de atualização que corresponde à sua versão do SQL Server. Para replicação unidirecional e transferência do SQL Server, a política de atualização de destino deve corresponder, ou ser superior à sua versão do SQL Server.
  • SQL Server 2022 suporta replicação para instâncias configuradas com as políticas SQL Server 2022, SQL Server 2025 e Always-up-to-date.
  • SQL Server 2025 suporta replicação para instâncias configuradas com as políticas SQL Server 2025 e Always-up-to-date, mas não SQL Server 2022. Você não poderá replicar dados ou voltar para o SQL Server após a substituição se as políticas não coincidirem.

Para versões e edições do SQL Server que suportam links de banco de dados único, veja Suporte à versão de links Instância Gerenciada.

Pré-requisitos

Para estender seu grupo de disponibilidade entre SQL Server e Instância Gerenciada de SQL do Azure, você precisa dos seguintes pré-requisitos:

• Uma assinatura de Azure ativa. Crie uma conta gratuita se ainda não tiver a sua.
• Uma versão e edição do SQL Server suportadas com a atualização de serviço necessária instalada. Você pode usar um grupo de disponibilidade Always On existente ou bancos de dados autônomos que o SSMS insere em um novo grupo de disponibilidade de nó único. Grupos de disponibilidade contida não são suportados.
• Instância Gerenciada de SQL do Azure com uma política de atualização apropriada para o seu cenário. Uma política de correspondência é necessária quando a Instância Gerenciada de SQL é a primária inicial ou para inversão de papéis. Comece se você não tem uma instância gerenciada em SQL.
• SQL Server Management Studio (SSMS) 22.10.2 ou versão posterior.
• Para configuração scriptada, Azure PowerShell com o módulo Az versão 16.3.0 ou posterior e Az.SQL versão 7.1.0 ou posterior, ou CLI do Azure versão 2.90.0 ou posterior. Você também pode usar o Azure Cloud Shell. Verifique se os módulos instalados ou a CLI atendem a esses requisitos de versão.
• Um ambiente adequadamente preparado.
• Para um grupo de disponibilidade com múltiplos nós, um ouvinte de grupo de disponibilidade configurado. Use o endereço IP do ouvinte ao configurar o link, não o endereço IP de uma réplica individual do SQL Server. O uso do listener permite que a conexão continue funcionando após um failover do grupo de disponibilidade local.
• Não há links existentes em nenhuma réplica do SQL Server quando você ativa o modo de link de múltiplos bancos de dados. Antes de começar, remova todos os links que usam o modo antigo de link de banco de dados único.
• Capacidade suficiente disponível de banco de dados e armazenamento na instância gerenciada alvo para todos os bancos de dados do seu grupo de disponibilidade. Revise os limites de recursos.

Permissions

Para SQL Server, você precisa de permissões sysadmin.

Para a Instância Gerenciada de SQL do Azure, você precisa ser membro da função colaborador da Instância Gerenciada de SQL ou ter as seguintes permissões de função personalizadas:

Ativar o modo de vinculação entre vários bancos de dados

O suporte ao modo de ligação de múltiplos bancos de dados é desativado por padrão durante a prévia. Use o procedimento armazenado sys.sp_multidb_milink interno para habilitá-lo em todas as réplicas do SQL Server no grupo de disponibilidade ou na instância do SQL Server em que você pretende criar um grupo de nó único.

Execute o seguinte comando em cada réplica do SQL Server para habilitar o modo de link de múltiplos bancos de dados:

EXEC sys.sp_multidb_milink 1;

A configuração persiste durante as reinicializações do SQL Server, então você só precisa habilitá-la uma vez em cada réplica.

Para verificar a configuração, execute o procedimento armazenado sem um parâmetro em cada réplica. Ele retorna 1 quando ativado e 0 quando desativado:

EXEC sys.sp_multidb_milink;

Se o procedimento armazenado não estiver disponível, verifique se a réplica possui uma versão suportada do SQL Server e uma atualização cumulativa instaladas.

Para desabilitar o modo de link de múltiplos bancos de dados, primeiro remova todos os links e depois execute o seguinte comando em cada réplica do SQL Server:

EXEC sys.sp_multidb_milink 0;

Preparar os bancos de dados dos grupos de disponibilidade

Defina cada banco de dados do SQL Server que você deseja replicar para o modelo de recuperação completo e então crie um backup completo. Tanto os bancos de dados existentes de grupos de disponibilidade quanto os bancos de dados independentes exigem essa preparação. Use o procedimento de backup SSMS no guia de configuração do link.

Para bancos de dados SQL Server, migre o certificado TDE para o Instância Gerenciada de SQL. Para bancos de dados criptografados Instância Gerenciada de SQL vinculados ao SQL Server, use uma chave gerenciada pelo cliente acessível ao SQL Server de destino. Examine Preparo do TDE para o link para verificar os requisitos em cada direção.

O link replica todos os bancos de dados do grupo de disponibilidade selecionado. Você não pode escolher um subconjunto, então verifique a capacidade disponível da instância gerenciada SQL de destino antes de criar o link. O destino não deve conter bancos de dados com os mesmos nomes dos bancos de dados que você deseja replicar. Bancos de dados existentes com nomes diferentes são permitidos, sujeitos aos limites de capacidade da instância.

O link suporta apenas a replicação de bancos de dados de usuários. Não há suporte para a replicação de bancos de dados do sistema. Para replicar objetos de nível de instância armazenados em master ou msdb, faça os scripts deles e execute scripts o T-SQL scripts na instância de destino.

Configure o ouvinte e os certificados

Para um grupo de disponibilidade com múltiplos nós, use o endereço IP do ouvinte ao configurar o link, tanto no SSMS quanto em scripts. O ouvinte direciona as conexões para a réplica primária atual. Não use o endereço IP de uma réplica individual do SQL Server como ponto final parceiro do link. Sem o ouvinte, o link deixa de funcionar após um failover do grupo de disponibilidade local. Para um grupo de disponibilidade de nó único, incluindo um criado pelo assistente SSMS para bancos de dados independentes, use o endpoint IP dessa instância do SQL Server.

O assistente SSMS troca certificados entre o Instância Gerenciada de SQL do Azure e apenas a réplica principal atual do SQL Server. Ele não configura a confiança de certificados nas outras réplicas do SQL Server. Você deve copiar e configurar manualmente os certificados necessários em todas as outras réplicas do SQL Server para que o link possa continuar funcionando após um failover do grupo de disponibilidade local. Essa etapa manual se aplica tanto ao SSMS quanto à configuração por script. Consulte Estabelecer confiança entre instâncias para ver as etapas de troca de certificados.

Prepare-se para a criação de links scriptados

Use o SSMS para a experiência recomendada de configuração. O assistente automatiza muitas etapas de configuração. Se você não precisar de automação scriptada, pule esta seção e continue para a aba SSMS em Estender o grupo de disponibilidade.

A configuração scriptada é uma opção avançada que exige experiência configurando grupos de disponibilidade, endpoints e confiança de certificados. Complete essas etapas apenas se você estiver usando PowerShell ou CLI do Azure com o SQL Server como principal inicial.

A lista de verificação abrange tanto grupos de disponibilidade existentes quanto bancos de dados independentes. Depois de preparar os bancos de dados, o trust e o endpoint, reutilize seu grupo de disponibilidade existente ou crie um no passo 4. Depois, crie o grupo de disponibilidade distribuída. Os comandos de criação de link do PowerShell e do CLI do Azure não criam o grupo de disponibilidade para você.

Para um script adaptado ao seu ambiente, use o assistente de link SSMS e selecione Script na página de Resumo . Revise o script gerado e execute-o separadamente.

1. Ative o modo de link de múltiplos bancos de dados em cada réplica do SQL Server, ou na instância independente do SQL Server, e prepare os bancos de dados.
2. Estabelecer confiança entre instâncias. Siga os passos de criação de certificados, troca de chaves públicas, importação de certificados raiz e validação da cadeia de certificados. Para um grupo de múltiplos nós, aplique os requisitos do certificado a cada réplica do SQL Server, não apenas à primária atual.
3. Proteja o endpoint de espelhamento do banco de dados. Se seu grupo de disponibilidade já tiver um endpoint, use Alterar um endpoint existente em vez de criar outro. Mantenha a porta endpoint configurada para o comando de criação de link.
4. Prepare o grupo de disponibilidade. Se você já tem um grupo de disponibilidade contendo todos os bancos de dados que quer replicar, reutilize-o e pule a criação de um novo grupo. Se você começar com bancos de dados independentes, primeiro crie um grupo de disponibilidade no SQL Server. Na aba primária inicial do SQL Server, use o exemplo de nó CREATE AVAILABILITY GROUP único com CLUSTER_TYPE = NONE, mas substitua FOR DATABASE [<DatabaseName>] pela lista completa do banco de dados, como FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Defina <AGNameOnSQLServer> o nome que você quer dar ao novo grupo. Execute este script antes de continuar para a criação do grupo de disponibilidade distribuída. Não o execute contra um grupo existente nem mude a configuração do cluster de um grupo existente.
5. Crie o grupo de disponibilidade distribuída no SQL Server. Use a aba primária inicial do SQL Server e comece pelas instruções de criação do grupo de disponibilidade distribuída. Defina <AGNameOnSQLServer> para o grupo de disponibilidade que você reutilizou ou criou na etapa anterior. Para um grupo com vários nós, use o endereço IP do listener para <SQLServerIP>. Para um grupo de nó único, use o endpoint da instância do SQL Server. Mantenha <DAGName> como seu nome de link e <AGNameOnSQLMI> como nome do grupo de disponibilidade de instâncias gerenciadas para o comando de criação abaixo.
6. Verifique os grupos de disponibilidade no SQL Server. Confirme que tanto o grupo de disponibilidade Always On quanto o grupo de disponibilidade distribuída estão presentes. Depois, retorne ao Estender o grupo de disponibilidade, selecione PowerShell ou CLI do Azure, e execute o comando de criação de múltiplos bancos de dados neste artigo em vez do comando de banco de dados único do outro guia.

Estenda o grupo de disponibilidade

Para manter os registros de log necessários para a propagação inicial, a abordagem recomendada é ativar o sinalizador de rastreamento 12381 em compilações com suporte do SQL Server antes de criar vínculos, especialmente para bancos de dados grandes ou para muitos bancos de dados no modo de vínculo de vários bancos de dados. No entanto, o sinalizador não é obrigatório, e há mitigações alternativas, listadas em Solucionar o erro 1412. Com a flag ativada, backups de log podem continuar, mas registros de log retidos não são reutilizáveis. Monitore o crescimento do log do SQL Server e o espaço livre em disco, e desative o sinalizador assim que a propagação terminar para todos os links que estiverem sendo criados.

Use o SSMS para automatizar a criação de links, ou escolha PowerShell ou CLI do Azure para configuração avançada de scripts. Os exemplos a seguir usam o SQL Server como o primário inicial. Você também pode começar pelo Instância Gerenciada de SQL com uma política de atualização correspondente, mas esse fluxo de criação não é abordado aqui.

Para a configuração por script, conclua as etapas de configuração por script para reutilizar ou criar um grupo de disponibilidade que contenha todos os bancos de dados que você deseja replicar e, em seguida, crie o grupo de disponibilidade distribuído antes de executar o comando de criação do PowerShell ou da CLI do Azure. Alternativamente, se você começar com bancos de dados independentes, o procedimento SSMS nesta seção cria automaticamente o grupo de disponibilidade de nó único como parte da configuração do link.

Para o modo de vínculo com vários bancos de dados, especifique MultiDatabase explicitamente nos scripts e informe todos os nomes dos bancos de dados no grupo de disponibilidade. O PowerShell usa SingleDatabase por padrão quando -LinkMode é omitido. Use -LinkMode MultiDatabase no PowerShell ou --link-mode MultiDatabase no CLI do Azure.

Update-Module -Name Az
Update-Module -Name Az.Sql

Get-InstalledModule -Name Az | Select-Object Name, Version
Get-InstalledModule -Name Az.Sql | Select-Object Name, Version

# Run in Azure Cloud Shell and select PowerShell.
$ManagedInstanceName = "<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
$DAGName = "<DAGName>"

# Enter the availability group names from the setup steps.
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Include every database in the availability group.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07")

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
$SQLEndpointIP = "<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
$EndpointPort = "<EndpointPort>"

$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
$SQLPartnerEndpoint = "TCP://" + $SQLEndpointIP + ":" + $EndpointPort

# Create the multi-database link with SQL Managed Instance as the secondary.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI -Database $DatabaseNames -PartnerEndpoint $SQLPartnerEndpoint -InstanceLinkRole "Secondary" -FailoverMode "Manual" -SeedingMode "Automatic" -LinkMode "MultiDatabase"

# Run in Azure Cloud Shell and select Bash.
ResourceGroupName="<ResourceGroupName>"
ManagedInstanceName="<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
DAGName="<DAGName>"

# Enter the availability group names from the setup steps.
AGNameOnSQLServer="<AGNameOnSQLServer>"
AGNameOnSQLMI="<AGNameOnSQLMI>"

# Include every database in the availability group.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07}]"

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
SQLEndpointIP="<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
EndpointPort="<EndpointPort>"

SQLPartnerEndpoint="TCP://${SQLEndpointIP}:${EndpointPort}"

# Create the multi-database link with SQL Managed Instance as the secondary.
az sql mi link create --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --partner-availability-group-name "$AGNameOnSQLServer" --instance-availability-group-name "$AGNameOnSQLMI" --databases "$DatabaseNames" --partner-endpoint "$SQLPartnerEndpoint" --instance-link-role Secondary --failover-mode Manual --seeding-mode Automatic --link-mode MultiDatabase

Verificar replicação

Depois de criar o link ou adicionar bancos de dados, os dados se replicam da réplica primária atual para a secundária atual. Tanto o SQL Server quanto o Instância Gerenciada de SQL do Azure podem ser os primários iniciais. Após a inversão de papéis, os dados se replicam na direção oposta. Dependendo do tamanho do banco de dados e da velocidade da rede, cada banco pode inicialmente estar em estado de Restauração na réplica secundária. Após concluir a propagação inicial, o banco de dados será restaurado para a réplica secundária e estará pronto para cargas de trabalho de somente leitura.

Em qualquer uma das réplicas, use Pesquisador de Objetos no SSMS para verificar o estado Synchronized de cada banco de dados replicado. Expandir Alta disponibilidade Always On e Grupos de Disponibilidade para exibir o grupo de disponibilidade distribuído que é criado para o link.

Quando o SQL Server atua como primário, você pode continuar a executar backups do log de transações durante a propagação inicial se o sinalizador de rastreamento 12381 estiver ativado em uma versão com suporte. Se você pausar backups de log para evitar truncamento prematuro, retome-os após a propagação inicial ser concluída. Para cada banco de dados sem um agendamento de backup de log, execute o primeiro backup de log de transações somente após a conclusão da propagação inicial, não durante a propagação. Após a conclusão da propagação para todos os links que estão sendo criados, desative o sinalizador, se você o tiver ativado, e faça backups regulares do log de transações do SQL Server enquanto o SQL Server permanecer primário. Quando o Instância Gerenciada de SQL do Azure é primário, ele faz backups de logs de transações automaticamente. Você não precisa fazer backups manuais de log do SQL Server para esses bancos de dados, enquanto o SQL Server é secundário.

O truncamento prematuro do log durante a propagação inicial pode causar os erros 1408 e 1412 no registro de erros da Instância Gerenciada de SQL. Em compilações que oferecem suporte a isso, o sinalizador de rastreamento 12381 impede essa truncação. Desative-o assim que a propagação inicial for concluída para todos os links que estão sendo criados e monitore o uso do log de transações, a taxa de crescimento e o espaço livre em disco enquanto ele estiver habilitado. Backups de logs podem continuar enquanto os registros necessários permanecem retidos. Essa retenção não substitui backups de log regulares após a propagação. Veja Prevenir o truncamento prematuro do log.

Adicionar bancos de dados

Use o assistente do SSMS para adicionar bancos de dados da instância primária atual, seja ela o SQL Server ou a Instância Gerenciada de SQL. O mago automatiza as mudanças necessárias. Para automação avançada, use PowerShell ou a CLI do Azure. Adicionar um banco de dados é uma única operação do lado primário.

Antes de adicionar bancos de dados, verifique se o link existente utiliza o modo de link de múltiplos bancos de dados e se o destino possui capacidade e armazenamento suficientes disponíveis, sem nomes de banco de dados existentes que conflitem com os novos bancos de dados. Quando o SQL Server for primário, defina cada novo banco de dados que não esteja no grupo de disponibilidade para o modelo completo de recuperação e crie um backup completo usando o procedimento de backup SSMS.

Adicionar bancos de dados com SSMS

Use o assistente Adicionar Banco de Dados ao Link da Instância Gerenciada de SQL do Azure para adicionar bancos de dados a um link existente de vários bancos de dados:

1. Conecte-se ao primário atual no SSMS. No Pesquisador de Objetos, expanda sempre em grupos de alta disponibilidade e disponibilidade.

2. Clique com o botão direito no grupo de disponibilidade distribuída do seu link, passe o mouse sobre o link Instância Gerenciada de SQL do Azure e selecione Adicionar Banco de Dados....

   

3. Prossiga pela Introdução e pelo login do Azure, e então selecione seu link de múltiplos bancos de dados na página Selecionar Link.

4. Na página Selecionar Bancos de Dados , selecione os bancos de dados que deseja adicionar. Você só pode adicionar bancos de dados com um estado Pronto . Bancos de dados já no link são mostrados como Já parte do link selecionado. Resolva quaisquer questões de elegibilidade antes de continuar.

   

5. Conclua Validação e revise Resumo. Selecione Finalizar para executar a mudança, ou selecione Script para gerar um script sem executar a alteração, assim você pode revisar, personalizar e rodar separadamente. Se você executar a alteração no assistente, analise os Resultados antes de fechá-lo.

Adicionar bancos de dados com scripts

Execute a operação de adição na instância primária atual. Siga as instruções para essa situação.

Quando o SQL Server é principal

Use o T-SQL para adicionar cada banco de dados ao grupo de disponibilidade. O link propaga a adição ao Instância Gerenciada de SQL. Não é necessária nenhuma ação adicional no Instância Gerenciada de SQL. Não execute uma atualização do PowerShell ou CLI do Azure para essa adição.

Quando a Instância Gerenciada de SQL é a principal

Use PowerShell ou CLI do Azure para atualizar o link no Instância Gerenciada de SQL. O link propaga automaticamente os bancos de dados adicionados para o grupo de disponibilidade. Não é necessário um passo separado no SQL Server. Forneça a composição completa pretendida, incluindo todos os bancos de dados existentes que você deseja manter e os novos bancos de dados. A lista fornecida substitui a atual membresia. Omitir um banco de dados remove ele da membresia do link.

Por exemplo, para adicionar DB09 quando o link já contém DB01, DB03, DB05, , e DB07, mantêm esses quatro nomes na lista, e também adicionam DB09 à lista. Substitua os nomes dos recursos e do banco de dados pelos seus valores.

# 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

# Include every existing database to retain and each new database to add.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Repita as etapas de verificação de replicação para cada banco de dados recém-adicionado. Siga as etapas de backup manual do log apenas quando o SQL Server for o servidor principal.

Remover bancos de dados

Use o assistente do SSMS no primário atual para automatizar a remoção em ambos os lados. Remover um banco de dados exige removê-lo do link no Instância Gerenciada de SQL e do grupo de disponibilidade. Removê-lo de apenas um lado não conclui a operação.

Remover bancos de dados com SSMS

Os seguintes passos se aplicam se o SQL Server ou o Instância Gerenciada de SQL são os principais:

1. Conecte-se ao primário atual no SSMS. No Pesquisador de Objetos, expanda sempre em grupos de alta disponibilidade e disponibilidade.

2. Clique com o botão direito do mouse no grupo de disponibilidade distribuída do link, aponte para Link da Instância Gerenciada de SQL do Azure e selecione Remover Banco de Dados....

   

3. No assistente Remover Banco de Dados do Link da Instância Gerenciada de SQL do Azure, prossiga por Introdução e Logon do Azure e selecione o link em Selecionar Link.

4. Em Select Databases, selecione os bancos de dados a serem removidos. Por exemplo, selecione DB05 para removê-lo do link e depois selecione Próximo.

   

5. Conclua Validação, revise Resumo e selecione Terminar para executar a remoção ou Script para revisar primeiro os comandos gerados. Verifique Resultados para verificar se a conclusão foi bem-sucedida antes de fechar o assistente.

Remover bancos de dados com scripts

Remova os bancos de dados em ambas as instâncias. O primário atual determina qual instância deve ser atualizada primeiro.

Os exemplos do PowerShell e do CLI do Azure usam as seguintes variáveis:

Quando o SQL Server é principal

1. Use o T-SQL para remover os bancos de dados do grupo de disponibilidade.
2. Use PowerShell ou CLI do Azure para remover os bancos de dados do link no Instância Gerenciada de SQL, como mostrado nesta seção.

Para a etapa Instância Gerenciada de SQL, forneça a lista completa de bancos de dados a serem mantidos, omitindo apenas aqueles que você deseja remover. Por exemplo, se o link inclui DB09, DB05, DB07, DB05 e DB03, o comando a seguir remove DB01 e mantém os outros quatro. Substitua os nomes dos recursos e do banco de dados pelos seus valores.

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

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

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Quando a Instância Gerenciada de SQL é a principal

1. Use PowerShell ou CLI do Azure para remover os bancos de dados do link no Instância Gerenciada de SQL, como mostrado nesta seção.
2. Use o T-SQL no SQL Server para remover os bancos de dados do grupo de disponibilidade. A remoção só está completa quando você concluir essa etapa.

Para a etapa Instância Gerenciada de SQL, forneça a lista completa de bancos de dados a serem mantidos, omitindo apenas aqueles que você deseja remover. Por exemplo, se o link contém DB09, DB05, DB07, DB05 e DB03, o comando a seguir remove DB01 e mantém os outros quatro. Substitua os nomes dos recursos e do banco de dados pelos seus valores.

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

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

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Confirme que os bancos de dados removidos não pertencem mais ao link ou ao grupo de disponibilidade. Remover um banco de dados da replicação não é o mesmo que deletar sua cópia retida. Revise os bancos de dados em ambas as instâncias antes de decidir se vai deletar uma cópia que você não precisa mais.

Faça failover ou substituição para o Azure

Use os procedimentos de failover existentes no SSMS ou em scripts para reverter as funções entre o SQL Server e a Instância Gerenciada de SQL do Azure. A inversão de papéis exige que a instância gerenciada em SQL use a política de atualização que corresponde à sua versão do SQL Server. Para replicação unidirecional e transição para Instância Gerenciada de SQL do Azure, sua política de atualização deve ser igual ou superior à sua versão do SQL Server. Você não poderá replicar dados ou fazer failback para o SQL Server depois se as políticas não coincidirem. Revise as combinações suportadas. Para orientações sobre migração e transição, veja Migrar com o link.

Monitorar e solucionar problemas de replicação

Use as seguintes vistas de gerenciamento dinâmico (DMVs) e a visualização de catálogo no SQL Server para verificar o grupo principal de disponibilidade, a conectividade das réplicas e a saúde da replicação de cada banco de dados:

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;

Se os DMVs internos de replicação não estiverem disponíveis, ou se a execução do procedimento armazenado sys.sp_multidb_milink informar que ele não está disponível, verifique a versão instalada do SQL Server e a atualização cumulativa nessa réplica. Para conectividade geral e solução de problemas de replicação, veja Troubleshoot the Instância Gerenciada link.

Limitations

Considere as seguintes limitações ao estender um grupo de disponibilidade por meio de um link de múltiplos bancos de dados:

• Os nomes dos links devem usar letras minúsculas. Hifens são permitidos, mas um nome não pode começar ou terminar com hífen.
• Não faça downgrade de nenhuma réplica do SQL Server para uma versão anterior ao SQL Server 2022 CU27 ou ao SQL Server 2025 CU9, conforme aplicável, enquanto um link no modo de vários bancos de dados estiver ativo. Fazer downgrade para uma versão abaixo da CU necessária pode causar problemas imprevisíveis mesmo sem failover.
• Grupos de disponibilidade contida não são suportados.
• Links de banco de dados único e links de múltiplos bancos de dados não podem coexistir na mesma instância do SQL Server.
• Você não pode alterar o modo de um link diretamente. Para alternar entre modos de link de banco de dados único e múltiplos bancos de dados, remova todos os links existentes, mude o modo em cada réplica do SQL Server e então recrie os links no novo modo.
• Quando você cria um link para um grupo de disponibilidade existente, todos os bancos de dados desse grupo precisam ser replicados. Você não pode selecionar apenas um subconjunto dos bancos de dados desse grupo.
• A capacidade restante do banco de dados na instância SQL gerenciada de destino limita o número de bancos de dados que você pode replicar. O Propósito Geral e Crítico de Negócios suporta até 100 bancos de dados por instância, e o Propósito Geral de Próxima Geração suporta até 500. Bancos de dados existentes contam para esses limites. Por exemplo, uma instância com limite de 100 bancos de dados e 10 bancos de dados existentes tem capacidade para 90 bancos de dados adicionais. Para mais informações, veja limites de recursos.
• Adicionar bancos de dados ao grupo de disponibilidade além da capacidade disponível do banco de dados da SQL managed instance de destino pode ter sucesso no SQL Server, mas a replicação para o Instância Gerenciada de SQL falha. Essa condição pode deixar o link em um estado inconsistente que exige a remoção manual dos bancos de dados não replicados do grupo de disponibilidade.
• Adicionar bancos de dados é propagado pelo link, mas remover um banco de dados de um lado não o remove automaticamente do outro lado. Se você remover um banco de dados do grupo de disponibilidade, sua cópia permanece na Instância Gerenciada de SQL. Se você remover um banco de dados do link na Instância Gerenciada de SQL, o banco de dados permanece no grupo de disponibilidade sem replicação pelo link e precisa de limpeza manual.
• Ao adicionar bancos de dados a um link existente via SSMS, você só pode adicionar bancos de dados com estado Ready . Você não pode adicionar bancos de dados que pertençam a outro grupo de disponibilidade ou que tenham um nome que já exista no destino.

Conteúdo relacionado

• Visão geral do link de Instância Gerenciada
• Prepare seu ambiente para o link
• Configurar link com o SSMS
• Práticas recomendadas para manter o link
• Solucionar problemas com o link