Menu de navegação

[EliezioParticipante]

[quote=”Eliezio”:2oxldyj6][quote=”felipeg”:2oxldyj6]Post duplicado?

Eu imagino que o primeiro tenha retornado zero, mas e o retorno desse?


SELECT COUNT(OBJECT_TYPE),
OBJECT_TYPE, owner
FROM DBA_OBJECTS
WHERE OWNER LIKE 'OWNER_DAS_TABELAS'
GROUP BY OBJECT_TYPE, owner;


Atenciosamente,
Felipe.[/quote]

Filipe ainda continua aparecendo a mesma quantidade de tabelas. todos os outros objetos está na mesma quantidade do servidor de produção, menos as tabelas.

Obs. estou demorando a responder pq internet ta muito lenta.[/url][/quote]

Cara, estou pensando em gerar um novo export, tem um export mais completo, onde eu nao tenha risco de deixar nada de fora.

[burgaParticipante]

Você está usando o 11g? Se sim deve ser o problema em que ele ainda não criou os segmentos pras tabelas vazias… Tente fazer com o datapump.

Outra coisa, posta as versões dos bancos de origem e destino também pra tentar matar esta dúvida, e também versões dos clients que você está usando pra fazer exp/imp..

[IshiiParticipante]

Olá,

Realmente com o import de muitas tabelas sempre dá esse tipo de problema e NUNCA descobri a razão, pelo fato se ser intermitente… Tinha um ERP com cerca de 5000 objetos no BD desde tabelas, procedures, functions, packages, triggers, views etc. só não tinha muitas types e view materializada. Sempre tinha que efetuar o import 2 ou 3 vezes, pois sempre faltava uns objetos, que NUNCA se repetiam em outros testes, e para piorar nos logs não tinha mensagem de erro…o problema é que nas tabelas ficava registrado nos logs mas os objetos não ficam todos…

Em umas vezes umas procedures não importavam, em outras eram algumas packages, testei por anos em vários ambiente tentando achar uma lógica, -mas sem encontrar. A saída foi um Workaround (leia-se POG) que eram importar duas vezes… e fazer exatamente essa comparação…

[]s Ishii

[EliezioParticipante]

[quote=”Ishii”:2ivyoeit]Olá,

Realmente com o import de muitas tabelas sempre dá esse tipo de problema e NUNCA descobri a razão, pelo fato se ser intermitente… Tinha um ERP com cerca de 5000 objetos no BD desde tabelas, procedures, functions, packages, triggers, views etc. só não tinha muitas types e view materializada. Sempre tinha que efetuar o import 2 ou 3 vezes, pois sempre faltava uns objetos, que NUNCA se repetiam em outros testes, e para piorar nos logs não tinha mensagem de erro…o problema é que nas tabelas ficava registrado nos logs mas os objetos não ficam todos…

Em umas vezes umas procedures não importavam, em outras eram algumas packages, testei por anos em vários ambiente tentando achar uma lógica, -mas sem encontrar. A saída foi um Workaround (leia-se POG) que eram importar duas vezes… e fazer exatamente essa comparação…

[]s Ishii[/quote]

Bom dia Ishii, deixa eu entender,
1º Pra resolver o problema você faz o import 2 vezes?
2º e quando você faz o segundo import você não precisa dá um drop cascade no ususario(esquema) onde você fez a importação, tem com me explicar com mais detalhes?

Obrigado pela sua dica, preciso muito resolver esse problema.

Eliézio Mesquita

[EliezioParticipante]

[quote=”burga”:19vu2751]Você está usando o 11g? Se sim deve ser o problema em que ele ainda não criou os segmentos pras tabelas vazias… Tente fazer com o datapump.

Outra coisa, posta as versões dos bancos de origem e destino também pra tentar matar esta dúvida, e também versões dos clients que você está usando pra fazer exp/imp..[/quote]

Bom dia, na nova maquina nova estou usando o 11g, na maquina que está em produção está sendo usado o 10. Abaixo segue as versões so oracle do Exprt e Import, estou querendo saber se existe outra forma de backup onde eu não possa ter problemas.

Versão do Oracle do Export:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0

Versão do Oracle do Import:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0

Obrigado,

Eliézio Mesquita

[IshiiParticipante]

Olá,

Para o novo import eu utilizava os seguintes parâmetros, SOMENTE para objetos!!!
ignore=y
rows = n


Com isso os objetos já existentes no FROMUSER/TOUSER apenas apareciam com msg de objeto já estava criado…e o restante era criado (os que não tinham sido da primeira vez)

No caso de tabelas era um problema mesmo. Se eram poucas as tabelas utilizava:
TABLES=(TAB_1,TAB2 etc)


Pois no caso do ERP, algumas tabelas não tinham PK (por razões de negócio) e eu listava as mesmas para 1) DROPAR essas tabelas 2) Proceder com o novo import mas com a seguinte alteração
ignore=y
rows = Y


Com isso as tabelas DROPADAS eram recriadas e realimentadas sem duplicidade e as tabelas que~por alguma razão não tinham sido importadas na primeira vez, agora eram… (Nunca descobri o porque mesmo)

[]s Ishii

[EliezioParticipante]

[quote=”felipeg”:19ncm0x8]Estranho…

Aquele select da user_tables você rodou em produção ou homologação?
Era pra rodar em produção (schema original).

Atenciosamente,
Felipe.[/quote]

Filipe existe alguma outra técnica que eu possa usar para fazer um novo backup da maquina de produção sem ter o risco de deixa objeto de fora, mas que seja uma forma simples como o exprt ou o proprio export de forma mais refinada?

[IshiiParticipante]

Olá,

Se a maquina de teste for parecida com o Servidor de Produção, sugiro o RMAN, pois é uma cópia física mesmo…com isso, seria rápido e você teria todos os objetos, se não for parecida, pode ainda usar o RMAN e o EXPDP e IMPDP.

[]s Ishii

[felipegParticipante]

Opa,

Eu testaria um exportimport utilizando o datapump…
Nunca tive problemas em relação a quantidade de objetos.

@Ishii
Essa situação de faltar tabelas é nova pra mim, será que não tem nada no metalink?
Vou dar uma conferida.

Atenciosamente,
Felipe.

[IshiiParticipante]

Olá

@felipeneg

Como eu nunca consegui reproduzir isso, e nos logs não aparecia nada. A Oracle nunca conseguiu abrir um chamado, pois não havia evidências (além da tabela estar faltando 😯 ) para comprovar o problema…

Tenho essa situação desde o Oracle 7.3.4 e nas versões 10g e superiores diminuiram bastante essa ocorrência, tenho a impressão que deve estar relacionada ao HW mesmo, pois na época, algumas máquinas não tinham a mesma característica de processamento e memória que hj…

Para se ter uma idéia da intermitência, executando o import direto do servidor também dava um ou outro problema. Nessas mesmas condições, executando via cliente em outra máquina, não dava mais o problema…

[]s Ishii

[felipegParticipante]

Momento descontração

Você chegou pra Oracle reportou o problema e o cara deu uma de Padre Quevedo?

ESTO NON ECZISTE, se no podes provar NON ECZISTE!

😆

O jeito é apelar para o Datapump ou o RMAN mesmo…

Atenciosamente,
Felipe.

[rmanParticipante]

[quote=”Ishii”:507bj5v0]Olá,

Realmente com o import de muitas tabelas sempre dá esse tipo de problema e NUNCA descobri a razão, pelo fato se ser intermitente… Tinha um ERP com cerca de 5000 objetos no BD desde tabelas, procedures, functions, packages, triggers, views etc. só não tinha muitas types e view materializada. Sempre tinha que efetuar o import 2 ou 3 vezes, pois sempre faltava uns objetos, que NUNCA se repetiam em outros testes, e para piorar nos logs não tinha mensagem de erro…o problema é que nas tabelas ficava registrado nos logs mas os objetos não ficam todos…

Em umas vezes umas procedures não importavam, em outras eram algumas packages, testei por anos em vários ambiente tentando achar uma lógica, -mas sem encontrar. A saída foi um Workaround (leia-se POG) que eram importar duas vezes… e fazer exatamente essa comparação…

[]s Ishii[/quote]

Esse problema também ocorre no EXPDP/IMPDP ? Ou apenas no EXP/IMP ?

[IshiiParticipante]

Olá,

Relatando o problema até a versão 8i, pois depois terceirizei com o DBA jr.

Sim, só ocorria no EXP/IMP e ainda mais nas versões 8.0 e anteriores…

POG automatizada:
1) IMP com rows=n
2) Novo IMP para garantir todos os objetos e ignore = y
3) Desabilitar as FKs e PKs via script
4) IMP com rows=y e ignore = y
5) Dormir umas horas
6) Habilitar as PKs via script e rezar
7) Habilitar as FKs via script e rezar em triplo para não dar erro…

IF erro na etapa 7 THEN
IF horas restantes < 8horas THEN rollback em tudo…
e tentar em outro dia/fim de semana
ELSE tentar descobrir quais eram as tabelas e tentar tratar
END IF;
ELSE
rezar mais um pouco para agradecer
END IF;

Com a implementação do DATAPUMP e depois do RMAN acho que não aconteceu mais, porém estou distante disso agora…

[]s Ishii 😈

[rmanParticipante]

Bom, como o Eliezio trabalha com o Oracle 10g e 11g, é mais recomendado o uso do EXPDP/IMPDP, além de melhor performance, está livre o bug conforme a vivência do Ishii…

Workaround !

[EliezioParticipante]

[quote=”Ishii”:1er9ng2r]Olá,

Para o novo import eu utilizava os seguintes parâmetros, SOMENTE para objetos!!!
ignore=y
rows = n


Com isso os objetos já existentes no FROMUSER/TOUSER apenas apareciam com msg de objeto já estava criado…e o restante era criado (os que não tinham sido da primeira vez)

No caso de tabelas era um problema mesmo. Se eram poucas as tabelas utilizava:
TABLES=(TAB_1,TAB2 etc)


Pois no caso do ERP, algumas tabelas não tinham PK (por razões de negócio) e eu listava as mesmas para 1) DROPAR essas tabelas 2) Proceder com o novo import mas com a seguinte alteração
ignore=y
rows = Y


Com isso as tabelas DROPADAS eram recriadas e realimentadas sem duplicidade e as tabelas que~por alguma razão não tinham sido importadas na primeira vez, agora eram… (Nunca descobri o porque mesmo)

[]s Ishii[/quote]

Boa noite, olha só eu ja fiz o import uma vez agora posso fazer a segunda vez com o paramentro abaixo, veja se está certinho:

imp system@MinhaInstancia file=MeuDump.dmp log=imp_MeuLog.log fromuser=UserOrigem touser=UserDestino ignore=y row=n

[Autor]

Posts