Um desenvolvedor disse que eu deveria simplesmente agrupar todos os meus scripts de atualização de banco de dados em uma transação. Se falhar, basta reverter todas as alterações. Todos os meus instintos me dizem que isso é errado, especialmente quando se trata de lidar com grandes volumes de dados e/ou procedimentos e funções.
Eu normalmente mantenho o processo de atualização em bancos de dados de instância única da seguinte maneira:
- Negociar uma janela de manutenção
- Preparar scripts de atualização
- Colocar banco de dados em modo de usuário restrito
- Desabilita trabalhos/processos agendados que normalmente atingiriam o banco de dados durante esta janela
- Faça um backup completo
- Aplicar os scripts de atualização
- Faça com que o desenvolvedor ou a equipe de teste confirme se o aplicativo funciona conforme o esperado
- Coloque o banco de dados de volta no modo multiusuário
- Liberar o banco de dados para uso normal
No entanto, quando se trata de implementar alterações em várias centenas de instâncias, alterei meu processo da seguinte maneira:
Torno os scripts de atualização muito mais robustos: eles podem ser executados várias vezes no mesmo servidor sem danos, os números da versão do banco de dados são respeitados, os scripts serão encerrados se forem executados na versão de execução, etc.
gerar um processo para cada servidor (usando powershell, osql, etc)
- execute o script de atualização apropriado
- relatar sucesso ou falha
Não existe um processo padrão porque cada sistema é diferente. A última coisa que eu faria seria agrupar tudo em uma única transação. O que acontece se eu precisar mover 500 Gigs de dados? Essa é uma transação massiva.
Recentemente, tenho usado instantâneos de banco de dados como minha reversão.
Basicamente, tire um instantâneo, faça as alterações. Exclua o instantâneo após a aprovação. Se a atualização falhou, reverta o instantâneo e tente novamente.
É muito mais rápido reverter um instantâneo do que restaurar o banco de dados (supondo que o banco de dados seja grande).