Alterar o esquema sem quebrar aplicações ativas

Uma migração pode terminar corretamente enquanto o aplicativo falha. Durante uma implantação gradual, versões antigas e novas compartilham o banco. Renomear uma coluna ou exigir imediatamente um campo novo pode quebrar processos ainda ativos. A unidade de mudança é o contrato entre código e dados.

Expandir antes de exigir

Adicione estrutura compatível, publique código que entenda ambas as formas, complete o histórico, valide e retire o contrato antigo depois. Uma coluna nullable costuma ser um bom começo, mas ainda exige bloqueios de esquema. Mudança pequena não garante ausência de bloqueio.

O exercício usa uma tabela temporária pequena. Execute blocos em ordem. NOT NULL representa uma etapa separada de validação e liberação, não uma ação automática após adicionar a coluna.

CREATE TABLE #Orders(OrderId int PRIMARY KEY, Amount decimal(12,2));
INSERT #Orders VALUES(1,10),(2,20);
ALTER TABLE #Orders ADD CurrencyCode char(3) NULL;

UPDATE #Orders SET CurrencyCode='USD' WHERE CurrencyCode IS NULL;
SELECT OrderId,Amount,CurrencyCode FROM #Orders ORDER BY OrderId;

IF EXISTS(SELECT 1 FROM #Orders WHERE CurrencyCode IS NULL)
    THROW 50000, 'Backfill is incomplete.', 1;
ALTER TABLE #Orders ALTER COLUMN CurrencyCode char(3) NOT NULL;

Em produção, defina como novas escritas preenchem CurrencyCode antes de concluir o histórico. USD só está correto pelo significado declarado do exercício. Um default conveniente não descobre a moeda real de pedidos antigos. Valores desconhecidos precisam de reconciliação.

Coordenar escrita concorrente

Quando representações coexistem, estabeleça qual é autoritativa em cada fase. Escritas duplas devem ser atômicas ou reconciliadas. Uma falha pode alterar somente uma representação. Uma leitura alternativa pode preservar disponibilidade enquanto esconde divergência; meça desacordos antes de mudar leitores.

Em tabelas grandes, use lotes retomáveis com faixa estável de chaves. O predicado não pode sobrescrever valores mais recentes do aplicativo. Confirme progresso com as alterações quando precisar sobreviver a falhas. Limitar linhas alteradas não limita automaticamente leituras ou log gerado por índices e triggers.

Mudanças de esquema podem esperar atrás de transações longas. Defina timeout e repetição adequados, examine bloqueadores e não lance outra migração enquanto a anterior espera. Opções online dependem de operação, versão e edição; não significam ausência total de bloqueios.

Definir a fronteira de retorno

Antes de remover, confirme que nenhuma versão suportada, relatório, job, exportação ou SQL dinâmico depende do campo antigo. Catálogos ajudam, mas não encontram todas as strings montadas externamente. Combine inventário, execução observada e testes com versões misturadas.

Reverter código é simples somente enquanto o banco mantém seu contrato. Novas escritas podem conter valores impossíveis de representar no modelo antigo. Voltar então perde significado mesmo com a coluna antiga presente. Documente a última etapa reversível e a recuperação preservando dados após esse ponto.

Valide valores transformados, restrições e operações típicas das duas versões, não apenas contagens. Interrompa o preenchimento e teste retomada. Guarde identificadores e estado para distinguir passos aplicados de falhas.

A remoção final deve ser outra liberação após estabilidade comprovada. Teste também um processo antigo ativo durante toda a transição, pois reiniciar tudo no laboratório esconde problemas de coexistência. Verifique se pools de conexão e jobs noturnos ainda usam o contrato anterior. Cada fase precisa explicar quem lê, quem escreve, qual dado vale e qual retorno permanece seguro.

Referências técnicas: Microsoft Learn: ALTER TABLE · Microsoft Learn: Dependency metadata.