[Oracle] Migração de Dados

Primeiro Post 2012

Vamos começar assim: para mim ainda não é 2012, mas estamos chegando nele com a graça de Deus, espero que chegue logo e que seja como queremos/esperamos/sonhamos/desejamos, com novos desafios/metas/objetivos e incansável busca a elas(es) – pessoais e profissionais.

O trabalho nos últimos meses e alguns problemas pessoais não me deixaram estar mais presente no Blog nos últimos meses como eu vinha fazendo, vamos melhor isso para 2012.

Vamos ao que interessa: Migração de Dados

Falar um pouco desta atividade que os DBAs, Analista de Banco de Dados, Administradores de Dados e Desenvolvedores realizam ou já realizam alguma vez.

Sempre que participamos de um projeto, ele tem uma entrega final (encerramento do projeto!?!? outra história), em alguns casos temos sistemas legados envolvidos, ou uma versão desatualizada do sistema atual, ou ter uma carga inicial de dados imprescindíveis etc vamos nos organizando para grande dia.

Chamo de grande dia, pois é realmente um dia (ou horas) esperado por todos os envovidos, desde a equipe de projetos (Gerente, Analistas, Desenvolvedores etc) que vai entregar, as áreas Administrativa/Financeira/Comercial e o mais ansioso de todos (talvez) o nosso CLIENTE que vai receber o seu novo sistema.

Esse novo sistema soa como ‘brinquedo novo’, ele vai ‘destroçar’ até achar todo e qualquer problema que possa existir (mesmo que a equipe de Testes tenha feito seu melhor) e nessa visão não seria diferente para os dados, quando ele tiver certeza que tudo foi migrado corretamente e estava ‘como o anterior’ lhe dará mais tranquilidade para as utilizações diárias e degustar a ferramenta, mesmo encontrando os problemas.

Falando do processo de migração coloco abaixo algumas dicas (que podem ser importantes) de migração:

• Analisar a dependência das tabelas, para criar os scripts na ordem correta;

• Os scripts de inserção podem ser criados: dependendo do volume com FOR … COMMIT cada X mil registros; pode ser INSERT … SELECT; pode ser também CREATE TABLE AS SELECT; e também se tiver acesso ao SO utilizando DATA PUMP pode fazer por TABELA, essa para tabelas grandes é muito melhor e ainda mais não tiverem dependências a serem tratadas; (Exemplos abaixo)!

• Os scripts devem ser testados e se nos testes eles sofreram alguma alteração LEMBRAR de remove-las. Essas alterações citadas podem ser teste em relação a importar somente até uma data determinada, um usuário, uma linha de produto específica, por exemplo;

• Se o ambiente do cliente é 24×7, quando menos tempo parado melhor, certo? Então analise a possibilidade de iniciar migração de dados que não sofrerão mudanças até a virada que não tenham dependências, possivelmente dados históricos e inicie a importação desses antes, sem precisar se preocupar no grande dia;

• Compreender todo o ambiente que será trabalhado também é muito importante, analisar se existem scripts/processos ou carga de dados por outros sistemas que rodam nos servidores de banco de dados envolvidos na migração; se tem algum backup agendado no período reservado para migração, se existem outros sistemas com schema nesse banco de dados e qual a utilização se executem algum processamento pesado no horário marcado, esses pequenos detalhes em um banco Oracle em Archive Mode pode gerar problemas;

• BACKUP!!! pensei, citar ou não citar (eis a questão!), mas claro que é bom citar, então antes de iniciar o processo executar as formas normais de BACKUP que já são utilizadas normalmente e claro as que você se garanta em recuperar em caso de problemas.

Basicamente essas são algumas dicas que tenho. Claro que devem existir outras necessidades que você já conheça e do ambiente.
Fico grato com comentários de algo que possa acrescentar esse post, tornando mais completo possível.

Exemplos:

Era isso por hoje, grato pela atenção.

Att,
capin