Neste cenário o enterprise manager é ao mesmo tempo herói e vilão. Ao mesmo tempo que nos ajuda, criando scripts evolutivos para os objetos de banco, basta uma simples distração nossa para que o script seja perdido ou o banco destruido.
Existem certas operações que não podem ser feitas diretamente via script. Ou melhor, até podem, mas seriam extremamente trabalhosas.
Por exemplo, trocar o tipo de dados de uma chave primária que possui relacionamentos com outras tabelas. Seria um processo extremamente trabalhoso fazer isso via código. O Enterprise Manager realiza esse processo automaticamente para nós. A pergunta que normalmente surge é : Se este é um processo muito complexo via código como o Enterprise Manager consegue realiza-lo ?
Ocorre que o Enterprise Manager foi preparado para contornar limitações do servidor através de alterações no modelo de dados.
Se trocamos o tipo de dados da chave primária o enterprise manager se encarrega de eliminar as constraints (PK e FK, ou seja, nas duas tabelas) e até mesmo recriar a tabela para que a troca de tipo seja possível, transferindo todos os dados da antiga tabela para a nova tabela, recriada. Isso tudo, claro, sem esquecer de recriar as constraints ao final.
Assim sendo, o trabalho realizado automaticamente pelo Enterprise Manager é exatamente o que precisamos : uma evolução das tabelas existentes no banco com o cuidado de manter todos os objetos e dados. O enterprise manager, felizmente, nos permite fazer a gravação dos scripts que ele utiliza para gerar essas modificações. Desta forma podemos não apenas gerar as modificações com facilidade como podemos também salvar os scripts e reproduzir as modificações em outros servidores.
Mas o Enterprise Manager se torna um grande vilão quando percebemos que basta um clique em um botão errado para perdermos toda a possibilidade de gerarmos este script . O botão para geração do script fica exatamente ao lado do botão salvar. Se nos confundirmos e por engano clicarmos em salvar, o enterprise manager irá executar as alterações e não poderemos mais salvar o script. Ou seja, temos apenas uma chance de salvar o script, se clicarmos no botão errado, teremos problemas.
Além do cuidado que o DBA deve ter para não errar existe também a questão da sequencia de arquivos. O DBA precisa organizar os arquivos de forma a que possa identificar facilmente a sequencia de execução dos arquivos. Assim sendo precisará planejar como fazer essa organização, que envolve a nomenclatura dos arquivos. Veja algumas possibilidades
· Utilizar um número sequencial
· Utilizar identificação de data
· Utilizar uma identificação do objeto em conjunto com um dos itens anteriores
Desta forma, gerando os scripts evolutivos e mantendo os arquivos organizados, no momento da implantação bastará executar os scripts na ordem correta para reproduzir as mesmas alterações criadas em ambiente de desenvolvimento.

