Menu de navegação

[José Laurindo ChiappaModerador]

Sim, cfrme o link que te passei (e a Doc confirma) o REPLACE faz um DROP das tabelas que já existam e depois executa o CREATE que foi extraído da origem, e esse CREATE já vai ter as colunas todas, constraints todas, triggers todas, índices todos, isso aí… Não é só as constraints, é Tudo que é diretamente dependente da tabela dropada que será criado de novo… Só mesmo elementos estruturais gerais como Tablespaces, Quotas, Sinônimos, DBLINKs, usuários, profiles, etc, etc é que não são dropados e recriados pelo parâmetro, mas se vc tem 100% de certeza que essas coisas tão sempre Iguaizinhas nos dois bancos, blz…

A sintaxe para um importação de um dump file gerado com export full E com a opção de REPLACE para table_exists_action seria :

impdp usuário/senha directory=nomedodirectory dumpfile=nomedodumpfile.dmp logfile=nomedologfile.log full=y table_exists_action=replace

[]s

Chiappa

[Edgar Rombesso RisolaParticipante]

Funcionou uns 95%….todos os dados foram inseridos nas tabelas e o sistema subiu normalmente…porém ele apresentou alguns erros de input de informações diretamente na aplicação…mas isso posso ver como consertar depois..o importante é que os dados foram levados…tks man

[José Laurindo ChiappaModerador]

Yep, blz….
Bem , do lado do banco de dados (que é onde podemos palpitar, dado que não conhecemos nem um átomo da sua aplicação, e nem temos como conhecer) a verificação é simples : se, usando a opção de logfile (pra não perder ** nem uma linha ** do log gerado, tanto no export QUANTO no import), vc não recebeu ** nenhum ** erro ORA-qquercoisa, e nem recebeu NENHUM warning/aviso (de conversão de characterset, de coluna inexistente, de constraints violada,enfim, nada de nada) congratule-se, a “clonagem” foi feita, os bancos estão IGUAIS….
O que sobra pra explicar comportamente inadequados da aplicação se vc Provou que a camada de banco está OK e que exatamente os mesmos dados estão lá e cá basicamente seria :

a) dados relacionados ao servidor/ambiente de origem : é meio absurdo, mas como de cabeça de desenvolvedor vc nunca sabe o que vêm, tranquilamente pode haver, digamos, tabelas que armazenam informação logicamente relacionada ao servidor/ambiente (talvez IP, nome do servidor, domínio ou coisa assim) : nesse caso, Obviamente, a tabela vai estar carregada com o IP/nome do servidor Origem, que difere do destino aí a APlicação não encontra o dado que espera… Idem por exemplo para DBLINKs que no servidor-destino tenham que apontam pra outra fonte de dados, e coidsas do tipo

b) processamentos/manipulações de dados feitaos por métodos que não sejam SQL : cfrme já dissse, o export gera INSERTs de dados, que serão executados pelo import no banco-destino : digamos que determinados processamentos estejam codificados numa procedure que insere dados (e talvez os grave até fora do banco, em arquivo-texto, digamos) : OBVIAMENTE essas procedures NÂO SERÂO EXECUTADAS : o import cria as procedures/triggers/etc que vêm do banco-origem fielmente MAS não as executa, a não ser no caso de triggers amarradas a INSERT/UPDATE/DELETE

c) configurações externas ao banco de dados,incluindo Listener, TNSNAMES, SQLNET.ORA, permissões no SO, enfim, tudo que serve ao banco, EM CONJUNTO com itens criados para atender à aplicação, como arquivos de texto, diretórios e etc : evidentemente export e import Não Toca nessas coisas externas ao banco….. Não é provável que seja isso, mas por questão de completude eu as cito

Fica totalmente por sua conta, em conjunto com o pessoal da Aplicação, analisar e descobrir quais dessas possibilidades pode estar pegando aí pra vc e portanto exigirão itens adicionais na sua rotina/script de “clone”…

[]s

Chiappa

[Autor]

Posts