Otimizando o Gerenciamento de Armazenamento do SQL Server com o Database Migration Service
A migração de bancos de dados é frequentemente associada à transferência de dados entre ambientes, seja do local para a nuvem ou entre diferentes provedores. No entanto, o Database Migration Service (DMS) do Google Cloud vai além, oferecendo funcionalidades avançadas para a gestão de instâncias de SQL Server já na nuvem. Especificamente, o DMS suporta o Cloud SQL para SQL Server como fonte, abrindo portas para padrões operacionais inovadores. Sua capacidade de replicar dados continuamente e com baixa interrupção entre instâncias do Cloud SQL — dentro do mesmo projeto, entre projetos ou regiões — o transforma em uma ferramenta poderosa para operações do dia a dia, incluindo a otimização de armazenamento.
Este artigo explora um caso de uso operacional significativo para o DMS com Cloud SQL para SQL Server: a execução de reduções de disco (shrinking) com tempo de inatividade minimizado para as aplicações.
Por que reduzir o tamanho do disco?
Em ambientes de produção, o espaço em disco dos bancos de dados tende a aumentar. Recursos como o aumento automático de armazenamento do Cloud SQL são cruciais para evitar interrupções por falta de espaço, especialmente durante picos de tráfego inesperados, grandes importações de dados, manutenção de índices ou cargas temporárias de staging. Ao longo do ciclo de vida de uma aplicação, é comum arquivar registros históricos, purgar dados obsoletos ou remover índices não utilizados.
Quando dados são excluídos, o SQL Server marca o espaço liberado dentro dos arquivos de dados (.mdf, .ndf) como reutilizável. Da mesma forma, a truncagem de logs libera espaço nos arquivos de log de transação (.ldf). Contudo, os arquivos do banco de dados, por si só, continuam a ocupar o espaço máximo utilizado anteriormente, a menos que a opção AUTO_SHRINK seja configurada. Esta configuração, no entanto, geralmente não é recomendada em produção devido ao risco de fragmentação severa de índices e sobrecarga de desempenho.
Uma operação manual de redução (shrink) nos arquivos do banco de dados, utilizando o comando DBCC SHRINKFILE, permite liberar o espaço não utilizado de volta para o disco subjacente. Mesmo após a redução dos arquivos do banco de dados, o disco persistente do Cloud SQL mantém sua capacidade alocada original. Se você não prevê que o banco de dados necessitará desse espaço em um futuro próximo, reduzir o disco em si é uma medida inteligente para diminuir custos contínuos de armazenamento. Cenários comuns para essa otimização incluem:
- Após arquivamento ou purga massiva de dados: Dados históricos foram permanentemente movidos para armazenamento frio ou BigQuery, e o conjunto de dados ativo agora representa uma fração do tamanho máximo anterior.
- Recuperação de picos de armazenamento pontuais: Uma transação descontrolada, uma grande migração de dados ou uma carga de staging temporária acionou o auto-aumento de armazenamento, resultando em pagamento por terabytes de capacidade de disco provisionada que não são mais necessários.
- Pós-refatoração ou otimização de esquema: Tabelas foram divididas de um banco de dados monolítico para serviços separados, grandes índices não utilizados foram removidos, ou a compressão de dados foi aplicada.
A consulta abaixo ajuda a inspecionar tanto a capacidade alocada quanto o espaço livre disponível para cada arquivo de banco de dados:
SELECT
DB_NAME() AS [DatabaseName],
name AS [LogicalName],
type_desc AS [FileType],
-- Tamanho alocado em disco (convertido de páginas de 8KB para MB)
CAST(size / 128.0 AS DECIMAL(18, 2)) AS [AllocatedSize_MB],
-- Espaço realmente utilizado dentro do arquivo
CAST(FILEPROPERTY(name, 'SpaceUsed') / 128.0 AS DECIMAL(18, 2)) AS [UsedSpace_MB],
-- Espaço livre restante no arquivo alocado
CAST((size - FILEPROPERTY(name, 'SpaceUsed')) / 128.0 AS DECIMAL(18, 2)) AS [FreeSpace_MB],
-- Porcentagem do espaço alocado que está em uso
CAST((FILEPROPERTY(name, 'SpaceUsed') * 100.0) / size AS DECIMAL(18, 2)) AS [SpaceUsed_Percent]
FROM sys.database_files;
É possível monitorar métricas chave do Cloud SQL no Cloud Monitoring para identificar se sua cota de disco provisionado excede significativamente o uso real, indicando uma oportunidade de redução:
database/disk/bytes_used: Rastrea a quantidade real de espaço em disco atualmente consumida pelos arquivos e logs do seu banco de dados.database/disk/quota: Representa a capacidade total de disco provisionada alocada para a sua instância.
O Cloud SQL oferece um recurso nativo de redução de armazenamento para recuperar esse espaço em disco não alocado. Essa funcionalidade é eficaz quando sua carga de trabalho permite uma janela de manutenção planejada. No entanto, a redução nativa de disco exige um tempo de inatividade da instância proporcional ao tamanho total do disco alocado, o que pode significar horas de manutenção offline para discos de múltiplos terabytes.
Se os SLAs de produção não comportam tempos de inatividade prolongados, o Database Migration Service (DMS) apresenta uma alternativa com tempo de inatividade minimizado. Ao replicar continuamente seus bancos de dados para uma nova instância do Cloud SQL provisionada com um disco menor e dimensionado corretamente, é possível recuperar o armazenamento não utilizado enquanto a aplicação permanece online, exigindo apenas uma breve janela de corte (cutover). Para entender como essa abordagem resulta em uma janela de corte tão curta, vamos examinar o mecanismo de replicação de dados do DMS entre instâncias do Cloud SQL para SQL Server.
Como o DMS funciona: Replicação entre Instâncias do Cloud SQL para SQL Server
Para aproveitar o DMS de forma eficaz, é fundamental compreender seu mecanismo de replicação subjacente. Ao migrar entre instâncias do Cloud SQL para SQL Server, o DMS coordena um processo de sincronização que se assemelha ao log shipping nativo do SQL Server:
- Backup completo inicial: O DMS captura um backup completo inicial (.bak) das bases de dados selecionadas e as restaura na instância de destino.
- Backups contínuos de log: Em seguida, ele captura e aplica continuamente backups de log de transação (.trn) para manter a instância de destino sincronizada em tempo quase real.
Como a sincronização ocorre no nível das bases de dados de usuário, objetos que residem fora delas — como logins, servidores vinculados e trabalhos do SQL Server Agent — não são replicados automaticamente para a instância de standby. Consequentemente, objetos em nível de servidor devem ser migrados manualmente.
Redução de disco com tempo de inatividade mínimo
Utilizando esse pipeline de replicação contínua, é possível recuperar o armazenamento não alocado sem exigir um longo período de inatividade...
chat_bubble Comentários (0)
Nenhum comentário ainda. Seja o primeiro a comentar!
Deixe seu comentário