Eu tenho este cenário:
- Um enorme (milhares de tabelas), complexo banco de dados de produção Oracle 8,
- Um enorme (milhares de tabelas), complexo, banco de dados de desenvolvimento Oracle 9, (mesma estrutura de produção)
- No banco de dados de desenvolvimento, alguns stored procedures e packages foram modificados e novos foram adicionados.
- O banco de dados de desenvolvimento tem novas tabelas em alguns esquemas
- Nem o Oracle 8
expnem o Oracle 9imptêm a opção ROWS ONLY
Geralmente fazemos o seguinte porque é a única maneira de obter dados atualizados corretamente porque uma importação com ignore=yesapenas inseriria novos dados, mas não atualizaria linhas pré-existentes com o mesmo PK, mas valores diferentes em colunas não PK:
- Exclua um esquema e crie o usuário novamente para ter um esquema vazio
- Importar de usuário para usuário para o esquema vazio
O problema é:
- Como atualizar o banco de dados de desenvolvimento com dados novos de uma exportação de produção sem precisar excluir o esquema primeiro, pois há novos procedimentos/pacotes armazenados, bem como modificados no banco de dados de desenvolvimento?
- O processo de comparação para recriar apenas procedimentos armazenados modificados ou novos após a exclusão do esquema, para recuperá-los de um backup, seria muito propenso a erros.
- Existem milhares (literalmente) de tabelas, então não queremos programar um procedimento armazenado para atualizar os dados em determinada ordem, etc. Isso levaria meses para escrever e testar.
O que seria uma solução baseada em importação para isso?
EDIT: não mencionei que prod é Solaris e dev é RedHat.
Vejo duas soluções. Não os testei, mas espero que sejam úteis.
Em contraste com a exportação do modo de tabela, tanto a exportação do modo de usuário quanto a do modo de tablespace cuidam das dependências entre as tabelas para que as tabelas sejam importadas na ordem correta. Ambos os métodos importam as estruturas da tabela de produção para dev. A exportação/importação no modo Tablespace no Oracle 8i ou 9i pode ser feita apenas entre sistemas de banco de dados no mesmo sistema operacional. O On pode lidar com essa restrição importando os dados usando a importação do modo de usuário para um esquema ou banco de dados intermediário no mesmo sistema operacional do sistema de destino.
Método 1: Usando TablespaceMode export/import :
1) Coloque o(s) tablespace(s) de prod em modo somente leitura
2) TablespaceMode-Exporte o(s) tablespace(s) e copie o arquivo de dados de prod
3) Coloque os tablespaces de prod em modo de leitura/gravação novamente
4) Solte os Tablespaces no dev (deixa os procedimentos, visualizações do dev)
5) TablespaceMode-Importe os tablespaces no Target (inclui tabelas, gatilhos, índices, restrições de prod)
6) Coloque o(s) tablespace(s) do dev em read/ modo de gravação
Talvez haja alguns problemas que você tenha que copiar com alterações na estrutura da tabela, concessões ausentes ou que as sequências precisem ser ajustadas
Método 2: substitua os procedimentos por uma exportação
1) UserMod-Export do esquema prod
2) UserMod-Export do esquema dev
CONSTRAINTS=NGRANTS=NSTATITICS=NTRIGGERS=NROWS=N3) elimine o esquema dev
4) importe o esquema prod (para dev)
5) importe o esquema dev ( para desenvolvedor)
IGNORE=YCONSTRAINTS=N*GRANTS=N*INDEXES=NROWS=N*a segunda importação deve substituir os objetos prod (procedimentos, visualizações) pelos objetos dev, mas deixar as tabelas e objetos relacionados a tabelas. Parâmetros com * já são definidos durante a exportação. Talvez não se deva defini-los durante a importação. Se você definir
IGNORE=N, receberá muitas mensagens de erro, mas talvez haja algumas outras vantagens. Acontecerá que você importa tabelas de dev que não estão em prod. As alterações na estrutura da tabela devem ser tratadas anualmente.Eu preferiria um método que extraia os procedimentos do esquema dev antes de ser substituído pelo esquema prod. Ferramentas como o Toad da Quest (como mencionado por @rm em um comentário) que podem comparar esquemas e criar scripts para implementar as diferenças podem ajudar.
1) UserMode-Export de prod
2) Extraia os procedimentos de dev para sql-scripts
3) elimine o esquema dev
4) UserMode-Import para dev
5) elimine procedimentos em dev
6) execute os scripts criados pelo processo de extração
7) compile tudo procedimentos
O método a seguir sai das estruturas dev e importa apenas os dados da produção. Você receberá erros durante a importação de dados se a coluna de uma tabela tiver sido renomeada ou removida em dev. Adicionar colunas com restrições em tabelas dev ou alterar restrições em dev também pode fazer com que a importação de dados dessas tabelas falhe. Se algumas tabelas não forem importadas por causa desses erros, tabelas dependentes que não foram alteradas no dev também podem ter problemas quando os dados são importados. Portanto, muitos problemas complicados podem surgir. A ideia básica é:
*) remover os dados das tabelas dev
*) desabilitar restrições, gatilhos e índices nas tabelas dev
*) importar os dados apenas das tabelas de produção para as tabelas dev
*) habilitar restrições, gatilhos e índices nas tabelas dev
*) importe os dados para as novas tabelas de desenvolvimento e habilite suas restrições, gatilhos e índices
1) o modo de usuário exporta o esquema dev sem gatilhos
ROWS=NOTRIGGERS=NOFILE=dev1.dmp2) o modo de usuário exporta o esquema dev novamente
ROWS=NOTRIGGERS=NOFILE=dev1.dmp3) o modo de tabela exporta as tabelas dev não encontradas no prod
TABLES=list_of_tables_in_right_orderTRIGGERS=YCONSTRAINTS=YINDEXES=YESGRANTS=YROWS=YSTATISTICS=NOdev3.dmp4) descarta o esquema no dev
5) cria o esquema vazio no dev novamente
6) importa o esquema dev vazio sem gatilhos, restrições e índices
ROWS=NOCONSTRAINTS=NINDEXES=NOFILE=dev1.dmp7) importar os índices em um script
INDEXES=YESÌNDEXFILE=index.sqlFILE=dev1.dmp8) modo de usuário exportar o esquema prod TRIGGERS=NO INDEXES=NO FILE=prod1.dmp TABLES=* 10) criar os índices usando index.sql com sqlplus 11) importar restrições e gatilhos da tabela 12) importar as tabelas dev necessárias
CONSTRAINTS=NOGRANTS=NO
9) table import the prod table data
IGNORE=YCONSTRAINTS=NINDEXES=NGRANTS=NFILE=prod1.dmpTABLES=*CONSTRAINT=YTRIGGERS=YROWS=NFILE=dev2.dmpTABLES=list_of_tables_in_right_orderIGNORE=YCONSTRAINT=YGRANTS=YINDEXES=YO que finalmente resolveu meu problema foi: