Estender um grupo de disponibilidade Always On para Azure SQL Managed Instance (pré-visualização)

Aplica-se a: Azure SQL Managed Instance

Este artigo ensina-lhe como expandir um grupo de disponibilidade Always On com múltiplas bases de dados entre SQL Server e Azure SQL Managed Instance com a ligação Managed Instance, utilizando SQL Server Management Studio (SSMS), PowerShell ou CLI do Azure.

Este artigo aborda o modo de ligação de múltiplas bases de dados, que replica todas as bases de dados num grupo de disponibilidade através de uma única ligação. O modo de ligação de base de dados única replica uma base de dados por ligação.

Overview

Quando se estende um grupo de disponibilidade Always On entre o SQL Server e o Azure SQL Managed Instance, cria-se um link que replica múltiplas bases de dados num grupo de disponibilidade para a réplica alvo. A ligação utiliza um grupo de disponibilidade distribuída para replicar alterações quase em tempo real desde a réplica primária atual para cópias de base de dados de apenas leitura na réplica secundária. Isto garante que as cópias só de leitura no secundário se mantêm atualizadas em relação ao primário.

Pode usar um grupo de disponibilidade existente ou começar com bases de dados autónomas. Quando seleciona bases de dados autónomas no SSMS, o assistente cria um grupo de disponibilidade de nó único no nó primário inicial e replica as bases de dados selecionadas através de uma única ligação.

Tanto o SQL Server como o Azure SQL Managed Instance podem ser os primários iniciais. Criar a ligação a partir do SQL Managed Instance requer o SQL Server 2022 ou SQL Server 2025 com a atualização cumulativa necessária e uma política de atualização do SQL Managed Instance correspondente. Os exemplos de criação neste artigo começam no SQL Server. Não explicam passo a passo como criar o SQL Managed Instance. É suportado o failover com inversão de papéis entre SQL Server e Azure SQL Managed Instance para instâncias configuradas com políticas de atualização correspondentes.

Supportability

Os seguintes requisitos aplicam-se à extensão de um grupo de disponibilidade através de uma ligação de múltiplas bases de dados durante a pré-visualização. O SQL Server em Windows e Linux é suportado. Deve instalar a atualização cumulativa () necessária. As versões anteriores não suportam esta funcionalidade.

Considere o seguinte:

• A edição standard não é suportada porque os grupos de disponibilidade básica suportam apenas uma base de dados.
• O SQL Server 2019 e versões anteriores não são suportados para o modo de ligação de múltiplas bases de dados porque não têm a tecnologia necessária introduzida no SQL Server 2022.
• Para criar a ligação a partir da Instância Gerida de SQL ou inverter os papéis novamente para o SQL Server, a sua Instância Gerida de SQL deve usar a política de atualização que corresponda à sua versão do SQL Server. Para replicação unidirecional e transferência a partir do SQL Server, a política de atualização de destino deve corresponder ou ser superior à da 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. Não podes replicar dados nem regressar ao SQL Server após a transição se as políticas não coincidirem.

Para versões e edições do SQL Server que suportam ligações de base de dados única, consulte Suporte de versões para a ligação do Managed Instance.

Pré-requisitos

Para expandir o seu grupo de disponibilidade entre o SQL Server e o Azure SQL Managed Instance, precisa dos seguintes pré-requisitos:

• Uma assinatura ativa do Azure. Se ainda não tiver uma, crie uma conta gratuita.
• Uma versão e edição do SQL Server suportadas com a atualização de serviço necessária instalada. Pode usar um grupo de disponibilidade Always On existente ou bases de dados autónomas que o SSMS coloca num novo grupo de disponibilidade de nó único. Os grupos de disponibilidade contidos não são suportados.
• Azure SQL Managed Instance com uma política de atualização adequada ao seu cenário. É necessária uma política de correspondência quando a SQL Managed Instance é a primária inicial ou para inversão de papéis. Começa se não tiveres uma instância gerida em SQL.
• SQL Server Management Studio (SSMS) 22.10.2 ou 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 cumprem estes requisitos de versão.
• Um ambiente devidamente 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 a ligação, e não o endereço IP de uma réplica individual do SQL Server. Usar o ouvinte permite que a ligação continue a funcionar após um failover de grupo de disponibilidade local.
• Não há ligações existentes em nenhuma réplica do SQL Server quando ativas o modo de ligação de múltiplas bases de dados. Antes de começar, remova todos os links que usam o antigo modo de ligação de base de dados única.
• Capacidade e armazenamento de base de dados disponíveis suficientes na instância gerida alvo para todas as bases de dados do seu grupo de disponibilidade. Consulte os limites de recursos.

Permissions

Para SQL Server, precisas de permissões sysadmin.

Para Azure SQL Managed Instance, precisa de ser membro da função Contribuidor de Instância Gerida SQL ou ter as seguintes permissões de função personalizadas:

Ativar o modo de ligação de múltiplas bases de dados

O suporte para o modo de ligação de múltiplas bases de dados está desativado por defeito durante a pré-visualização. Use o procedimento armazenado incorporado sys.sp_multidb_milink para o ativar em todas as réplicas do SQL Server no grupo de disponibilidade, ou na instância do SQL Server onde planeia criar um grupo de nó único.

Execute o seguinte comando em cada réplica do SQL Server para ativar o modo de ligação de múltiplas bases de dados:

EXEC sys.sp_multidb_milink 1;

A configuração mantém-se ao longo dos reinicios do SQL Server, por isso só precisa de a ativar uma vez em cada réplica.

Para verificar a definiçã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 tem uma versão suportada do SQL Server e uma atualização cumulativa instaladas.

Para desativar o modo de ligação de múltiplas bases de dados, remova primeiro todas as ligações e depois execute o seguinte comando em cada réplica do SQL Server:

EXEC sys.sp_multidb_milink 0;

Preparar as bases de dados dos grupos de disponibilidade

Define cada base de dados SQL Server que queres replicar com o modelo de recuperação completo e depois cria um backup completo. Tanto as bases de dados existentes dos grupos de disponibilidade como as bases de dados autónomas requerem esta preparação. Use o procedimento de backup SSMS no guia de configuração do link.

Para bases de dados SQL Server, migre o certificado TDE para SQL Managed Instance. Para bases de dados SQL Managed Instance encriptadas ligadas ao SQL Server, utilize uma chave gerida pelo cliente acessível ao SQL Server de destino. Reveja a preparação do TDE para a ligação relativamente aos requisitos em cada direção.

A ligação replica todas as bases de dados do grupo de disponibilidade selecionado. Não podes escolher um subconjunto, por isso verifica a capacidade disponível da instância gerida SQL de destino antes de criares o link. O destino não deve conter bases de dados com os mesmos nomes das bases de dados que pretende replicar. Bases de dados existentes com nomes diferentes são permitidas, sujeitas 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 replicação de bancos de dados do sistema. Para replicar objetos ao nível da instância armazenados em master ou msdb, crie scripts deles e execute os scripts T-SQL na instância de destino.

Configurar o ouvinte e os certificados

Para um grupo de disponibilidade com múltiplos nós, use o endereço IP do ouvinte ao configurar a ligação, tanto em SSMS como em scripts. O ouvinte direciona as ligaçõ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 terminal parceiro do link. Sem o ouvinte, o link não continua a funcionar após um failover do grupo de disponibilidade local. Para um grupo de disponibilidade de nó único, incluindo um criado pelo assistente do SSMS para bases de dados independentes, use o ponto final IP dessa instância do SQL Server.

O assistente SSMS troca certificados entre a Azure SQL Managed Instance e apenas a réplica principal atual do SQL Server. Não configura a confiança de certificados nas outras réplicas do SQL Server. Deve copiar e configurar manualmente os certificados necessários em todas as outras réplicas do SQL Server para que a ligação possa continuar a funcionar após um failover de grupo de disponibilidade local. Este passo manual aplica-se tanto ao SSMS como à configuração por script. Revise : Estabeleça confiança entre as instâncias para as etapas de troca de certificados.

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

Usa o SSMS para a experiência de configuração recomendada. O assistente automatiza muitos passos de configuração. Se não precisares de automação scriptada, salta esta secção e continua para o separador SSMS em Estender o grupo de disponibilidade.

A configuração por script é uma opção avançada que requer experiência na configuração de grupos de disponibilidade, endpoints e confiança nos certificados. Complete estes passos apenas se estiver a usar PowerShell ou CLI do Azure com o SQL Server como principal inicial.

A lista de verificação abrange tanto grupos de disponibilidade existentes como bases de dados autónomas. Depois de preparar as bases de dados, o trust e o endpoint, reutilize o seu grupo de disponibilidade existente ou crie um no passo 4. Depois cria o grupo de disponibilidade distribuída. Os comandos de criação de links do PowerShell e do CLI do Azure não criam o grupo de disponibilidade para ti.

Para um script adaptado ao seu ambiente, use o assistente de ligação SSMS e selecione Script na sua página de Resumo . Revê o script gerado e executa-o separadamente.

1. Ative o modo de ligação de múltiplas bases de dados em cada réplica do SQL Server, ou na instância autónoma do SQL Server, e prepare as bases de dados.
2. Estabeleça 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 de certificado a todas as réplicas do SQL Server, não apenas à principal atual.
3. Proteja o endpoint de espelhamento da base de dados. Se o seu grupo de disponibilidade já tiver um endpoint, use Alterar um endpoint existente em vez de criar outro. Manter a porta endpoint configurada para o comando de criação de ligação.
4. Prepara o grupo de disponibilidade. Se já tens um grupo de disponibilidade contendo todas as bases de dados que queres replicar, reutiliza-o e evita criar um novo grupo. Se começares com bases de dados autónomas, primeiro cria um grupo de disponibilidade no SQL Server. No separador primário inicial do SQL Server, use o exemplo de CREATE AVAILABILITY GROUP nó único com CLUSTER_TYPE = NONE, mas substitua FOR DATABASE [<DatabaseName>] pela lista completa da base de dados, como FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Define <AGNameOnSQLServer> o nome que queres 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 já existente nem altere a configuração do cluster de um grupo existente.
5. Crie o grupo de disponibilidade distribuída no SQL Server. Use o separador primário 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 reutilizou ou criou na etapa anterior. Para um grupo com vários nós, utilize o endereço IP do listener para <SQLServerIP>. Para um grupo de um único nó, utilize o endpoint da instância do SQL Server. Mantenha <DAGName> como nome da ligação e <AGNameOnSQLMI> como nome do grupo de disponibilidade da instância gerida para o comando de criação abaixo.
6. Verifica os grupos de disponibilidade no SQL Server. Confirme que tanto o grupo de disponibilidade Always On como o grupo de disponibilidade distribuída estão presentes. Depois, volte a Estender o grupo de disponibilidade, selecione PowerShell ou CLI do Azure, e execute o comando de criação de múltiplas bases de dados neste artigo em vez do comando de base de dados única do outro guia.

Estender o grupo de disponibilidade

Para reter os registos de transações necessários para a propagação inicial, a abordagem recomendada é ativar o sinalizador de rastreio 12381 nas versões suportadas do SQL Server antes de criar ligações, especialmente para bases de dados de grande dimensão ou para muitas bases de dados no modo de ligação de várias bases de dados. No entanto, o sinalizador não é obrigatório e existem mitigações alternativas, indicadas em Resolver problemas do erro 1412. Com a opção ativada, as cópias de segurança do registo de transações podem continuar, mas os registos de transações retidos não ficam disponíveis para reutilização. Monitorize o crescimento do registo de transações do SQL Server e o espaço livre em disco, e desative o sinalizador assim que a propagação inicial terminar em todas as ligações que estão a ser criadas.

Use SSMS para automatizar a criação de links, ou escolha PowerShell ou CLI do Azure para configuração avançada de scripts. Os exemplos seguintes usam o SQL Server como principal inicial. Também podes começar pelo SQL Managed Instance com uma política de atualização correspondente, mas esse fluxo de trabalho de criação não é abordado aqui.

Para a configuração por script, conclua os passos da configuração por script para reutilizar ou criar um grupo de disponibilidade que contenha todas as bases de dados que pretende replicar e, em seguida, crie o grupo de disponibilidade distribuído antes de executar o comando de criação no PowerShell ou na CLI do Azure. Em alternativa, se começar com bases de dados autónomas, o procedimento no SSMS nesta secção cria automaticamente o grupo de disponibilidade de nó único como parte da configuração da ligação.

Para o modo de ligação de múltiplas bases de dados, especifique MultiDatabase explicitamente nos scripts e forneça todos os nomes das bases de dados no grupo de disponibilidade. O PowerShell utiliza SingleDatabase por predefinição se -LinkMode for 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 bases de dados, os dados replicam-se da réplica primária atual para a réplica secundária atual. Tanto o SQL Server como o Azure SQL Managed Instance podem ser os primários iniciais. Após a inversão de papéis, os dados replicam-se na direção oposta. Dependendo do tamanho da base de dados e da velocidade da rede, cada base de dados pode inicialmente estar num estado de Restauração na réplica secundária. Após a conclusão do seeding inicial, o banco de dados é restaurado na réplica secundária e está pronto para cargas de trabalho de leitura apenas.

Em qualquer uma das réplicas, use o Object Explorer no SSMS para visualizar o estado sincronizado de cada base de dados replicada. Expanda os Grupos de Disponibilidade Sempre Ativa e Disponibilidade para visualizar o grupo de disponibilidade distribuído criado para a ligação.

Quando o SQL Server é o primário, pode continuar a efetuar cópias de segurança do registo de transações durante a propagação inicial se o sinalizador de rastreio 12381 estiver ativado numa compilação suportada. Se pausar as cópias de segurança dos registos para evitar a truncação prematura, retome-as após a propagação inicial terminar. Para cada base de dados sem um agendamento de cópia de segurança do registo, efetue a primeira cópia de segurança do registo de transações apenas após a conclusão da propagação inicial, não durante a propagação. Depois de concluída a propagação inicial para todas as ligações que estão a ser criadas, desative o sinalizador, se o tiver ativado, e efetue cópias de segurança regulares dos registos de transações do SQL Server enquanto o SQL Server se mantiver como primário. Quando o Azure SQL Managed Instance é o principal, faz backups dos registos de transações automaticamente. Não precisas de fazer backups manuais do log do SQL Server para estas bases de dados, enquanto o SQL Server é secundário.

O truncamento prematuro do log durante a seed pode causar os erros 1408 e 1412 no registo de erros do SQL Managed Instance. Nas compilações que o suportem, o sinalizador de rastreio 12381 impede esta truncagem. Desative-o assim que a propagação inicial estiver concluída para todas as ligações que estão a ser criadas e monitorize a utilização do registo de transações, a taxa de crescimento e o espaço livre em disco enquanto estiver ativado. As cópias de segurança dos registos podem continuar enquanto os registos necessários permanecem mantidos. Esta retenção não substitui os backups regulares dos registos após a sementeira. Veja Evitar o truncamento prematuro do log.

Adicionar bases de dados

Usa o assistente SSMS para adicionar bases de dados do principal atual, seja SQL Server ou SQL Managed Instance. O assistente automatiza as alterações necessárias. Para automação avançada, use o PowerShell ou a CLI do Azure. Adicionar uma base de dados é uma única operação do lado primário.

Antes de adicionar bases de dados, verifique se a ligação existente utiliza o modo de ligação de múltiplas bases de dados e que o destino tem capacidade e armazenamento suficientes disponíveis, sem nomes de bases de dados existentes que entrem em conflito com as novas bases de dados. Quando o SQL Server for principal, defina cada nova base de dados que não esteja no grupo de disponibilidade para o modelo de recuperação completo e crie um backup completo usando o procedimento de backup SSMS.

Adicionar bases de dados com SSMS

Utilize o assistente Add Database to Azure SQL Managed Instance Link para adicionar bases de dados a uma ligação existente de múltiplas bases de dados:

1. Ligue-se ao primário atual no SSMS. No Object Explorer, expanda Always On High Availability e Grupos de Disponibilidade.

2. Clique com o botão direito no grupo de disponibilidade distribuída para o seu link, passe o rato sobre o link Azure SQL Managed Instance e selecione Adicionar Base de Dados....

   

3. Prossiga pela Introdução e pelo Login do Azure, e depois selecione o seu link de múltiplas bases de dados na página de Selecionar Link.

4. Na página Selecionar Bases de Dados , selecione as bases de dados que pretende adicionar. Só podes adicionar bases de dados com um estado Pronto . As bases de dados já presentes no link são mostradas como Já parte do link selecionado. Resolva quaisquer questões de elegibilidade antes de continuar.

   

5. Conclua a Validação e reveja o Resumo. Selecione Terminar para executar a alteração, ou selecione Script para gerar um script sem executar a alteração, para que possa rever, personalizar e executar separadamente. Se executares a alteração no assistente, revê os resultados antes de o fechar.

Adicionar bases de dados com scripts

Execute a operação de adição na primária atual. Segue as instruções nessa situação.

Quando o SQL Server é o principal

Use o T-SQL para adicionar cada base de dados ao grupo de disponibilidade. A ligação propaga a adição ao SQL Managed Instance. Não é necessária mais nenhuma ação no SQL Managed Instance. Não execute uma atualização do PowerShell ou do CLI do Azure para esta adição.

Quando o SQL Managed Instance é o principal

Use PowerShell ou CLI do Azure para atualizar o link no SQL Managed Instance. A ligação propaga automaticamente as bases de dados adicionadas para o grupo de disponibilidade. Não é necessário nenhum passo separado no SQL Server. Forneça a adesão completa pretendida, incluindo todas as bases de dados existentes que pretende manter e as novas bases de dados. A lista fornecida substitui os membros atuais. Omitir uma base de dados remove-a da pertença ao link.

Por exemplo, para adicionar DB09 quando o link já contém DB01, DB03, DB05, e DB07, manter esses quatro nomes na lista, e também adicionar DB09 à lista. Substitui os nomes dos recursos e da base de dados pelos teus 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 os passos de verificação de replicação para cada nova base de dados adicionada. Siga os passos manuais de cópia de segurança dos registos apenas quando o SQL Server for o servidor principal.

Remover bases de dados

Utilize o assistente do SSMS no servidor principal atual para automatizar a remoção em ambos os lados. Remover uma base de dados requer removê-la do link na SQL Managed Instance e do grupo de disponibilidade. Removê-lo apenas de um lado não completa a operação.

Remover bases de dados com SSMS

Os passos seguintes aplicam-se quer o SQL Server ou o SQL Managed Instance seja o principal:

1. Ligue-se ao primário atual no SSMS. No Object Explorer, expanda Always On High Availability e Grupos de Disponibilidade.

2. Clique com o botão direito do rato no grupo de disponibilidade distribuída da ligação, paire sobre ligação do Azure SQL Managed Instance e selecione Remover base de dados....

   

3. No assistente Remover Base de Dados do Azure SQL Managed Instance Link, prossiga pelo Introduction e pelo Azure Login, e selecione o link em Select Link.

4. Em Selecionar Bases de Dados, selecione as bases de dados a remover. Por exemplo, selecione DB05 para removê-lo do link e depois selecione Próximo.

   

5. Completar a Validação, rever o Resumo e selecionar Terminar para executar a remoção ou Script para rever primeiro os comandos gerados. Verifique os resultados para conclusão bem-sucedida antes de fechar o assistente.

Remover bases de dados com scripts

Remova as bases de dados em ambas as instâncias. A instância primária atual determina qual é a primeira instância a atualizar.

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

Quando o SQL Server é o principal

1. Utilize T-SQL para remover as bases de dados do grupo de disponibilidade.
2. Use PowerShell ou CLI do Azure para remover as bases de dados do link no SQL Managed Instance, como mostrado nesta secção.

Para o passo SQL Managed Instance, forneça a lista completa de bases de dados a manter, omitindo apenas aquelas que pretende remover. Por exemplo, se a ligação contiver DB09, DB05, DB07, DB05 e DB03, o comando seguinte remove DB01 e mantém os outros quatro. Substitui os nomes dos recursos e da base de dados pelos teus 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 o SQL Managed Instance é o principal

1. Use PowerShell ou CLI do Azure para remover as bases de dados do link no SQL Managed Instance, como mostrado nesta secção.
2. Use o T-SQL no SQL Server para remover as bases de dados do seu grupo de disponibilidade. A remoção só está completa quando terminares esta etapa.

Para o passo SQL Managed Instance, forneça a lista completa de bases de dados a manter, omitindo apenas aquelas que pretende remover. Por exemplo, se a ligação contiver DB09, DB05, DB07, DB05 e DB03, o comando seguinte remove DB01 e mantém os outros quatro. Substitui os nomes dos recursos e da base de dados pelos teus 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 as bases de dados removidas já não pertencem ao link ou ao grupo de disponibilidade. Remover uma base de dados da replicação não é o mesmo que apagar a sua cópia retida. Revise as bases de dados de ambas as instâncias antes de decidir se deve eliminar uma cópia que já não precisa.

Faça failover ou passe para o Azure

Utilize os procedimentos de failover existentes em SSMS ou scripts para inverter os papéis entre o SQL Server e o Azure SQL Managed Instance. A inversão de papéis exige que a instância gerida SQL use a política de atualização que corresponde à sua versão do SQL Server. Para replicação unidirecional e transição para Azure SQL Managed Instance, a sua política de atualização deve corresponder ou ser superior à da sua versão do SQL Server. Não podes replicar dados nem voltar ao SQL Server depois se as políticas não coincidirem. Revê 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

Utilize as seguintes vistas de gestão dinâmica (DMVs) e a visualização de catálogo no SQL Server para verificar o grupo principal de disponibilidade, a conectividade das réplicas e o estado de replicação de cada base 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 indicar que este não está disponível, verifique a versão instalada do SQL Server e a atualização cumulativa dessa réplica. Para resolução geral de problemas de conectividade e replicação, veja Troubleshoot the Managed Instance link.

Limitations

Considere as seguintes limitações ao estender um grupo de disponibilidade através de uma ligação de múltiplas bases de dados:

• Os nomes dos links devem usar letras minúsculas. Hífens são permitidos, mas um nome não pode começar nem 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 estiver ativa uma ligação no modo de várias bases de dados. Fazer downgrade abaixo do exigido pode causar problemas imprevisíveis mesmo sem failover.
• Os grupos de disponibilidade contidos não são suportados.
• Ligações de base de dados única e de múltiplas bases de dados não podem coexistir na mesma instância do SQL Server.
• Não podes alterar diretamente o modo de uma ligação. Para alternar entre modos de ligação de base de dados única e múltiplas bases de dados, remover todas as ligações existentes, alterar o modo em cada réplica do SQL Server e depois recriar as ligações no novo modo.
• Quando crias um link para um grupo de disponibilidade existente, todas as bases de dados desse grupo têm de ser replicadas. Não podes selecionar apenas um subconjunto das bases de dados desse grupo.
• A capacidade restante da base de dados na instância SQL gerida de destino limita o número de bases de dados que pode replicar. O General Purpose e Business Critical suporta até 100 bases de dados por instância, e o General Purpose de próxima geração suporta até 500. As bases de dados existentes contam para estes limites. Por exemplo, uma instância com um limite de 100 bases de dados e 10 bases de dados existentes tem capacidade para mais 90 bases de dados. Para mais informações, consulte limites de recursos.
• Adicionar bases de dados ao grupo de disponibilidade para além da capacidade de base de dados disponível da SQL managed instance de destino pode ter sucesso no SQL Server, mas a replicação para a SQL Managed Instance falha. Esta condição pode deixar a ligação num estado inconsistente que exige a remoção manual das bases de dados não replicadas do grupo de disponibilidade.
• Adicionar bases de dados propaga-se através do link, mas remover uma base de dados de um lado não a remove automaticamente do outro lado. Se remover uma base de dados do grupo de disponibilidade, a sua cópia permanece no SQL Managed Instance. Se remover uma base de dados do link no SQL Managed Instance, a base de dados permanece no grupo de disponibilidade sem replicação através do link e requer limpeza manual.
• Ao adicionar bases de dados a uma ligação existente através do SSMS, só pode adicionar bases de dados com um estado Pronto . Não podes adicionar bases 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
• Preparar o ambiente para a ligação
• Configurar link com o SSMS
• Práticas recomendadas para manter o link
• Solucionar problemas com o link