Migrar do SQL Server autogerenciado usando grupos de disponibilidade distribuídos

Neste guia, mostramos como migrar bancos de dados de uma instância autogerenciada do SQL Server Enterprise Edition para o Cloud SQL para SQL Server Enterprise Edition em uma conexão de rede privada usando um grupo de disponibilidade distribuído (DAG, na sigla em inglês) no Database Migration Service.

Com uma migração de DAG, o Database Migration Service faz streaming da carga completa inicial (conhecida como fase FULL_DUMP) e da replicação contínua do registro de transações (conhecida como fase de captura de dados alterados - CDC) diretamente pela rede entre o grupo de disponibilidade de origem e o grupo de disponibilidade de destino do Cloud SQL para SQL Server. Para mais informações sobre a arquitetura, os pré-requisitos e as limitações das migrações de DAG, consulte Sobre as migrações de grupo de disponibilidade distribuído (DAG). Para migrar usando arquivos de backup armazenados no Cloud Storage, consulte Migrar os bancos de dados do SQL Server para o Cloud SQL para SQL Server.

Para realizar uma migração de grupo de disponibilidade distribuído, conclua as seguintes tarefas de alto nível:

1. Crie e prepare a instância de destino do Cloud SQL para SQL Server.
2. Prepare a instância de origem do SQL Server e o grupo de disponibilidade.
3. Estabeleça conectividade de rede privada bidirecional e configure um servidor vinculado.
4. Crie perfis de conexão e execute o job de migração.
5. Monitorar e verificar a migração.
6. Promova, faça failback ou conclua a migração.

Custos

Para migrações homogêneas para o Cloud SQL, o Database Migration Service é oferecido sem custo adicional. No entanto, os preços padrão do Cloud SQL e da rede são aplicáveis. Para estimar os custos de uso, use a calculadora de preços.

Antes de começar

1. Verifique se os bancos de dados de origem e de destino atendem a todos os pré-requisitos e limitações para migrações de grupos de disponibilidade distribuídos (incluindo a execução do Enterprise Edition, o armazenamento de arquivos de dados no diretório de dados padrão e não o uso de sa como proprietário do banco de dados). Consulte Sobre as migrações de grupo de disponibilidade distribuído (DAG).
2. Escolha a região Google Cloud da migração. O Database Migration Service é um produto totalmente regional. Todas as entidades relacionadas à migração (perfis de conexão de origem e destino, job de migração e instância de destino do Cloud SQL para SQL Server) precisam residir na mesma região.
3. No console do Google Cloud , na página do seletor de projetos, selecione ou crie um projeto do Google Cloud .

   Acessar o seletor de projetos

4. Ative as APIs Database Migration Service, Compute Engine e Cloud SQL Admin.

   Ativar as APIs

Funções exigidas

Verifique se os seguintes papéis do IAM foram concedidos no seu projeto doGoogle Cloud :

• Conta de usuário que realiza a migração:
  • Administrador de migração do banco de dados (roles/datamigration.admin)
  • Editor do Cloud SQL (roles/cloudsql.editor)
• Conta de serviço do Database Migration Service (service-<var>PROJECT_NUMBER</var>@gcp-sa-datamigration.iam.gserviceaccount.com):
  • Agente de serviço do Database Migration Service (roles/datamigration.serviceAgent)
  • Editor do Cloud SQL (roles/cloudsql.editor)
  • Usuário do Cloud SQL Studio (roles/cloudsql.studioUser)

Para mais informações sobre como conceder papéis, consulte Gerenciar o acesso.

Criar e preparar a instância de destino do Cloud SQL para SQL Server

Nesta etapa, você vai criar a instância de destino do Cloud SQL para SQL Server Enterprise Edition e ativar a flag de banco de dados necessária para servidores vinculados.

1. Crie a instância de destino do Cloud SQL para SQL Server. Para instruções detalhadas de criação, consulte Criar uma instância do Cloud SQL para SQL Server. Verifique se a instância atende aos seguintes requisitos para migrações de grupos de disponibilidade distribuídos:
   • Selecione Enterprise Edition (versão 2017, 2019, 2022 ou 2025).
   • Configure a rede particular para se alinhar à forma como você planeja conectar a instância de origem do SQL Server e a instância de destino do Cloud SQL para SQL Server. Ative o acesso a serviços privados se você planeja conectar suas instâncias por peering de nuvem privada virtual ou use o Private Service Connect se planeja conectar suas instâncias usando um endpoint de entrada do Private Service Connect e um anexo de rede de saída do Private Service Connect.

     Não ative o acesso a serviços particulares e o Private Service Connect na mesma instância de destino do Cloud SQL para SQL Server. O Cloud SQL para SQL Server não é compatível com servidores vinculados quando ambos estão ativados. Para detalhes completos sobre a configuração de rede, consulte Estabelecer conectividade de rede privada bidirecional.

   • Mantenha a recuperação pontual (PITR) desativada e não adicione réplicas de leitura até concluir e excluir o job de migração do DAG.
   • Se algum banco de dados de origem for de propriedade de um login do Active Directory do Windows, mude o proprietário do banco de dados de origem para um login do SQL antes de migrar ou adicione a instância de destino do Cloud SQL para SQL Server ao Active Directory para que o Database Migration Service possa criar automaticamente o login correspondente do Windows na instância de destino quando o job de migração for iniciado. Para instruções, consulte Configurar o Microsoft AD gerenciado para o Cloud SQL para SQL Server.
2. Ative a flag de banco de dados cloudsql enable linked servers (definida como on) na instância de destino do Cloud SQL para SQL Server. Para instruções sobre como definir flags, consulte Gerenciar servidores vinculados e Configurar flags de banco de dados.

   Essa flag é necessária mais adiante neste guia, quando você criar e verificar o servidor vinculado na instância de destino do Cloud SQL para SQL Server.

Preparar a instância de origem do SQL Server

Nesta etapa, você vai ativar os grupos de disponibilidade sempre ativados na instância de origem do SQL Server, criar um endpoint e um certificado de espelhamento de banco de dados, criar um login SQL dedicado para o Database Migration Service e preparar o grupo de disponibilidade de origem.

Ativar grupos de disponibilidade Always On

Verifique se o recurso Grupos de Disponibilidade Always On está ativado na instância de origem do SQL Server:

• Para Windows, consulte Ativar e desativar grupos de disponibilidade sempre ativados na documentação da Microsoft.
• Para Linux, consulte Configurar o grupo de disponibilidade Always On do SQL Server para alta disponibilidade no Linux na documentação da Microsoft.

Criar o endpoint e o certificado de espelhamento de banco de dados

No SQL Server, os grupos de disponibilidade distribuídos transmitem dados e registros de transações entre instâncias por endpoints TCP DATABASE_MIRRORING (DBM) (porta padrão 5022). Como a instância autogerenciada do SQL Server e a instância de destino do Cloud SQL para SQL Server são instâncias independentes, elas exigem autenticação mútua baseada em certificado e codificação AES para estabelecer confiança no endpoint DBM.

Basta criar um certificado e vinculá-lo ao endpoint DATABASE_MIRRORING na instância de origem do SQL Server. Não é necessário exportar manualmente arquivos de certificado ou criar certificados na instância de destino do Cloud SQL para SQL Server:

• Quando você inicia o job de migração, o Database Migration Service configura automaticamente o endpoint e o certificado DATABASE_MIRRORING na instância de destino do Cloud SQL para SQL Server e usa o servidor vinculado para trocar as chaves públicas entre as duas instâncias.
• Quando você exclui o job de migração depois de concluir a transição, o Database Migration Service remove automaticamente os certificados importados de ambas as instâncias.

Se a instância de origem do SQL Server ainda não tiver um endpoint DATABASE_MIRRORING autenticado com um certificado, crie um:

1. Conecte-se à instância de origem com um cliente SQL, por exemplo, o utilitário sqlcmd.
2. Execute os seguintes comandos T-SQL para criar uma chave mestra de banco de dados, um certificado e um endpoint DATABASE_MIRRORING que detecta a porta DBM escolhida (padrão 5022):

   USE [master];
   GO
   
   IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
   BEGIN
       CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MASTER_KEY_PASSWORD';
   END
   GO
   
   CREATE CERTIFICATE [SOURCE_CERT_NAME]
       WITH SUBJECT = 'AlwaysOn AG Certificate',
       EXPIRY_DATE = 'CERT_EXPIRY_DATE';
   GO
   
   CREATE ENDPOINT [HADR_ENDPOINT_NAME]
       STATE = STARTED
       AS TCP (LISTENER_PORT = SOURCE_DBM_PORT_NUMBER)
       FOR DATABASE_MIRRORING (
           ROLE = ALL,
           AUTHENTICATION = CERTIFICATE [SOURCE_CERT_NAME],
           ENCRYPTION = REQUIRED ALGORITHM AES
       );
   GO

   Substitua:

   • MASTER_KEY_PASSWORD por uma senha para criptografar a chave mestra do banco de dados.
   • SOURCE_CERT_NAME por um nome para o certificado de espelhamento de banco de dados de origem (por exemplo, dbmCertificate).
   • CERT_EXPIRY_DATE pela data de validade do certificado no formato YYYYMMDD.
   • HADR_ENDPOINT_NAME pelo nome do endpoint de espelhamento de banco de dados.
   • SOURCE_DBM_PORT_NUMBER pelo número da porta TCP para o tráfego de espelhamento de banco de dados (padrão 5022).

Criar o login e as permissões dedicados do Database Migration Service

O Database Migration Service se conecta à instância de origem do SQL Server pelo servidor vinculado usando um login SQL dedicado que você fornece no perfil de conexão de origem. Para configurar esse login, conceda o papel de servidor sysadmin ou configure permissões de privilégio mínimo com o banco de dados auxiliar gcp_dms_db:

Conceder papel de sysadmin

Se a política de segurança permitir a concessão do papel de servidor sysadmin ao login de migração, execute os seguintes comandos T-SQL:

USE [master];
GO
CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GO

Substitua:

• SOURCE_USERNAME pelo nome de login do SQL que o Database Migration Service usa para se conectar à instância de origem (por exemplo, cloud_dms_login).
• SOURCE_PASSWORD pela senha do login SOURCE_USERNAME.
• SOURCE_USER pelo nome de usuário do banco de dados mapeado para SOURCE_USERNAME (por exemplo, cloud_dms_user).
• HADR_ENDPOINT_NAME pelo nome do endpoint de espelhamento de banco de dados (por exemplo, Hadr_endpoint).

Privilégio mínimo (gcp_dms_db)

Se a política de segurança proibir a concessão de sysadmin ao login de migração, crie o banco de dados auxiliar gcp_dms_db dedicado (de propriedade de sa com TRUSTWORTHY ON), crie os três procedimentos armazenados do wrapper do Database Migration Service e conceda permissões granulares ao login de migração:

USE [master];
GO

CREATE DATABASE [gcp_dms_db];
GO

ALTER AUTHORIZATION ON DATABASE::[gcp_dms_db] TO [sa];
ALTER DATABASE [gcp_dms_db] SET TRUSTWORTHY ON;
GO

USE [gcp_dms_db];
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_commit_mode
    @dag_name NVARCHAR(128),
    @source_ag NVARCHAR(128),
    @dest_ag NVARCHAR(128),
    @commit_mode NVARCHAR(30)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    IF @commit_mode NOT IN ('SYNCHRONOUS_COMMIT', 'ASYNCHRONOUS_COMMIT')
    BEGIN
        RAISERROR('Invalid commit mode. Must be SYNCHRONOUS_COMMIT or ASYNCHRONOUS_COMMIT.', 16, 1);
        RETURN;
    END
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) +
               N' MODIFY AVAILABILITY GROUP ON ' +
               QUOTENAME(@source_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N'), ' +
               QUOTENAME(@dest_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N');';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_secondary
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' SET (ROLE = SECONDARY);';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_failover_dag
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' FORCE_FAILOVER_ALLOW_DATA_LOSS;';
    EXECUTE sp_executesql @sql;
END;
GO

USE [master];
GO

CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT VIEW SERVER STATE TO [SOURCE_USERNAME];
-- Note: Run GRANT VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later:
GRANT VIEW SERVER PERFORMANCE STATE TO [SOURCE_USERNAME];
GRANT VIEW ANY DEFINITION TO [SOURCE_USERNAME];
GRANT ALTER ANY AVAILABILITY GROUP TO [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GRANT CREATE CERTIFICATE TO [SOURCE_USER];
GO

USE [gcp_dms_db];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_commit_mode TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_secondary TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_failover_dag TO [SOURCE_USER];
GO

-- Repeat the following block for EACH user database in your source Availability Group:
USE [DATABASE_NAME];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER ROLE [db_backupoperator] ADD MEMBER [SOURCE_USER];
GO

Substitua:

• SOURCE_USERNAME pelo nome de login do SQL que o Database Migration Service usa para se conectar à instância de origem (por exemplo, cloud_dms_login).
• SOURCE_PASSWORD pela senha do login SOURCE_USERNAME.
• SOURCE_USER pelo nome de usuário do banco de dados mapeado para SOURCE_USERNAME (por exemplo, cloud_dms_user).
• HADR_ENDPOINT_NAME pelo nome do endpoint de espelhamento de banco de dados (por exemplo, Hadr_endpoint).
• DATABASE_NAME pelo nome de cada banco de dados de origem no grupo de disponibilidade. A concessão de db_backupoperator em cada banco de dados migrado é exigida pela verificação de simulação do Database Migration Service e permite limpar os registros de transações com CHECKPOINT durante a promoção.

Preparar os bancos de dados de origem e o grupo de disponibilidade

É possível migrar bancos de dados de um grupo de disponibilidade Always On atual ou criar um novo grupo de disponibilidade independente (CLUSTER_TYPE = NONE). Antes de continuar, verifique os seguintes requisitos:

• Cada banco de dados no grupo de disponibilidade usa o modelo de recuperação FULL, não é de propriedade de sa e armazena os arquivos de dados (.mdf e .ndf) no diretório de dados padrão.
• Se você reutilizar um grupo de disponibilidade, confirme se o endpoint de espelhamento de banco de dados está configurado na porta 5022 (ou na porta DBM escolhida), se SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) está ativado na réplica para que os bancos de dados secundários permaneçam legíveis com strings de conexão padrão depois que a promoção inverter os papéis do DAG e se o login de migração tem CONNECT ON ENDPOINT. Se o grupo de disponibilidade de origem tiver várias réplicas e um listener de grupo de disponibilidade configurado, use o endereço IP do listener como <var>SOURCE_HOST_IP_ADDRESS</var> ao configurar o servidor vinculado e o perfil de conexão de origem para que a migração possa ser retomada se ocorrer um failover no grupo de disponibilidade de origem.

Para preparar um banco de dados e criar um novo grupo de disponibilidade independente (CLUSTER_TYPE = NONE), execute os seguintes comandos T-SQL:

USE [master];
GO

ALTER DATABASE [DATABASE_NAME] SET RECOVERY FULL;
GO

-- If the database is owned by 'sa', change the owner to another login:
ALTER AUTHORIZATION ON DATABASE::[DATABASE_NAME] TO [DB_OWNER_LOGIN];
GO

-- Initialize the local SQL Server transaction log chain for the Availability Group:
BACKUP DATABASE [DATABASE_NAME] TO DISK = 'NUL';
GO

CREATE AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON N'SOURCE_SERVER_NAME' WITH (
        ENDPOINT_URL = N'TCP://localhost:SOURCE_DBM_PORT_NUMBER',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        SEEDING_MODE = MANUAL,
        PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE),
        SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
    );
GO

ALTER AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] ADD DATABASE [DATABASE_NAME];
GO

Substitua:

• DATABASE_NAME pelo nome do banco de dados a ser incluído no grupo de disponibilidade.
• DB_OWNER_LOGIN por um login que não seja sa para ser o proprietário do banco de dados.
• SOURCE_AVAILABILITY_GROUP_NAME pelo nome do grupo de disponibilidade de origem (por exemplo, source_ag).
• SOURCE_SERVER_NAME pelo nome do servidor da instância de origem do SQL Server (correspondente ao valor retornado por SELECT @@SERVERNAME).
• SOURCE_DBM_PORT_NUMBER pelo número da porta TCP do endpoint de espelhamento de banco de dados (padrão 5022).

Observação : a execução de BACKUP DATABASE ... TO DISK = 'NUL' é um requisito local do SQL Server para inicializar a cadeia de registros de transações do banco de dados depois de alternar para o modelo de recuperação FULL antes de adicioná-lo a um grupo de disponibilidade. Esse comando inicializa a cadeia de registros local para o grupo de disponibilidade e não cria nem faz upload de arquivos de backup. Quando você inicia o job de migração, o Database Migration Service configura o grupo de disponibilidade distribuída para transmitir a carga completa inicial diretamente pela rede.

Estabelecer conectividade de rede privada bidirecional

Para migrações de DAG, o Database Migration Service se comunica com a instância de destino do Cloud SQL para SQL Server por meio de APIs internas do Google Cloud , executa consultas de orquestração na instância de origem do SQL Server por meio de um servidor vinculado na instância de destino do Cloud SQL para SQL Server e transmite dados diretamente entre as duas instâncias por uma rede privada. Essa migração exige que você estabeleça uma conexão por IP privado bidirecional diretamente entre o host de origem do SQL Server e a instância de destino do Cloud SQL para SQL Server pela rede de nuvem privada virtual. A conectividade por IP público entre as instâncias de origem e destino não é compatível.

Portas e endereços IP necessários

A configuração de rede precisa permitir o tráfego entre a instância de origem do SQL Server e a instância de destino do Cloud SQL para SQL Server nas duas portas TCP a seguir:

Porta	Direção	Finalidade
Porta do banco de dados do SQL Server (padrão 1433)	Da instância de destino do Cloud SQL para SQL Server para a instância de origem do SQL Server	Usado pelo servidor vinculado na instância de destino do Cloud SQL para SQL Server para executar consultas de validação de simulação, troca de certificados e orquestração de DAG na instância de origem.
Porta de espelhamento de banco de dados (DBM) (padrão 5022)	Bidirecional entre a instância de origem do SQL Server e a instância de destino do Cloud SQL para SQL Server	Usado pelos grupos de disponibilidade de origem e destino para transmitir a carga completa inicial durante FULL_DUMP, as mudanças contínuas no banco de dados durante CDC e a replicação reversa durante FAILBACK.

Ao configurar o servidor vinculado e os perfis de conexão mais adiante neste guia, você vai fornecer dois endereços IP particulares:

• SOURCE_HOST_IP_ADDRESS (usado no parâmetro @datasrc do servidor vinculado e na flag --host do perfil de conexão de origem) é o endereço IP privado do host do SQL Server de origem (ou o endereço IP do listener do grupo de disponibilidade, que é preferível se configurado para um grupo de disponibilidade de origem com várias réplicas, para que a migração possa ser retomada se ocorrer um failover no grupo de disponibilidade de origem) que pode ser acessado pela instância de destino do Cloud SQL para SQL Server.
• DESTINATION_HOST_IP_ADDRESS (usado na flag --host do perfil de conexão de destino) é o endereço IP privado da instância de destino do Cloud SQL para SQL Server (ou o endereço IP do endpoint do Private Service Connect) que pode ser acessado pelo host de origem do SQL Server.

Configurar o método de rede particular

Conclua a configuração de roteamento de rede para o método de rede (acesso a serviços particulares ou Private Service Connect) que você ativou na instância de destino do Cloud SQL para SQL Server:

Acesso privado a serviços

O acesso a serviços particulares faz peering da sua rede de nuvem privada virtual com a rede de nuvem privada virtual do produtor de serviço gerenciado pelo Google que hospeda a instância de destino do Cloud SQL para SQL Server:

1. Verifique se a rede de nuvem privada virtual tem um intervalo de endereços IPv4 interno alocado e uma conexão particular (peering de nuvem privada virtual com servicenetworking-googleapis-com) ativada para a instância de destino do Cloud SQL para SQL Server. Para instruções, consulte Configurar IP particular para o Cloud SQL para SQL Server.
2. Configure o roteamento para o host de origem do SQL Server com base em onde ele está hospedado:
   • Se a instância de origem for executada em uma máquina virtual do Compute Engine na mesma rede de nuvem privada virtual, nenhum roteamento adicional será necessário. A máquina virtual e a instância do Cloud SQL para SQL Server podem acessar os endereços IP particulares uma da outra diretamente pela conexão de peering da nuvem privada virtual.
   • Se a instância de origem for executada no local, em outro provedor de nuvem ou em outra rede de nuvem privada virtual, siga as etapas abaixo para que as rotas sejam trocadas pelo limite de peering transitivo:
     1. Conecte sua rede externa à rede de nuvem privada virtual usando o Cloud VPN ou o Cloud Interconnect. Para instruções, consulte Acessar uma instância do Cloud SQL de uma fonte externa.
     2. No Cloud Router, divulgue o intervalo de endereços IP alocado do Cloud SQL para SQL Server para sua rede de origem. Para instruções, consulte Divulgar intervalos de IP personalizados.
     3. Atualize a conexão de peering servicenetworking-googleapis-com na rede de nuvem privada virtual para ativar a opção Exportar rotas personalizadas para que a instância do Cloud SQL para SQL Server aprenda as rotas para a rede de origem. Para instruções, consulte Atualizar uma conexão de peering.
3. Registre os endereços IP particulares da migração:
   • Use o endereço IP interno do host do SQL Server de origem como SOURCE_HOST_IP_ADDRESS.
   • Use o endereço IP particular atribuído à instância de destino do Cloud SQL para SQL Server (mostrado na página Visão geral da instância) como DESTINATION_HOST_IP_ADDRESS.

Private Service Connect

Se você usar o Private Service Connect em vez do acesso a serviços particulares, configure um endpoint de entrada do Private Service Connect (para que a instância de origem possa se conectar ao Cloud SQL para SQL Server na porta 5022) e uma interface de saída do Private Service Connect (para que o Cloud SQL para SQL Server possa iniciar conexões de servidor vinculado e DAG com a instância de origem nas portas 1433 e 5022):

1. Verifique se a instância de destino do Cloud SQL para SQL Server tem o Private Service Connect ativado (sem IP privado) e especifica os projetos de consumidor permitidos. Para instruções, consulte Configurar o Private Service Connect.
2. Para permitir conexões de entrada do host de origem do SQL Server com a instância de destino do Cloud SQL para SQL Server, reserve um endereço IP interno na sub-rede da nuvem privada virtual e crie um endpoint do Private Service Connect (regra de encaminhamento) que tenha como destino o anexo de serviço da instância do Cloud SQL para SQL Server. Para instruções, consulte Criar um endpoint do Private Service Connect.
3. Para permitir conexões de saída da instância de destino do Cloud SQL para SQL Server com o host de origem do SQL Server (necessário para conexões de servidor vinculado e DAG de saída), crie um anexo de rede de nuvem privada virtual na sub-rede que pode rotear para o host de origem e configure a conectividade de saída do Private Service Connect na instância de destino do Cloud SQL para SQL Server. Para instruções, consulte Criar e gerenciar anexos de rede e Configurar a conectividade de saída do Private Service Connect.
4. Registre os endereços IP particulares da migração:
   • Use o endereço IP particular do host do SQL Server de origem como SOURCE_HOST_IP_ADDRESS.
   • Use o endereço IP interno do endpoint do Private Service Connect (regra de encaminhamento) na sua rede de nuvem privada virtual como DESTINATION_HOST_IP_ADDRESS.

Configurar regras de firewall da nuvem privada virtual e do host de origem

1. Na rede de nuvem privada virtual, crie regras de firewall de entrada e saída que permitam o tráfego TCP entre o endereço IP do SQL Server de origem (SOURCE_HOST_IP_ADDRESS) e o intervalo de IP do Cloud SQL para SQL Server de destino (ou endpoint do Private Service Connect e sub-rede de anexo de rede) na porta do banco de dados (padrão 1433) e na porta de espelhamento de banco de dados (padrão 5022). Para mais informações sobre como criar regras de firewall, consulte Criar regras de firewall.
2. Na máquina de origem do SQL Server, verifique as seguintes configurações de rede e firewall do host:
   • O TCP/IP está ativado no SQL Server Configuration Manager (ou mssql-conf no Linux), e a instância detecta uma porta TCP estática (padrão 1433).
   • O firewall do sistema operacional (como o Firewall do Windows Defender ou o iptables ou firewalld do Linux) permite conexões TCP de entrada na porta do banco de dados (padrão 1433) e na porta de espelhamento do banco de dados (padrão 5022), além de conexões TCP de saída para DESTINATION_HOST_IP_ADDRESS na porta 5022.

Verificar a acessibilidade com os testes de conectividade do Cloud SQL

Antes de configurar o servidor vinculado, recomendamos executar três testes de conectividade na guia Conexões > Testes de conectividade da sua instância do Cloud SQL para SQL Server no console do Google Cloud . Para instruções sobre como executar um teste de conectividade, consulte Gerenciar testes de conectividade:

1. Para testar a conectividade de saída do servidor vinculado na porta 1433, defina Origem como Instância atual do Cloud SQL, Destino como SOURCE_HOST_IP_ADDRESS e Porta de destino como 1433 (ou sua porta de banco de dados personalizada).
2. Para testar a conectividade de saída do espelhamento de banco de dados na porta 5022, defina Origem como Instância atual do Cloud SQL, Destino como SOURCE_HOST_IP_ADDRESS e Porta de destino como 5022 (ou sua porta DBM personalizada).
3. Para testar a conectividade de entrada do espelhamento de banco de dados na porta 5022, defina Origem como SOURCE_HOST_IP_ADDRESS, Destino como Instância atual do Cloud SQL (ou DESTINATION_HOST_IP_ADDRESS se você usar o Private Service Connect) e Porta de destino como 5022 (ou sua porta DBM personalizada).

Criar e verificar o servidor vinculado na instância de destino do Cloud SQL para SQL Server

Depois que a conectividade de rede estiver estabelecida, conecte-se à instância de destino do Cloud SQL para SQL Server e crie o servidor vinculado que aponta para a instância de origem do SQL Server:

1. Conecte-se à instância do Cloud SQL com um cliente SQL. Use os seguintes métodos:
   • Cliente do sqlcmd. É possível usar esse método para se conectar ao IP privado da instância, mas talvez seja necessário criar uma máquina virtual do Compute Engine.
   • Comando gcloud sql connect. Esse comando funciona apenas para instâncias do Cloud SQL que têm um endereço IP público ativado.
2. Faça login como o usuário sqlserver e execute os seguintes comandos T-SQL para a versão de destino do Cloud SQL para SQL Server para criar um servidor vinculado que aponte para a instância de origem do SQL Server, mapeie @locallogin = N'sqlserver' para o login de migração de origem, ative rpc out e teste a conexão com OPENQUERY. Para mais informações sobre as opções de servidor vinculado no Cloud SQL, consulte Gerenciar servidores vinculados:

   Cloud SQL para SQL Server 2017, 2019 e 2022

   USE [master];
   GO
   
   EXEC master.dbo.sp_addlinkedserver
       @server = N'LINKED_SERVER_NAME',
       @srvproduct = N'',
       @provider = N'SQLNCLI',
       @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER';
   GO
   
   EXEC master.dbo.sp_addlinkedsrvlogin
       @rmtsrvname = N'LINKED_SERVER_NAME',
       @useself = N'False',
       @locallogin = N'sqlserver',
       @rmtuser = N'SOURCE_USERNAME',
       @rmtpassword = N'SOURCE_PASSWORD';
   GO
   
   EXEC master.dbo.sp_serveroption
       @server = N'LINKED_SERVER_NAME',
       @optname = N'rpc out',
       @optvalue = N'TRUE';
   GO
   
   SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
   GO

   Cloud SQL para SQL Server 2025

   USE [master];
   GO
   
   EXEC master.dbo.sp_addlinkedserver
       @server = N'LINKED_SERVER_NAME',
       @srvproduct = N'',
       @provider = N'MSOLEDBSQL19',
       @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER',
       @provstr = N'Encrypt=Optional;TrustServerCertificate=Yes;Authentication=SqlPassword;UID=Placeholder;';
   GO
   
   EXEC master.dbo.sp_addlinkedsrvlogin
       @rmtsrvname = N'LINKED_SERVER_NAME',
       @useself = N'False',
       @locallogin = N'sqlserver',
       @rmtuser = N'SOURCE_USERNAME',
       @rmtpassword = N'SOURCE_PASSWORD';
   GO
   
   EXEC master.dbo.sp_serveroption
       @server = N'LINKED_SERVER_NAME',
       @optname = N'rpc out',
       @optvalue = N'TRUE';
   GO
   
   SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
   GO

   Substitua:

   • LINKED_SERVER_NAME pelo nome do servidor vinculado no Cloud SQL para SQL Server (por exemplo, source_sql_linked_server).
   • SOURCE_HOST_IP_ADDRESS pelo endereço IP privado da instância de origem do SQL Server (ou o endereço IP do listener do grupo de disponibilidade, se configurado para um grupo de disponibilidade de origem com várias réplicas).
   • SOURCE_PORT_NUMBER pelo número da porta em que o mecanismo de banco de dados do SQL Server de origem aceita conexões (padrão 1433).
   • SOURCE_USERNAME pelo nome de login dedicado do SQL que você criou na instância de origem em Criar o login e as permissões dedicados do Database Migration Service.
   • SOURCE_PASSWORD pela senha do login SOURCE_USERNAME.

Criar perfis de conexão e executar o job de migração

Use a Google Cloud CLI para criar os perfis de conexão de origem e destino, criar o job de migração contínua de DAG, verificar a configuração de migração e iniciar o job de migração:

1. Crie o perfil de conexão de origem.
   Execute o comando gcloud database-migration connection-profiles create sqlserver (clique para abrir):

   gcloud database-migration connection-profiles create sqlserver

   Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível pular a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

   gcloud database-migration connection-profiles create sqlserver SOURCE_CONNECTION_PROFILE_ID \
       --no-async \
       --display-name=SOURCE_CONNECTION_PROFILE_NAME \
       --region=REGION \
       --role=SOURCE \
       --host=SOURCE_HOST_IP_ADDRESS \
       --port=SOURCE_PORT_NUMBER \
       --dbm-port=SOURCE_DBM_PORT_NUMBER \
       --username=SOURCE_USERNAME \
       --password=SOURCE_PASSWORD

   Substitua:

   • SOURCE_CONNECTION_PROFILE_ID por um identificador legível por máquina para o perfil de conexão de origem (por exemplo, sqlserver-dag-source-profile).
   • SOURCE_CONNECTION_PROFILE_NAME com um nome legível por humanos para o perfil de conexão de origem. Esse valor é exibido no Database Migration Service no console do Google Cloud .
   • REGION pelo identificador da região em que você quer salvar o perfil de conexão (por exemplo, us-central1).
   • SOURCE_HOST_IP_ADDRESS pelo endereço IP privado da instância de origem do SQL Server (ou o endereço IP do listener do grupo de disponibilidade, se configurado para um grupo de disponibilidade de origem com várias réplicas).
   • SOURCE_PORT_NUMBER pelo número da porta em que o mecanismo de banco de dados do SQL Server de origem aceita conexões (padrão 1433).
   • SOURCE_DBM_PORT_NUMBER pelo número da porta TCP do endpoint de espelhamento de banco de dados de origem (padrão 5022).
   • SOURCE_USERNAME pelo nome de login dedicado do SQL que você criou na instância de origem em Criar o login e as permissões dedicados do Database Migration Service.
   • SOURCE_PASSWORD pela senha do login SOURCE_USERNAME.

2. Crie o perfil de conexão de destino.
   Execute o comando gcloud database-migration connection-profiles create sqlserver (clique para abrir):

   gcloud database-migration connection-profiles create sqlserver

   Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível pular a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

   gcloud database-migration connection-profiles create sqlserver DESTINATION_CONNECTION_PROFILE_ID \
       --no-async \
       --display-name=DESTINATION_CONNECTION_PROFILE_NAME \
       --region=REGION \
       --role=DESTINATION \
       --cloudsql-instance=CLOUDSQL_INSTANCE_ID \
       --host=DESTINATION_HOST_IP_ADDRESS \
       --port=DESTINATION_PORT_NUMBER \
       --dbm-port=DESTINATION_DBM_PORT_NUMBER \
       --username=sqlserver \
       --password=CLOUD_SQL_DB_USER_PASSWORD

   Substitua:

   • DESTINATION_CONNECTION_PROFILE_ID por um identificador legível por máquina para o perfil de conexão de destino (por exemplo, sqlserver-dag-dest-profile).
   • DESTINATION_CONNECTION_PROFILE_NAME com um nome legível por humanos para o perfil de conexão de destino. Esse valor é exibido no Database Migration Service no console do Google Cloud .
   • REGION pelo identificador da região em que você quer salvar o perfil de conexão.
   • CLOUDSQL_INSTANCE_ID pelo nome da instância de destino do Cloud SQL para SQL Server.
   • DESTINATION_HOST_IP_ADDRESS pelo endereço IP privado da instância de destino do Cloud SQL para SQL Server (ou o endereço IP do endpoint do Private Service Connect) que pode ser acessado pela instância de origem do SQL Server.
   • DESTINATION_PORT_NUMBER pelo número da porta do banco de dados da instância de destino do Cloud SQL para SQL Server (1433).
   • DESTINATION_DBM_PORT_NUMBER pelo número da porta do espelhamento de banco de dados da instância de destino do Cloud SQL para SQL Server (5022).
   • CLOUD_SQL_DB_USER_PASSWORD pela senha do usuário sqlserver na instância de destino do Cloud SQL para SQL Server (--username precisa ser definido como sqlserver).

3. Crie o job de migração contínua de DAG.
   Execute o comando gcloud database-migration migration-jobs create (clique para abrir):

   gcloud database-migration migration-jobs create

   Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível pular a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

   gcloud database-migration migration-jobs create MIGRATION_JOB_ID \
       --no-async \
       --display-name=MIGRATION_JOB_NAME \
       --region=REGION \
       --type=CONTINUOUS \
       --source=SOURCE_CONNECTION_PROFILE_ID \
       --destination=DESTINATION_CONNECTION_PROFILE_ID \
       --sqlserver-dag-source-ag=SOURCE_AVAILABILITY_GROUP_NAME \
       --sqlserver-dag-linked-server=LINKED_SERVER_NAME

   Substitua:

   • MIGRATION_JOB_ID por um identificador legível por máquina para o job de migração (por exemplo, sqlserver-dag-job).
   • MIGRATION_JOB_NAME por um nome legível por humanos para o job de migração. Esse valor é exibido no console do Google Cloud .
   • REGION pelo identificador da região em que você quer criar o job de migração.
   • SOURCE_CONNECTION_PROFILE_ID pelo identificador do perfil de conexão de origem.
   • DESTINATION_CONNECTION_PROFILE_ID pelo identificador do perfil de conexão de destino.
   • SOURCE_AVAILABILITY_GROUP_NAME pelo nome do grupo de disponibilidade na instância de origem do SQL Server.
   • LINKED_SERVER_NAME pelo nome do servidor vinculado que você configurou na instância de destino do Cloud SQL para SQL Server em Criar e verificar o servidor vinculado na instância de destino do Cloud SQL para SQL Server.

4. Verifique a configuração do job de migração.
   Antes de iniciar um job de migração de DAG, execute verify para validar a conectividade de rede bidirecional, o acesso RPC do servidor vinculado, as permissões de gcp_dms_db (se estiver usando privilégio mínimo), os proprietários do banco de dados de origem (verificando se nenhum banco de dados pertence a sa) e os caminhos de arquivo de dados padrão. Execute o comando gcloud database-migration migration-jobs verify (clique para abrir):

   gcloud database-migration migration-jobs verify

   gcloud database-migration migration-jobs verify MIGRATION_JOB_ID \
       --region=REGION

   Substitua:

   • MIGRATION_JOB_ID pelo identificador do job de migração.
   • REGION pelo identificador da região em que o job de migração está salvo.

   Para verificar o status da operação de verificação, execute o comando gcloud database-migration operations describe.

5. Inicie o job de migração.
   Depois que a verificação for concluída, execute o comando gcloud database-migration migration-jobs start (clique para abrir):

   gcloud database-migration migration-jobs start

   gcloud database-migration migration-jobs start MIGRATION_JOB_ID \
       --region=REGION

   Substitua:

   • MIGRATION_JOB_ID pelo identificador do job de migração.
   • REGION pelo identificador da região em que o job de migração está salvo.
   Atenção: quando você inicia o job de migração do DAG, o Database Migration Service define automaticamente a flag cloud sql enable dag support como on na instância de destino do Cloud SQL para SQL Server. Não modifique ou remova manualmente a flag cloud sql enable dag support.

Monitorar e verificar sua migração

Enquanto o job de migração do DAG estiver em execução, será possível monitorar o progresso no console do Google Cloud , consultar os bancos de dados de destino no modo somente leitura durante o CDC e gerenciar a replicação ativa.

Monitorar o progresso no console do Google Cloud

É possível monitorar um job de migração de DAG em execução no console do Google Cloud na página Detalhes do job de migração, assim como outros jobs de migração do Database Migration Service:

• Na tabela Bancos de dados da página de detalhes do job de migração, confira a fase em tempo real (Full dump durante o carregamento completo inicial, CDC durante a replicação contínua e todas as mensagens de erro no nível do banco de dados) e o Atraso de restauração de cada banco de dados no grupo de disponibilidade.
• Na guia Monitoramento, confira o gráfico Atraso de restauração (datamigration.googleapis.com/migration_job/max_replica_sec_lag, que informa o atraso de replicação do grupo de disponibilidade distribuído em segundos por banco de dados).

Para mais informações sobre métricas de monitoramento e estados de jobs, consulte Métricas de jobs de migração e Códigos de status de jobs de migração.

Verificar bancos de dados migrados no modo somente leitura durante a CDC

Ao contrário das migrações baseadas em backup (em que os bancos de dados de destino permanecem no estado RESTORING até a promoção), as migrações de grupo de disponibilidade distribuído permitem consultar os bancos de dados de destino do Cloud SQL para SQL Server no modo somente leitura assim que eles entram na fase CDC.

Para cada banco de dados de um login do SQL na instância de origem, o Database Migration Service cria automaticamente um login na instância de destino do Cloud SQL para SQL Server com o prefixo gcp_dms_, um identificador de seis caracteres e o nome do proprietário de origem (por exemplo, gcp_dms_a1b2c3_myowner). Para consultar o banco de dados com esse login antes da promoção, conecte-se à instância de destino do Cloud SQL para SQL Server como sqlserver, encontre o nome de login gerado em sys.server_principals e redefina a senha:

SELECT name FROM sys.server_principals WHERE name LIKE 'gcp_dms_%';
GO
ALTER LOGIN [GENERATED_DMS_OWNER_LOGIN] WITH PASSWORD = 'NEW_OWNER_PASSWORD';
GO

Substitua:

• GENERATED_DMS_OWNER_LOGIN pelo nome de login do proprietário do banco de dados gerado retornado pela consulta.
• NEW_OWNER_PASSWORD por uma nova senha para o login.

Para mais informações sobre como verificar objetos e dados migrados, consulte Verificar uma migração.

Gerenciar um job de migração de DAG ativo (opcional)

Enquanto o job de migração estiver em execução na fase CDC, será possível realizar as seguintes operações de gerenciamento:

• Adicione ou remova bancos de dados no grupo de disponibilidade de origem na instância de origem do SQL Server executando ALTER AVAILABILITY GROUP ... ADD DATABASE ou ALTER AVAILABILITY GROUP ... REMOVE DATABASE. O Database Migration Service detecta automaticamente a alteração no próximo ciclo de sondagem e atualiza a instância de destino do Cloud SQL para SQL Server.
• Interrompa temporariamente a replicação de dados executando gcloud database-migration migration-jobs stop. A interrupção de um job de migração de DAG só deve ser usada por um período curto e definido, porque as atualizações continuam se acumulando nos registros de transações enquanto a replicação é interrompida, o que pode fazer com que os discos de registro de transações fiquem cheios. Em um estado interrompido, é possível executar gcloud database-migration migration-jobs resume para retomar a replicação de dados ou executar gcloud database-migration migration-jobs delete para concluir a migração e realizar a limpeza necessária.
• Reinicie um job de migração com falha executando gcloud database-migration migration-jobs restart. Reiniciar um job de migração de DAG exclui os bancos de dados migrados na instância de destino do Cloud SQL para SQL Server, recria o grupo de disponibilidade distribuído e executa novamente o carregamento completo inicial na rede.

Promover, fazer failback ou concluir a migração

Quando estiver tudo pronto para trocar seus aplicativos para o Cloud SQL para SQL Server, promova o job de migração. Em uma migração de DAG, promover o job muda o Cloud SQL para SQL Server para o primário de leitura/gravação e faz a transição do job de migração para a fase FAILBACK (PHASE_FAILBACK na Google Cloud CLI e nas respostas da API) com replicação reversa ativa de volta para a instância de origem do SQL Server:

1. Interrompa as gravações do aplicativo nos bancos de dados de origem do SQL Server e verifique a métrica Atraso de restauração no console do Google Cloud para confirmar se o atraso de replicação chegou a zero.

2. Promova o job de migração para fazer a transição para o Cloud SQL.
   Execute o comando gcloud database-migration migration-jobs promote (clique para abrir):

   gcloud database-migration migration-jobs promote

   gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
       --region=REGION

   Substitua:

   • MIGRATION_JOB_ID pelo identificador do job de migração.
   • REGION pelo identificador da região em que o job de migração está salvo.

   Durante a promoção, o Database Migration Service realiza as seguintes ações:

   • Define o grupo de disponibilidade distribuído como confirmação síncrona, emite um CHECKPOINT em todos os bancos de dados de origem, aguarda a sincronização de todas as transações com zero perda de dados e reverte os papéis do grupo de disponibilidade para que sua instância de destino do Cloud SQL para SQL Server se torne a principal de leitura/gravação e sua instância de origem original do SQL Server se torne a secundária.
   • Mantém o job de migração no estado Running e faz a transição do subestado para a fase FAILBACK (PHASE_FAILBACK na Google Cloud CLI e nas respostas da API), replicando continuamente novas gravações do Cloud SQL para SQL Server de destino de volta para a instância de origem do SQL Server.

   Depois que a promoção for concluída, conecte os aplicativos à nova instância do Cloud SQL para SQL Server.

3. (Opcional) Faça o failback para a instância de origem do SQL Server.
   Se você encontrar um problema depois de mudar seus aplicativos para o Cloud SQL para SQL Server enquanto o job de migração estiver na fase FAILBACK, reverta a transição sem perda de dados interrompendo as gravações do aplicativo no Cloud SQL para SQL Server e executando o comando gcloud database-migration migration-jobs promote com a flag --failback (clique para expandir):

   gcloud database-migration migration-jobs promote --failback

   gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
       --region=REGION \
       --failback

   Substitua:

   • MIGRATION_JOB_ID pelo identificador do job de migração.
   • REGION pelo identificador da região em que o job de migração está salvo.

   Executar promote com a flag --failback durante a fase FAILBACK sincroniza todas as mudanças gravadas no Cloud SQL para SQL Server, alterna a direção de replicação novamente para que o grupo de disponibilidade do SQL Server de origem original se torne o principal de leitura/gravação e o Cloud SQL para SQL Server se torne o secundário, além de retornar o job de migração para a fase CDC. O --failback só é válido quando o job de migração está na fase FAILBACK. Executar promote sem --failback durante a fase FAILBACK (ou transmitir --failback durante a fase CDC) falha na validação com um erro FAILED_PRECONDITION e deixa o job de migração em execução.

4. (Opcional) Interrompa a replicação de dados antes de excluir o job de migração.
   Se você quiser interromper a replicação de dados antes de excluir permanentemente o job de migração, execute o comando gcloud database-migration migration-jobs stop (clique para expandir):

   gcloud database-migration migration-jobs stop

   gcloud database-migration migration-jobs stop MIGRATION_JOB_ID \
       --region=REGION

   Substitua:

   • MIGRATION_JOB_ID pelo identificador do job de migração.
   • REGION pelo identificador da região em que o job de migração está salvo.
   Atenção: interromper um job de migração interrompe a replicação de dados, mas só deve ser usado por um período curto e definido, porque as atualizações continuam a se acumular nos registros de transações enquanto a replicação é interrompida. Em um estado Stopped, é possível executar gcloud database-migration migration-jobs resume para retomar a replicação de dados ou executar gcloud database-migration migration-jobs delete na próxima etapa para concluir a migração e realizar a limpeza necessária.

5. Conclua a migração e exclua o job de migração.
   Depois de verificar se os aplicativos estão totalmente operacionais com a nova instância de destino do Cloud SQL para SQL Server e que você não precisa mais da replicação reversa para a instância de origem do SQL Server, exclua o job de migração (do estado Running ou Stopped) para concluir a migração e realizar a limpeza necessária. Execute o comando gcloud database-migration migration-jobs delete (clique para abrir):

   gcloud database-migration migration-jobs delete

   Esse comando retorna um prompt de confirmação interativo que requer sua entrada para ser concluído. É possível pular a solicitação de confirmação usando a flag opcional --quiet.

   gcloud database-migration migration-jobs delete MIGRATION_JOB_ID \
       --region=REGION

   Substitua:

   • MIGRATION_JOB_ID pelo identificador do job de migração.
   • REGION pelo identificador da região em que o job de migração está salvo.

   A exclusão do job de migração conclui a migração, interrompe qualquer replicação reversa ativa, descarta os certificados do grupo de disponibilidade distribuído e do espelhamento de banco de dados em ambas as instâncias e permite ativar os recursos do Cloud SQL para SQL Server que são restritos durante a replicação do DAG (como recuperação pontual (PITR) ou réplicas de leitura).

   Depois de excluir o job de migração, é possível desativar ou remover a flag de banco de dados cloud sql enable dag support na instância de destino do Cloud SQL para SQL Server, descartar o servidor vinculado na instância do Cloud SQL para SQL Server (EXEC master.dbo.sp_dropserver @server = N'LINKED_SERVER_NAME', @droplogins = 'droplogins';) e remover o banco de dados auxiliar gcp_dms_db e o login de migração na instância de origem do SQL Server.