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
Reblogged this on ORA-01000 cc – miltonbastos.come comentado:
Aproveitem e visitem o Blog do Capin. Acabou de sair do forno um post sobre Migração de Banco de Dados!
Gostei muito! Parabéns pelo Post e gostei mais ainda dos exemplos, em especial o FOR … COMMIT.
Valeu pela divulgação no LinkedIn.
Ricardo,
Esse FOR … COMMIT é importante usar somente quando precisa tratar algo além da migração, na Oracle BR um companheiro de grupo disse que dependendo o caso pode ser um problema.
Então buscar mais informações antes de usar para grandes quantidades.
Att,
capin