Database Migration Service pode reduzir o disco do Cloud SQL for SQL Server com downtime mínimo
Aprofundamento CEVIU
Aprofundamento
O ponto central do post do Google Cloud é tratar o Database Migration Service (DMS) como ferramenta de day-two, e não só de onboarding. O DMS aceita o Cloud SQL for SQL Server como origem e replica de forma contínua entre instâncias, no mesmo projeto, entre projetos ou entre regiões. Isso permite criar uma instância nova com disco menor e migrar para ela com o aplicativo no ar.
O mecanismo lembra o log shipping nativo do SQL Server: o DMS captura um backup full (.bak) dos bancos de usuário, restaura no destino e depois aplica continuamente backups de log de transações (.trn). Como a sincronização ocorre no nível do banco de usuário, logins, linked servers e jobs do SQL Server Agent não vão junto e precisam ser migrados à mão. O fluxo é: provisionar o destino com disco menor (com folga para logs e crescimento), iniciar o job contínuo, deixar a replicação alcançar a origem e fazer um cutover curto (parar o tráfego, aplicar o último log, promover o destino no DMS e redirecionar a aplicação).
O post lista o que entra no runbook: scripts de logins com sp_help_revlogin, jobs do Agent, linked servers (com a flag cloudsql.linked_servers ativa), extended events, certificado TDE exportado e importado, configurações como database flags, Active Directory e Entra ID, e re-criptografia da DMK se houver Polybase. Depois do cutover, usuários órfãos aparecem quando os SIDs dos logins diferem, e a correção é um ALTER USER em cada banco. Para achar a oportunidade, o texto sugere comparar database/disk/bytes_used com database/disk/quota no Cloud Monitoring.
Por que isso importa
Para quem opera SQL Server no Cloud SQL com SLA apertado, a conta é simples: o shrink nativo exige downtime proporcional ao disco alocado, o que em discos de vários terabytes pode virar horas. O DMS troca isso por um cutover curto, ao custo de mais trabalho de preparação com objetos de servidor e usuários órfãos. Vale pesar esse esforço contra a economia mensal de armazenamento antes de decidir.
Perguntas frequentes
Por que o disco do Cloud SQL não diminui depois de um DBCC SHRINKFILE?
O shrink dos arquivos (.mdf, .ndf, .ldf) libera espaço dentro do SQL Server, mas o disco persistente do Cloud SQL continua na capacidade de pico alocada. Para pagar menos, é preciso reduzir o próprio disco, pelo recurso nativo ou migrando para uma instância menor.
Qual a diferença entre o shrink nativo e o uso do DMS?
O shrink nativo do Cloud SQL exige downtime proporcional ao tamanho total do disco alocado, o que pode levar horas em discos de vários terabytes. O DMS replica para uma nova instância com disco menor enquanto a aplicação segue online e exige só uma janela breve de cutover.
O DMS migra logins e jobs do SQL Server Agent?
Não. A replicação ocorre no nível do banco de usuário, então logins, linked servers, jobs do Agent e extended events precisam ser criados manualmente no destino antes do cutover. As configurações da instância, como database flags e Active Directory, também precisam ser igualadas.
Como identificar se vale a pena reduzir o disco?
O post sugere acompanhar no Cloud Monitoring as métricas database/disk/bytes_used e database/disk/quota. Se a cota provisionada for bem maior que o uso real, e o banco não deve crescer até lá, há oportunidade de reduzir.
Fontes
- cloud.google.comfonte original
- Categoria
- CEVIU Dados
- Publicado
- 02 de novembro de 2026
- Editoria
- CEVIU Dados