Tantas vezes fui contratado no final de um esforço de desenvolvimento de software e ouvi algo como "ok, temos todo esse novo código e requer que as tabelas sejam alteradas e os dados sejam migrados".
Parece que toda vez é um cenário único, disparado do quadril e melhor adivinhado. Eu sinto que esta é a minha habilidade mais fraca como DBA.
Eu gostaria de entrar em alguns padrões para abordar, gerenciar e testar migrações de dados .
Por favor, indique-me algumas das melhores práticas e/ou onde posso obter material de aprendizagem para me ajudar a melhorar nesta área.
Toda vez que fiz isso, passamos por duas passagens ...
Então, durante um fim de semana, você tem uma interrupção programada:
Com nossa programação, o pessoal do banco de dados geralmente tinha das 18h na sexta-feira às 10h no sábado para executar os scripts de backup e migração, então nosso objetivo era que eles rodassem em menos de 8 horas (~ 6 delas eram backups), então nós d ter algum tempo para nossos testes e correções antes de ser liberado para as partes interessadas.
As partes interessadas receberam suas janelas de tempo com antecedência, então elas sabiam que deveriam deixar seu fim de semana aberto para testes no início da janela. Eles também seriam informados do fim de sua janela, normalmente na tarde de domingo, onde, se todos não tivessem assinado, teríamos que começar a reverter.
Ah, e claro... se alguém tivesse uma mudança durante qualquer um dos testes de aceitação e nós fizéssemos uma mudança, isso significava que todas as aprovações da parte interessada seriam anuladas e eles teriam que testar novamente... então tentaríamos dar a eles um tempo para procurar problemas e executar as correções como um lote, em vez de aplicá-los um de cada vez.
Felizmente, nas únicas vezes em que tive uma dessas situações em que não poderíamos ter um tempo de inatividade significativo, os sistemas que eu estava migrando eram alimentados por scripts, não pela entrada do usuário, então eu poderia apenas ter dois sistemas paralelos funcionando e trocá-los quando as coisas foram assinadas. (apenas uma vez houve um problema, quando meu chefe insistiu que fizéssemos um backup completo, sem entender que a coisa toda ainda estaria online em um IP diferente ... então o que deveria ter sido uma interrupção de 5 minutos em um dia ruim tornou-se uma interrupção de 5 horas.)
Tudo depende do volume de dados em comparação com a potência do hardware que suporta o banco de dados e os acordos sobre a disponibilidade do sistema. Por acaso você tem algum tempo de inatividade ou tudo deve ser feito online? Comece a limpar os dados, eliminando as linhas desatualizadas o máximo possível. Este é um projeto em si. Se os dados estiverem limpos e valiosos, faça com que o usuário decida sobre o tempo de inatividade. Se o tempo de inatividade estiver disponível, é bastante simples, se for uma transformação conhecida que deve ser aplicada nos dados existentes para formar a coleção atualizada. Se não houver - ou muito pouco - tempo de inatividade permitido, o desafio começa. O Oracle oferece suporte a isso de algumas maneiras, como redefinição de tabela on-line e - novo em 11g - redefinição baseada na edição. Com a redefinição de mesas online pode preparar as mesas para assumirem a sua nova forma. Isso pode ser feito enquanto o aplicativo está sendo executado no formato antigo da(s) tabela(s). Se estiverem todos prontos, você pode mudar para a nova forma da(s) tabela(s). Este será também o momento de introduzir o novo código de aplicação e ao mesmo tempo marca o início do tempo de inatividade necessário para colocar a nova aplicação em funcionamento. Os dados históricos mais antigos podem ser preparados antes da migração dos dados ativos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você cria efetivamente um novo banco de dados que assume a função do banco de dados antigo. A redefinição baseada em edição é mais adequada se nenhuma alteração na tabela for necessária. Existem inúmeras opções a serem consideradas e acho que é difícil dar uma boa regra que sempre funcione. Este será também o momento de introduzir o novo código de aplicação e ao mesmo tempo marca o início do tempo de inatividade necessário para colocar a nova aplicação em funcionamento. Os dados históricos mais antigos podem ser preparados antes da migração dos dados ativos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você cria efetivamente um novo banco de dados que assume a função do banco de dados antigo. A redefinição baseada em edição é mais adequada se nenhuma alteração na tabela for necessária. Existem inúmeras opções a serem consideradas e acho que é difícil dar uma boa regra que sempre funcione. Este será também o momento de introduzir o novo código de aplicação e ao mesmo tempo marca o início do tempo de inatividade necessário para colocar a nova aplicação em funcionamento. Os dados históricos mais antigos podem ser preparados antes da migração dos dados ativos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você cria efetivamente um novo banco de dados que assume a função do banco de dados antigo. A redefinição baseada em edição é mais adequada se nenhuma alteração na tabela for necessária. Existem inúmeras opções a serem consideradas e acho que é difícil dar uma boa regra que sempre funcione. Os dados históricos mais antigos podem ser preparados antes da migração dos dados ativos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você cria efetivamente um novo banco de dados que assume a função do banco de dados antigo. A redefinição baseada em edição é mais adequada se nenhuma alteração na tabela for necessária. Existem inúmeras opções a serem consideradas e acho que é difícil dar uma boa regra que sempre funcione. Os dados históricos mais antigos podem ser preparados antes da migração dos dados ativos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você cria efetivamente um novo banco de dados que assume a função do banco de dados antigo. A redefinição baseada em edição é mais adequada se nenhuma alteração na tabela for necessária. Existem inúmeras opções a serem consideradas e acho que é difícil dar uma boa regra que sempre funcione.
É um assunto interessante, Ronald.
Boas respostas até agora. Vou adicionar mais alguns pontos para consideração.
Primeiro, quando você pode fazer suas migrações com SQL DML simples, pode confiar amplamente em seu mecanismo SQL para garantir que todas as linhas sejam processadas com êxito. Eu estive envolvido em migrações, porém, onde algumas das migrações foram um pouco mais complicadas -- houve transformações de dados reais quando os dados foram movidos para uma nova estrutura. Nesses casos, é importante que você tenha um processo que dê conta dos seguintes itens:
O outro ponto que eu acrescentaria é que é importante ter um plano para o que você fará se/quando as coisas não saírem como planejado. Essa é realmente uma função da implantação como um todo, mas parece ser minimizada com frequência suficiente para que eu achasse que valia a pena mencioná-la.
Uma visão geral de como fazer
Começar com
Em seguida, baixe o Red Gate Compare tools ou algo como Embarcadero SQL Change manager . Você não pode migrar facilmente sem ele. O custo é insignificante em relação ao tempo economizado. E o mais importante, os scripts gerados fazem alterações em uma única transação, o que significa uma implantação limpa
Agora,
Agora, você tem scripts de alteração e reversão testados e seguros para aplicar a qualquer momento.
E é claro que você faz backup do banco de dados antes de qualquer alteração porque, estatisticamente, a merda sempre acontecerá eventualmente.
As ferramentas do Red Gate também podem ser comparadas com uma pasta que está sob controle de origem. Em seguida, capturamos os ALTERs etc em nosso controle de origem separadamente para os scripts de alteração reais.