Qual é o seu fluxo de trabalho para planejar uma migração de dados?

Tantas vezes fui apresentado no final de um esforço de desenvolvimento de software e me disseram algo como "ok, temos todo esse novo código e ele exige que as tabelas sejam alteradas e que os dados sejam migrados".

Parece que toda vez que se trata de um cenário único, chute do quadril e melhor palpite. Sinto que essa é minha habilidade mais fraca como DBA.

Gostaria de entrar em alguns padrões para abordar, gerenciar e testar migrações de dados .

Por favor, indique-me algumas práticas recomendadas e / ou onde posso obter material de aprendizagem para me ajudar a melhorar nesta área.

Toda vez que faço isso, passamos por dois passes ...

1. tire um instantâneo e, trabalhando em um servidor diferente, use-o para determinar o que deve ser feito para a migração e faça um script.
2. depois de ter o script em mãos, o snapshop é restaurado no sistema de teste e é cronometrado para verificar se ele será executado dentro do tempo necessário ou se é ajustado e modificado até que seja possível.
3. faça com que as partes interessadas assinem que nada parece errado com os dados no sistema de teste.

Em um fim de semana, você terá uma interrupção programada:

1. Sexta à noite, os sistemas que usam o banco de dados são desativados, é feito um backup completo a frio e os scripts são executados para migrar / modificar / o que quer que seja para os dados
2. Os sistemas são recuperados sob algum endereço privado ou de alguma forma configurados, para que não sejam abertos a ninguém, exceto às partes interessadas para teste de aceitação
3. Se as partes interessadas aprovarem, o sistema será colocado online e tornado público; caso contrário, o banco de dados é restaurado a partir do backup feito na sexta-feira à noite e você inicia o processo novamente.

De acordo com nossa programação, o pessoal do banco de dados geralmente tinha das 18:00 na sexta-feira às 10:00 no sábado para executar os scripts de backup e migraçã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 serem liberados para as partes interessadas.

As partes interessadas receberam suas janelas de tempo com antecedência, então sabiam deixar o fim de semana aberto para testes no início da janela. Eles também seriam informados no final da janela, normalmente na tarde de domingo, onde, se todos não tivessem terminado, teríamos que começar a retroceder.

Ah, e claro ... se alguém teve uma mudança durante um dos testes de aceitação, e nós fizemos uma mudança, isso significava que todas as assinaturas das partes interessadas foram anuladas e elas tiveram que fazer um novo teste ... tentaríamos dar um tempo para procurar problemas e executar as correções em lote, em vez de aplicá-las uma por vez.

Felizmente, nas únicas vezes em que tive uma dessas situações em que não pudemos ter um tempo de inatividade significativo, os sistemas que eu estava migrando foram alimentados a partir de scripts, não da entrada do usuário, para que eu pudesse ter dois sistemas paralelos em funcionamento e trocá-los quando as coisas foram assinadas. (apenas uma vez houve um problema, quando meu chefe insistiu em fazer um backup completo, sem entender que tudo continuaria online com um IP diferente ... então o que deveria ter sido uma interrupção de 5 minutos em um dia ruim se tornou uma interrupção de 5 horas.)

Tudo depende do volume de dados comparado ao poder do hardware que suporta o banco de dados e aos acordos sobre a disponibilidade do sistema. Você tem algum tempo de inatividade ou tudo deve ser feito online? Comece a limpar os dados, apagando as linhas desatualizadas o máximo possível. Este é um projeto em si. Se os dados forem limpos e valiosos, peça ao usuário que decida sobre o tempo de inatividade. Se o tempo de inatividade estiver disponível, é bastante simples, se é uma transformação conhecida que deve ser aplicada aos dados existentes para formar a coleção atualizada. Se não houver - ou muito pouco - tempo de inatividade permitido, o desafio começará. A Oracle suporta isso de várias maneiras, como redefinição de tabela on-line e - nova na 11g - redefinição baseada na edição. Com a redefinição de tabela on-line, você pode preparar as tabelas para assumir sua nova forma. Isso pode ser feito enquanto o aplicativo está sendo executado na forma antiga da tabela [s]. Se todos estiverem prontos, você pode mudar para o novo formulário da tabela [s]. Este também será o momento de introduzir o novo código do aplicativo e, ao mesmo tempo, marcar o início do tempo de inatividade necessário para colocar o novo aplicativo no lugar. Os dados históricos mais antigos podem ser preparados antes da migração dos dados dinâmicos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você efetivamente cria 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 de tabela for necessária. Há muitas opções a considerar e acho difícil definir uma boa regra que sempre funcione. Este também será o momento de introduzir o novo código do aplicativo e, ao mesmo tempo, marcar o início do tempo de inatividade necessário para colocar o novo aplicativo no lugar. Os dados históricos mais antigos podem ser preparados antes da migração dos dados dinâmicos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você efetivamente cria 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 de tabela for necessária. Há muitas opções a considerar e acho difícil definir uma boa regra que sempre funcione. Este também será o momento de introduzir o novo código do aplicativo e, ao mesmo tempo, marcar o início do tempo de inatividade necessário para colocar o novo aplicativo no lugar. Os dados históricos mais antigos podem ser preparados antes da migração dos dados dinâmicos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você efetivamente cria 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 de tabela for necessária. Há muitas opções a considerar e acho difícil definir uma boa regra que sempre funcione. Os dados históricos mais antigos podem ser preparados antes da migração dos dados dinâmicos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você efetivamente cria 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 de tabela for necessária. Há muitas opções a considerar e acho difícil definir uma boa regra que sempre funcione. Os dados históricos mais antigos podem ser preparados antes da migração dos dados dinâmicos e mantidos em sincronia usando ferramentas como o Oracle Golden Gate. Nesse cenário, você efetivamente cria 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 de tabela for necessária. Há muitas opções a considerar e acho difícil definir uma boa regra que sempre funcione.

É um assunto interessante, Ronald.

Boas respostas até agora. Vou acrescentar mais alguns pontos para consideração.

Primeiro, quando você pode fazer suas migrações com o SQL DML simples, pode confiar amplamente no mecanismo SQL para garantir que todas as linhas sejam processadas com êxito. Entretanto, estive envolvido em migrações, onde parte da migração foi um pouco mais complicada - houve transformações reais de dados quando os dados foram movidos para uma nova estrutura. Nesses casos, é importante que você tenha um processo que possa lidar com os seguintes itens:

• Contar registros vs. registros processados.
• Detecte erros durante a transformação e lide com eles de uma maneira que permita que a transformação continue e permita o reprocessamento dos registros "inválidos" depois de identificar uma correção.
• A contagem de registros deve incluir registros "ruins" - ou seja, registros de entrada = registros de saída boa + registros ruins
• Se sua transformação alterar a contagem de registros (um registro de entrada se torna mais de um registro de saída, por exemplo), é possível prever o número de registros de saída com os quais você terminará e, em seguida, teste seus resultados com essa contagem.

O outro ponto que eu acrescentaria é que é importante ter um plano para o que você fará se / quando as coisas não saírem conforme o planejado. Essa é realmente uma função da implantação como um todo, mas parece que é encoberta com frequência suficiente para que eu ache que valha a pena mencionar.

Uma visão geral de como fazê-lo

Começar com

• Você tem o banco de dados "after" no teste / UAT / qualquer que seja "banco de dados de trabalho"
• Você tem o banco de dados "antes" em produção. Portanto, use-o para criar uma cópia da produção em algum lugar = "DB de referência". E outro como "script test DB"
• Eu também espero que você tenha vários scripts de desenvolvimento com seus ALTERs etc. Se sim, outra cópia da produção com seu script de desenvolvimento aplicada, limpa e em ordem é útil = "change DB"

Em seguida, faça o download das ferramentas do Red Gate Compare ou algo como o gerenciador do Embarcadero SQL Change . Você não pode migrar facilmente sem ele. O custo é trivial para a quantidade de tempo economizada. E o mais importante, os scripts gerados fazem alterações em uma única transação, o que significa uma implantação limpa

Agora,

• gere scripts de alteração e reversão usando as ferramentas que comparam entre a "referência" e a "alteração"
• aplique o script de alteração ao "teste de script" e compare novamente ao "banco de dados de trabalho"
• aplique o script de reversão a "teste de script" e compare novamente a "e compare novamente a" banco de dados de trabalho "

Agora, você tem scripts de mudança e reversão seguros e testados para aplicar sempre.

E é claro que você faz backup do banco de dados antes de qualquer alteração, porque a merda estatística sempre acontece eventualmente.

As ferramentas do Red Gate também podem ser comparadas a 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.