Compartilhar via

Configure um link com scripts - Instância Gerenciada de SQL do Azure

  • Artigo

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

Este artigo ensina como configurar um link entre o SQL Server e a Instância Gerenciada de SQL do Azure com scripts Transact-SQL e PowerShell ou CLI do Azure. Com o link, os bancos de dados da primária inicial são replicados para a réplica secundária quase em tempo real.

Depois que o link for criado, é possível fazer failover para a réplica secundária para fins de migração ou recuperação de desastre.

Observação

Visão geral

Use o recurso de link para replicar bancos de dados da primária inicial para a réplica secundária. Para o SQL Server 2022, a primária inicial pode ser o SQL Server ou a Instância Gerenciada de SQL do Azure. Para o SQL Server 2019 e versões anteriores, a primária inicial deve ser o SQL Server. Depois que o link é configurado, os bancos de dados do primário inicial são replicados para a réplica secundária.

É possível optar por deixar o link no lugar para replicação contínua de dados em um ambiente híbrido entre a réplica primária e secundária, ou fazer o failover do banco de dados para a réplica secundária, para migrar para o Azure ou para recuperação de desastre. Para o SQL Server 2019 e versões anteriores, fazer failover para a Instância Gerenciada de SQL do Azure quebra o link. Assim, a operação de failback não tem suporte. Com o SQL Server 2022, você tem a opção de manter o link e alternar entre as duas réplicas.

Se planejar utilizar a instância gerenciada secundária apenas para recuperação de desastre, é possível economizar em custos de licenciamento ativando o benefício de failover híbrido.

Utilize as instruções neste artigo para configurar manualmente o link entre o SQL Server e a Instância Gerenciada de SQL do Azure. Após a criação do link, o banco de dados de origem recebe uma cópia somente leitura na réplica secundária de destino.

Dica

Para simplificar o uso de scripts T-SQL com os parâmetros corretos para seu ambiente, é altamente recomendável usar o assistente de link Instância Gerenciada no SSMS (SQL Server Management Studio) para gerar um script para criar o link. Na página Resumo da janela Novo link Instância Gerenciada, selecione Script em vez de Concluir.

Pré-requisitos

Para replicar seus bancos de dados, você precisa dos seguintes pré-requisitos:

Considere o seguinte:

  • O recurso de link suporta um banco de dados por link. Para replicar bancos de dados múltiplos em uma instância, crie um link para cada banco de dados individual. Por exemplo, para replicar 10 bancos de dados para a Instância Gerenciada SQL, crie 10 links individuais.
  • O agrupamento entre o SQL Server e a Instância Gerenciada do SQL deve ser o mesmo. Uma incompatibilidade no agrupamento pode causar uma incompatibilidade na caixa de nome do servidor e impedir uma conexão bem-sucedida do SQL Server com a Instância Gerenciada de SQL.
  • O erro 1475 no SQL Server primário inicial indica que é necessário iniciar uma nova cadeia de backup, criando um backup completo sem a COPY ONLY opção.
  • Para estabelecer um link, ou failover, da Instância Gerenciada de SQL para o SQL Server 2022, sua instância gerenciada deve ser configurada com a política de atualização do SQL Server 2022. Não há suporte para a duplicação de dados e para o failover da Instância Gerenciada de SQL para o SQL Server 2022 por parte de instâncias configuradas com a política de atualizações Sempre atualizado.
  • Embora você possa estabelecer um link do SQL Server 2022 para uma instância gerenciada de SQL configurada com a política de atualização Sempre atualizado, após o failover para a Instância Gerenciada de SQL, você não poderá mais replicar dados nem fazer failback para o SQL Server 2022.

Permissões

No SQL Server, você deve ter permissões sysadmin.

Na Instância Gerenciada de SQL do Azure, você deve ser membro do Colaborador de Instância Gerenciada de SQL ou ter as seguintes permissões para uma função personalizada:

Recurso Microsoft.Sql/ Permissões necessárias
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Terminologia e convenções de nomenclatura

À medida que você executa scripts deste guia do usuário, é importante não confundir nomes de SQL Server e Instância Gerenciada SQL com seus nomes de domínio totalmente qualificados (FQDNs). A tabela a seguir explica o que os vários nomes representam exatamente e como obter seus valores:

Terminologia Descrição Como descobrir
Primário inicial 1 O SQL Server ou a Instância Gerenciada de SQL em que você cria inicialmente o link para replicar o banco de dados para a réplica secundária.
Réplica primária O SQL Server ou a Instância Gerenciada de SQL que atualmente hospeda o banco de dados primário.
Réplica secundária O SQL Server ou a Instância Gerenciada de SQL que está recebendo dados replicados quase em tempo real da réplica primária atual.
Nome do SQL Server Nome curto com uma só palavra do SQL Server. Por exemplo: sqlserver1 . Executar SELECT @@SERVERNAME do T-SQL.
FQDN do SQL Server FQDN (nome de domínio totalmente qualificado) do SQL Server. Por exemplo: "sqlserver1.domain.com". Consulte sua configuração de rede (DNS) local ou o nome do servidor se estiver usando uma máquina virtual (VM) do Azure.
Nome da Instância Gerenciada de SQL Nome curto com uma só palavra da Instância Gerenciada de SQL. Por exemplo: "managedinstance1". Confira o nome da sua instância gerenciada no portal do Azure.
FQDN da Instância Gerenciada de SQL FQDN (nome de domínio totalmente qualificado) da Instância Gerenciada de SQL. Por exemplo: "managedinstance1.6d710bcf372b.database.windows.net". Consulte o nome do anfitrião na página de visão geral da Instância Gerenciada de SQL no portal do Azure.
Nome de domínio resolvível Nome DNS que pode ser resolvido para um endereço IP. Por exemplo, a execução de nslookup sqlserver1.domain.com retorna um endereço IP, como 10.0.0.1. Execute o comando nslookup no prompt de comando.
IP do SQL Server Endereço IP do SQL Server. No caso de vários IPs no SQL Server, escolha um endereço IP que possa ser acessado no Azure. Execute o comando ipconfig no prompt de comando do sistema operacional host que executa o SQL Server.

1 A configuração da Instância Gerenciada do Azure SQL como sua instância primária inicial tem suporte a partir do SQL Server 2022 CU10.

Configurar recuperação e backup de banco de dados

Se o SQL Server for o seu primário inicial, os bancos de dados que serão replicados por meio do link devem estar no modelo de recuperação completa e ter pelo menos um backup. Como a Instância Gerenciada de SQL do Azure faz backups de forma automática, é possível ignorar esta etapa se a Instância Gerenciada de SQL for a primária inicial.

Execute o código a seguir no SQL Server para todos os bancos de dados que você deseja replicar. Substitua <DatabaseName> pelo nome atual do banco de dados.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Para saber mais, confira Criar um backup completo de banco de dados.

Observação

O link dá suporte apenas à replicação de bancos de dados de usuário. Não há suporte para a replicação de bancos de dados do sistema. Para replicar objetos em nível de instância (armazenados em bancos de dados master ou msdb), recomendamos que você faça o script deles e execute scripts T-SQL na instância de destino.

Estabelecer confiança entre instâncias

Primeiro, é necessário estabelecer confiança entre as duas instâncias e garantir a segurança dos pontos de extremidade usados para comunicar e criptografar dados pela rede. Os grupos de disponibilidade distribuídos usam o ponto de extremidade de espelhamento de banco de dados do grupo de disponibilidade existente, em vez de ter um ponto de extremidade dedicado próprio. Como tal, a segurança e a confiança precisam ser configuradas entre as duas instâncias por meio do ponto de extremidade de espelhamento de banco de dados do grupo de disponibilidade.

Observação

O link é baseado na tecnologia do grupo de disponibilidade Always On. O ponto de extremidade de espelhamento de banco de dados é um ponto de extremidade com finalidade especial usado exclusivamente pelo grupo de disponibilidade para receber conexões de outras instâncias. O termo "ponto de extremidade de espelhamento de banco de dados" não deve ser confundido com o recurso herdado de espelhamento de banco de dados do SQL Server.

A confiança baseada em certificado é a única maneira suportada para proteger pontos de extremidade de espelhamento de banco de dados para o SQL Server e na Instância Gerenciada do SQL. Se você tiver grupos de disponibilidade existentes que usam autenticação do Windows, você precisará adicionar a confiança baseada em certificado ao ponto de extremidade de espelhamento existente como uma opção de autenticação secundária. Faça isso usando a instrução ALTER ENDPOINT, conforme mostrado mais adiante neste artigo.

Importante

Os certificados são gerados com data e hora de expiração. Eles precisam ser renovados e girados antes da validade.

A seguir, esta é a visão geral do processo para proteger os pontos de extremidade de espelhamento de banco de dados para SQL Server e Instância Gerenciada de SQL:

  1. Gere um certificado no SQL Server e obtenha sua chave pública.
  2. Obtenha a chave pública do certificado da Instância Gerenciada do SQL.
  3. Troque as chaves públicas entre o SQL Server e a Instância Gerenciada de SQL.
  4. Importar chaves de autoridade de certificado raiz confiável do Azure para o SQL Server

As seções a seguir descrevem essas etapas com detalhes.

Crie um certificado no SQL Server e importe sua chave pública para a Instância Gerenciada

Primeiro, crie a chave mestra do banco de dados no banco de dados master, se ela ainda não estiver presente. Insira sua senha no lugar de <strong_password> no script a seguir e guarde-a em um lugar confidencial e seguro. Execute este script T-SQL no SQL Server:

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

Em seguida, gere um certificado de autenticação no SQL Server. No script a seguir, substitua:

  • @cert_expiry_date pela data de validade do certificado desejada (data futura).

Registre essa data e defina um lembrete para girar (atualizar) o certificado do SQL Server antes da expiração para garantir a operação contínua do link.

Importante

É altamente recomendável usar o nome do certificado gerado automaticamente por meio desse script. Embora a personalização do seu nome de certificado no SQL Server seja permitida, o nome não deve conter nenhum caractere \.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

Em seguida, use a seguinte consulta T-SQL no SQL Server para verificar se o certificado foi criado:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Nos resultados da consulta, você verá que o certificado foi criptografado com a chave mestra.

Agora você pode obter a chave pública do certificado gerado no SQL Server:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Salve os valores de SQLServerCertName e de SQLServerPublicKey na saída, porque você precisará deles na próxima etapa ao importar o certificado.

Primeiro, verifique se você está conectado ao Azure e se selecionou a assinatura em que a instância gerenciada está hospedada. A seleção da assinatura correta é especialmente importante se você tem mais de uma assinatura do Azure na conta.

Substitua <SubscriptionID> por sua ID da assinatura do Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Em seguida, use o comando New-AzSqlInstanceServerTrustCertificate do PowerShell ou o comando az sql mi partner-cert create do CLI do Azure para fazer o upload da chave pública do certificado de autenticação do SQL Server para o Azure, como o exemplo de PowerShell a seguir.

Preencha as informações necessárias do usuário, copie-as, cole-as e execute o script. Substitua:

  • <SQLServerPublicKey> pela parte pública do certificado do SQL Server em formato binário, que você registrou na etapa anterior. É um valor de cadeia longo que começa com 0x.
  • <SQLServerCertName> pelo nome do certificado do SQL Server que você registrou na etapa anterior.
  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

O resultado dessa operação é um resumo do certificado do SQL Server carregado no Azure.

Se precisar ver todos os certificados do SQL Server carregados para uma instância gerenciada, use o comando Get-AzSqlInstanceServerTrustCertificate do PowerShell ou o comando az sql mi partner-cert list da CLI do Azure no Azure Cloud Shell. Para remover um certificado do SQL Server carregado em uma instância gerenciada, use o comando Remove-AzSqlInstanceServerTrustCertificate do PowerShell ou o comando az sql mi partner-cert delete da CLI do Azure no Azure Cloud Shell.

Obtenha a chave pública do certificado da Instância Gerenciada do SQL e importe-a para o SQL Server

O certificado para proteger o ponto de extremidade do link é gerado automaticamente na Instância Gerenciada de SQL do Azure. Obtenha a chave pública do certificado da Instância Gerenciada de SQL e importe-a para o SQL Server usando o comando Get-AzSqlInstanceEndpointCertificate do PowerShell ou o comando az sql mi endpoint-cert show da CLI do Azure, como no exemplo de PowerShell a seguir.

Cuidado

Ao usar a CLI do Azure, você precisará adicionar manualmente 0x à frente da saída PublicKey ao usá-la nas etapas subsequentes. Por exemplo, a PublicKey será semelhante a "0x3082033E30...".

Execute o seguinte script. Substitua:

  • <SubscriptionID> com sua ID de assinatura do Azure.
  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

Copie toda a saída de PublicKey (começa com 0x), pois você precisará dela na próxima etapa.

Como alternativa, se você encontrar problemas ao copiar e colar a PublicKey, execute também o comando EXEC sp_get_endpoint_certificate 4 T-SQL na instância gerenciada para obter a chave pública para o ponto de extremidade do link.

Em seguida, importe a chave pública obtida do certificado de segurança da instância gerenciada para o SQL Server. Execute a consulta a seguir no SQL Server para criar o certificado de ponto de extremidade de MI. Substitua:

  • <ManagedInstanceFQDN> pelo nome de domínio totalmente qualificado da instância gerenciada.
  • <PublicKey> pelo valor da PublicKey obtido na etapa anterior (do Azure Cloud Shell, começando com 0x). Você não precisa usar aspas.

Importante

O nome do certificado precisa ser o FQDN da Instância Gerenciada de SQL e não deve ser modificado. O link não funcionará se você estiver usando um nome personalizado.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Importar chaves de autoridade de certificado raiz confiável do Azure para o SQL Server

A importação de chaves públicas de certificado raiz das ACs (autoridades de certificação) Microsoft e DigiCert para o SQL Server é necessária para o SQL Server a fim de confiar nos certificados emitidos pelo Azure para os domínios database.windows.net.

Cuidado

Verifique se a PublicKey começa com um 0x. Talvez seja necessário adicioná-lo manualmente ao início do PublicKey se ele ainda não estiver lá.

Primeiro, importe o certificado de autoridade raiz do PKI da Microsoft no SQL Server:

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exists.'
GO

Em seguida, importe o certificado de autoridade raiz do PKI da DigiCert no SQL Server:

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exists.'
GO

Por fim, verifique todos os certificados criados usando a seguinte visualização de gerenciamento dinâmico (DMV):

-- Run on SQL Server
SELECT * FROM sys.certificates

Validar o certificado

Depois de criar os certificados, valide se o certificado de ponto de extremidade de MI está configurado corretamente.

Primeiro, determine o certificate_id do certificado de MI exportado substituindo o valor de <ManagedInstanceFQDN> e executando a seguinte consulta no SQL Server:

-- Run on SQL Server 
USE MASTER 
GO 

SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Em seguida, valide o certificado substituindo o valor de <certificate_id> do resultado da consulta anterior e executando a seguinte consulta no SQL Server:

-- Run on SQL Server 

USE MASTER 
GO 

EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Uma resposta Commands completed successfully. Completion time: … indica que o certificado de ponto de extremidade de MI foi validado com êxito.

Caso encontre um erro, descarte o certificado e siga as etapas na seção Obtenha a chave pública do certificado da Instância Gerenciada de SQL e importe-a para o SQL Server para importar o certificado novamente.

Para descartar o certificado, execute a seguinte consulta no SQL Server:

-- Run on SQL Server 

USE MASTER 
GO 

DROP CERTIFICATE [<ManagedInstanceFQDN>] 
GO

Proteger o ponto de extremidade de espelhamento de banco de dados

Se você não tiver um grupo de disponibilidade existente nem um ponto de extremidade de espelhamento de banco de dados no SQL Server, a próxima etapa será criar um ponto de extremidade de espelhamento de banco de dados no SQL Server e protegê-lo com o certificado do SQL Server gerado anteriormente. Se você tiver um grupo de disponibilidade ou ponto de extremidade de espelhamento existente, vá direto para a seção Alterar um ponto de extremidade existente.

Criar e proteger o ponto de extremidade de espelhamento de banco de dados no SQL Server

Para verificar se você não tem um ponto de extremidade de espelhamento de banco de dados existente criado, use o seguinte script:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

Se a consulta anterior não mostrar um ponto de extremidade de espelhamento de banco de dados existente, execute o script a seguir no SQL Server para obter o nome do certificado do SQL Server gerado anteriormente.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Salve SQLServerCertName na saída, pois você precisará dele na próxima etapa.

Use o script a seguir para criar um ponto de extremidade de espelhamento de banco de dados na porta 5022 e proteger o ponto de extremidade com o certificado do SQL Server. Substitua:

  • <SQL_SERVER_CERTIFICATE> pelo nome do SQLServerCertName obtido na etapa anterior.
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Valide se o ponto de extremidade de espelhamento foi criado executando o seguinte script no SQL Server:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

A coluna state_desc do ponto de extremidade criado com sucesso indicará STARTED.

Um novo ponto de extremidade de espelhamento foi criado com autenticação de certificado e criptografia AES habilitada.

Alterar um ponto de extremidade existente

Observação

Ignore esta etapa se você acabou de criar um novo ponto de extremidade de espelhamento. Use esta etapa somente se estiver usando grupos de disponibilidade existentes com um ponto de extremidade de espelhamento de banco de dados existente.

Se você estiver usando grupos de disponibilidade existentes para o link ou se houver um ponto de extremidade de espelhamento de banco de dados existente, primeiro valide se ele atende às seguintes condições obrigatórias para o link:

  • O tipo deve ser DATABASE_MIRRORING.
  • A autenticação de conexão deve ser CERTIFICATE.
  • A criptografia deve estar habilitada.
  • O algoritmo de criptografia deve ser AES.

Execute a consulta a seguir no SQL Server para exibir os detalhes de um ponto de extremidade de espelhamento de banco de dados existente:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Se a saída mostrar que o DATABASE_MIRRORING ponto de extremidade existente connection_auth_descnão é CERTIFICATE ou encryption_algorthm_descnão éAES, o ponto de extremidade precisará ser alterado para atender aos requisitos.

No SQL Server, o mesmo ponto de extremidade de espelhamento de banco de dados é usado para grupos de disponibilidade e grupos de disponibilidade distribuídos. connection_auth_descSe o ponto de extremidade for NTLM(autenticação do Windows) ou KERBEROS, e você precisar de autenticação do Windows para um grupo de disponibilidade existente, será possível alterar o ponto de extremidade para usar vários métodos de autenticação alternando a opção de autenticação para NEGOTIATE CERTIFICATE. Isso permite que o grupo de disponibilidade existente use a autenticação do Windows, enquanto usa a autenticação de certificado para a Instância Gerenciada de SQL.

Da mesma forma, se a criptografia não incluir AES e você precisar de criptografia RC4, é possível alterar o ponto de extremidade para usar ambos os algoritmos. Para obter detalhes sobre as possíveis opções para alterar pontos de extremidade, consulte a página de documentação para sys.database_mirroring_endpoints.

O script a seguir é um exemplo de como alterar seu ponto de extremidade de espelhamento de banco de dados existente no SQL Server. Substitua:

  • <YourExistingEndpointName> pelo nome do ponto de extremidade existente.
  • <SQLServerCertName> pelo nome do certificado do SQL Server gerado (obtido em uma das etapas anteriores acima).

Dependendo de sua configuração específica, talvez seja necessário personalizar ainda mais o script. Você também pode usar SELECT * FROM sys.certificates para obter o nome do certificado criado no SQL Server.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Depois de executar a ALTER consulta de ponto de extremidade e definir o modo de autenticação dupla para Windows e certificado, use essa consulta novamente no SQL Server para mostrar detalhes do ponto de extremidade de espelhamento de banco de dados:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Você modificou com êxito seu ponto de extremidade de espelhamento de banco de dados para um link de instância gerenciada de SQL.

Criar um grupo de disponibilidade no SQL Server

Se você não tiver um grupo de disponibilidade existente, a próxima etapa é criar um no SQL Server, independente de qual será o primário inicial.

Observação

Ignore esta seção se você já tiver um grupo de disponibilidade.

Os comandos para criar o grupo de disponibilidade são diferentes se a Instância Gerenciada de SQL for o primário inicial, que só terá suporte a partir do SQL Server 2022 CU10.

Embora seja possível estabelecer vários links para o mesmo banco de dados, o link oferece suporte apenas à replicação de um banco de dados por link. Se desejar criar vários links para o mesmo banco de dados, use o mesmo grupo de disponibilidade para todos os links, mas crie um novo grupo de disponibilidade distribuído para cada link de banco de dados entre o SQL Server e a Instância Gerenciada de SQL.

Se o SQL Server for o principal inicial, crie um grupo de disponibilidade com os seguintes parâmetros para um link:

  • Nome do servidor primário inicial
  • Nome do banco de dados
  • Um modo de failover de MANUAL
  • Um modo de semeadura AUTOMATIC

Primeiro, descubra o nome do seu SQL Server executando a seguinte instrução T-SQL:

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

Em seguida, use o script a seguir para criar o grupo de disponibilidade no SQL Server. Substitua:

  • <AGNameOnSQLServer> com o nome do grupo de disponibilidade no SQL Server. Um link de Instância Gerenciada requer um banco de dados por grupo de disponibilidade. Para vários bancos de dados, você precisará criar vários grupos de disponibilidade. Considere nomear cada grupo de disponibilidade para que seu nome reflita o banco de dados correspondente - por exemplo, AG_<db_name>.
  • <DatabaseName> pelo nome do banco de dados que você deseja replicar.
  • <SQLServerName> pelo nome da instância do SQL Server obtido na etapa anterior.
  • <SQLServerIP> com o endereço IP do SQL Server. Você pode usar um nome de máquina host do SQL Server que pode ser resolvido como alternativa, mas você precisa se certificar de que o nome pode ser resolvido na rede virtual da Instância Gerenciada do SQL.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

Importante

Para o SQL Server 2016, exclua WITH (CLUSTER_TYPE = NONE) da instrução T-SQL acima. Mantenha-o no estado em que se encontra em todas as versões posteriores do SQL Server.

Em seguida, crie o grupo de disponibilidade distribuído no SQL Server. Se você planeja criar vários links, precisará criar um grupo de disponibilidade distribuído para cada link, mesmo que esteja estabelecendo vários links para o mesmo banco de dados.

Substitua os valores a seguir e execute o script T-SQL para criar seu grupo de disponibilidade distribuído.

  • <DAGName> pelo nome do seu grupo de disponibilidade distribuído. Como é possível configurar vários links para o mesmo banco de dados criando um grupo de disponibilidade distribuído para cada link, considere nomear cada grupo de disponibilidade distribuída de acordo, por exemplo, DAG1_<db_name>, DAG2_<db_name>.
  • <AGNameOnSQLServer> com o nome do grupo de disponibilidade que você criou na etapa anterior.
  • <AGNameOnSQLMI> com o nome do grupo de disponibilidade na Instância Gerenciada de SQL. O nome precisa ser exclusivo no SQL MI. Considere nomear cada grupo de disponibilidade para que seu nome reflita o banco de dados correspondente - por exemplo, AG_<db_name>_MI.
  • <SQLServerIP> com o endereço IP do SQL Server da etapa anterior. Você pode usar um nome de computador host do SQL Server como alternativa, mas garanta que o nome possa ser resolvido na rede virtual da Instância Gerenciada de SQL (que exige a configuração de um DNS do Azure personalizado para a sub-rede da instância gerenciada).
  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
  • <ManagedInstanceFQDN> com o nome de domínio totalmente qualificado da sua instância gerenciada.
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

Verificar grupos de disponibilidade

Use o script a seguir para listar todos os Grupos de disponibilidade e grupos de disponibilidade distribuídos na instância do SQL Server. Neste ponto, o estado do seu grupo de disponibilidade precisa ser connected, e o estado de seus grupos de disponibilidade distribuídos precisa ser disconnected. O estado do Grupo de Disponibilidade Distribuído muda para connected uma vez que tiver sido ingressado na Instância Gerenciada SQL.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

Como alternativa, você pode usar o SSMS Pesquisador de Objetos para localizar grupos de disponibilidade e grupos de disponibilidade distribuídos. Expanda a pasta Always On High Availability e, em seguida, a pasta Grupos de Disponibilidade.

Por fim, você pode criar o link. Os comandos diferem com base em qual instância é o primário inicial. Use o comando New-AzSqlInstanceLink do PowerShell ou o comando az sql mi link create da CLI do Azure para criar o link, como no exemplo de PowerShell nesta seção. No momento, não há suporte para a criação do link a partir de um primário da Instância Gerenciada de SQL com a CLI do Azure.

Se você precisar ver todos os links em uma instância gerenciada, use o comando Get-AzSqlInstanceLink do PowerShell ou o comando az sql mi link show da CLI do Azure no Azure Cloud Shell.

Para simplificar o processo, entre no portal do Azure e execute o script do Azure Cloud Shell a seguir. Substitua:

  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
  • <AGNameOnSQLServer> pelo nome do grupo de disponibilidade criado no SQL Server.
  • <AGNameOnSQLMI> com o nome do grupo de disponibilidade criado na Instância Gerenciada de SQL.
  • <DAGName> pelo nome do grupo de disponibilidade distribuído criado no SQL Server.
  • <DatabaseName> pelo banco de dados replicado no grupo de disponibilidade no SQL Server.
  • <SQLServerIP> pelo endereço IP do SQL Server. O endereço IP fornecido precisa ser acessível para a instância gerenciada.

Observação

Se você quiser estabelecer um link para um grupo de disponibilidade que já existe, forneça o endereço IP do ouvinte ao fornecer o parâmetro <SQLServerIP>.

#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGNameOnSQLServer -SecondaryAvailabilityGroupName $AGNameOnSQLMI |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

O resultado dessa operação é um carimbo de data/hora da execução bem-sucedida da solicitação para criar um link.

Para verificar a conexão entre a Instância Gerenciada de SQL e o SQL Server, execute a consulta a seguir no SQL Server. A conexão não será instantânea. Pode levar até um minuto para que a DMV comece a mostrar uma conexão bem-sucedida. Continue atualizando a DMV até que a conexão seja exibida como CONNECTED para a réplica da Instância Gerenciada de SQL.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

Depois que a conexão é estabelecida, o Pesquisador de Objetos no SSMS pode inicialmente mostrar os bancos de dados na réplica secundária em estado de Restauração à medida que a fase de propagação inicial se move e restaura o backup completo do banco de dados. Depois que o banco de dados é restaurado, a replicação precisa ser recuperada para colocar os dois bancos de dados em um estado sincronizado. O banco de dados não estará mais em Restauração depois que a propagação inicial terminar. A propagação de bancos de dados pequenos pode ser rápida o suficiente para que você não veja o estado inicial de Restauração no SSMS.

Importante

  • O link não funcionará a menos que exista conectividade de rede entre o SQL Server e a Instância Gerenciada SQL. Para solucionar problemas de conectividade de rede, siga as etapas em Testar conectividade de rede.
  • Faça backups regulares do arquivo de log no SQL Server. Se o espaço de log usado atingir 100%, a replicação para Instância Gerenciada de SQL será interrompida até que o uso de espaço seja reduzido. É altamente recomendável automatizar os backups de log configurando um trabalho diário. Para obter detalhes, consulte Fazer o back-up de arquivos de log SQL Server.

Fazer o primeiro backup de log de transações

Se o SQL Server for o primário inicial, é importante fazer o primeiro backup de log de transações no SQL Server após a conclusão do posicionamento inicial, quando o banco de dados não estiver mais no estado Restaurando... na Instância Gerenciada de SQL do Azure. Em seguida, faça backups de log de transações do SQL Server regularmente para minimizar o crescimento excessivo do log enquanto o SQL Server estiver na função primária.

Se a Instância Gerenciada de SQL for primária, não será necessário executar nenhuma ação, pois a Instância Gerenciada de SQL do Azure realiza backups de log automaticamente.

Se você quiser descartar o link, seja porque ele não é mais necessário ou porque está em um estado irreparável e precisa ser recriado, poderá fazer isso com o PowerShell e T-SQL.

Primeiro, use o comando Remove-AzSqlInstanceLink do PowerShell para descartar o link, como no seguinte exemplo:

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force

Em seguida, execute o script T-SQL a seguir para descartar o grupo de disponibilidade distribuído. Substitua <DAGName> pelo nome do grupo de disponibilidade distribuído usado para criar o link.

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO

Por fim, opcionalmente, você poderá remover o grupo de disponibilidade se não tiver mais uso para ele. Para fazer isso, substitua o <AGName> pelo nome do grupo de disponibilidade e execute-o na respectiva instância:

DROP AVAILABILITY GROUP <AGName>  
GO

Solucionar problemas

Caso encontre uma mensagem de erro ao criar o link, revise a mensagem de erro na janela de saída da consulta para obter mais informações.

Conteúdo relacionado

Para usar o link:

Para saber mais sobre o link:

Para outros cenários de replicação e migração, considere: