Menu de navegação

[armandovelosoParticipante]

Olá todos!

Tenho um dump do 9i 32 bits (windows), com 300GB de tamanho.

Estou tentando importar num 11G 64 bits (windows).

Não está dando erro nenhum, mas esta DEMORANDO DEMAIS. Tenho algumas tabelas bem grandes, passou horas em uma de 40GB e agora esta passando horas noutra tabela de 20GB.

Iniciei o import ontem a tarde, as 17h. Hoje, depois de 17 horas rodando o import, consultei a DBA_SEGMENTS e há somente 87 GB de dados importados.

O comando usado foi esse:

imp system/xxx@yyy BUFFER=64000 COMMIT=Y STATISTICS=NONE file=E:exportexport_diario.dmp log=E:exportlog_imp.txt fromuser=”USER1, USER2″ touser=””USER1, USER2″

Armando.

[Douglas Paiva de SousaParticipante]

De acordo com as informações que você passou, está dentro do esperado, esse DUMP é muito grande e se tiver objetos do tipo LOB, BLOB, CLOB e etc, vai demorar mais ainda.

Você já fez esta importação alguma outra vez que tenha demorado menos?

Att,

[Regis AraujoParticipante]

@armandoveloso

Quais as configurações do servidor onde está sendo importado?

Memoria, processador, disco (storage ou disco interno) ??

Não é para demorar tanto assim não..

Abraços..

[CleitonHanzenParticipante]

Aproveita e lista as 50 ultimas linhas do arquivo de alert.log do banco… 🙂

[armandovelosoParticipante]

O servidor que esta sendo importado é robusto, tem 64 nucleos, 128 GB de RAM, e o banco ta numa storage nova da EMC (nao lembro o modelo, mas o suporte garante q ta otimizado o acesso).

A origem, ondeta o dump, é outra storage antiga, mas nao acredito que a leitura dessa storage esteja impactando em tanta demora.

É a primeira vez que tento import dessa base.

Não há campos *LOB…

Olhei agora, terça a noite, 2 dias depois, e so tem importado 132 GB!!

Obrigado pela ajuda!

Armando.

[rmanParticipante]

@armandoveloso

Testa fazer a importação sem o parâmetro COMMIT=Y

[DavidIDBParticipante]

Como esta configuração do banco?
SGA
REDOS
TABLESPACES
DATAFILES

[armandovelosoParticipante]

DavidIDB,

SQL> sho parameter memory_target

NAME TYPE VALUE

---

memory_target big integer 39424M

SQL> sho parameter memory_max_target

NAME TYPE VALUE

---

memory_max_target big integer 39424M

Sao 8 redologs de 100 MB

Há umas 30 TS, e os DBS das maiores TS tem no máximo 10GB cada um de tamanho.

Usei as seguintes configurações na criação das TS:
” LOGGING ONLINE PERMANENT BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO; ”

Acabei de abortar o IMPORT, desse jeito ia durar mais de uma semana, procedimento inviável.

Vou tentar agora usando a sugestão do @RMAN, e coloco aqui o andamento.

Obrigado!
Armando.

[msantinoParticipante]

Na hora do IMP tenta botar também o parâmetro FEEDBACK:

FEEDBACK display progress every x rows(0)

Por exemplo, FEEDBACK=10000 vai te dar um feedback a cada 10 mil linhas inseridas. Como suas tabelas são gigantes, vai te dar uma visão de progresso sem achar que está travado…

[armandovelosoParticipante]

msantino,

Ja sabia desse parametro, mas sei que nao ta nada travado, fico sempre consultando na DBA_SEGMENTS e ela sempre aumenta, o problema é que muito lentamente.

De qq forma, na proxima tentativa, colocarei o feedback.

Obrigado,
Armando.

[armandovelosoParticipante]

@rman,

Sua dica parece ter melhorado, mas acho ainda lento.

Acabou de completar 24 horas de IMPORT e apenas 170GB foram importados. Essa quantidade da vez anterior so alcancei apos 3 dias de import…

Noto que o início do import é rapido, em menos de 2h de processo, passa dos 50GB importados, qdo vao chegando grandes tabelas, o processo se arrasta. Nas ultimas 14 horas, so importou 65 GB!

Obrigado,
Armando.

[CleitonHanzenParticipante]

Gera um report do ash e cola aí pra gente dar uma olhada……Tá tendo algum tipo de contenção nesse teu import….

Se não for no “destino” pode ser na “origem”….

[armandovelosoParticipante]

Realmente é estranho,

Com 24 horas tinha importado apenas 170GB, aí com 36 horas, 12 horas depois, termina todo o import, completando 378GB ao todo…

Parece que qdo diminuem as tabelas gigantes o processo anda mais fácil…

[msantinoParticipante]

Será que não seriam limitações de UNDO ou até mesmo REDO?

Por exemplo, se o REDO for pequeno demais ou em pouca quantidade, o “enchimento” deles pode ser mais rápido que o “esvaziamento”.

Outro dia criei uma instância de testes pra testar um IMPDP e esqueci de redimensionar os REDOs. Aì estranhei que tava demorando muito e por acaso abri o alert.log. Tinha um monte de mensagens dizendo que tava com delay esperando pra utilizar um novo REDO. Ai eu cancelei, redimensionei e depois foi numa boa!

Dá uma olhada nisso…

[DavidIDBParticipante]

Crie REDOs maiores. 10 de 1 G cada por exemplo.
Qual a configuração de discos? RAID 10? Se for RAID 5 esqueça, não ha como melhorar e teria que refazer.
Os dicos são de 15K?
Ja existe espaço suficiente nas tablespaces para toda a base ou os datafiles estão aumentando conforme chegam no seu tamanho total. Isso diminui muito a performance.
Não faça import com archives habilitados.
Isso tem que resolver.
abs
David

[Autor]

Posts