CleitonHanzen.
CleitonHanzenFala Galera…blz?
Bom, temos um cliente que adquiriu servidores RISC novos (2 Processadores Quad e 16Gb de memória por server) e estes vieram com RHEL5.3 para Itanium. Pois bem, montamos o RAC versão 10.2.0.4 e estava tudo rodando 100% até o momento que fizemos um import para testar o tempo da migração dos servidores antigos (como a janela de manutenção é grande, resolvemos fazer via export/import e fazer um “reorg” no banco, ao invés de fazer via RMAN, o banco é de +- 150GB).
Para a nossa total surpresa, um export que numa máquina X86 que demora mais ou menos 3 horas para fazer, está demorando 16 HORAS para importar, detalhe: Processo imp literalmente moendo com a CPU (não baixa de 100% de uso, isto na parte de dados, a job_queue setada para 0, o import fazendo local não está sendo usado TNS).
Alguém já observou este comportamento “anormal” com Linux em Itanium?
Marcio68AlmeidaQuando vocês fizeram o import, vocês deixaram apenas um nó do RAC ou deixaram todos ?
Se deixaram todos durante a atualização realmente vai demorar um pouco mais…
Vocês lembraram de desligar o arquivamento de logs ? Isso realmente puxa o freio de mão na hora de importar.
O arquivo dump está no servidor ou está sendo carregado via rede ? Se for via rede tem que concorrer com todoo tráfego da rede, isso também diminue a performance…
Não creio que o problema seja no Linux ou nos servidores…
David SiqueiraAlém das perguntas do Márcio, eu gostaria de saber qual tipo de gerencimaneto de discos e que tipo de RAID e a configuração como estão?
Abraço.
David
vieriJá passei com algo parecido.
Deslique o RAC, cluster=false, suba apenas um nó, e faça o imp
neste nó localmente com o dump local.
Só pode ser isso!!
CleitonHanzenOpá..
Respondendo:
DB está em modo exclusive (no primeiro nó).
Archive Desabilitado.
O arquivo está local no sevidor.
Sobre as LUN’s, são duas LUN’s de 200GB em RAID 10.
Não questionei isso à toa, o que realmente achei estranho não são os processos do banco (Processo Shadow ou LGWR/DBWR, ARCH) que estão consumindo excessivamente CPU, mas sim o processo IMP (do import, já tivemos experiências desastrosas com Data Pump que nem usamos mais essa M..)
Apresentamos outras LUN’s desse mesmo Storage para uma máquina single instance em Linux X86_64 com uma configuração similar, e pra parte de dados demorou 3 horas…agora está fazendo a parte de indices e contraints…
Vamo lá…chamado na Oracle e ver o que os “Bug Maker” falam… 🙂
Mas vlw pelas respostas…
David SiqueiraBoa, cara uma vez eu trabalhei em um ambiente RAC com 3 nós ( 9.2.0.5) em AIX 5.3 , e todas as vezes que precisavamos realizar tarefas de IMPORT independentemente da carga ser grande ou não , demorava demais e também consumia CPU absurdamente, depois de incasaveis verificações e cerca de 3 DBA’s de porte olhando resolvemos retirar o BUFFER do comando de IMPORT como teste para ver se poderia ser alguma falha de S.O mesmo, e pra nossa surpresa foi absurdamente rápido o Import dos dados, refizemos várias vezes porque ninguem acreditava nessa possibilidade, e constatamos que , nessa release em RAC e nesse S.O usando o Buffer a coisa ficava desastrosa, não sei se tu pode realizar esse pequeno teste, mais se achar valido tente e veja se obtem algum ganho.
Abraço.
Boa Sorte.
Marcio68AlmeidaAproveitando o gancho de nosso colega…
Teste com as diversas opções do import, pode ser que alguma esteja puxando o freio de mão…
Use sempre o feedback para avaliar o tempo de retorno das linhas…
CleitonHanzenOpá..
Fala galera, somente para dar finalidade à esse assunto:
Cagada minha nesta situação, o animal aqui tava fazendo o import por uma sessão SSH sem utilizar nohup…. 😆 , como estava dando pau na criação de um milhão de views ficava “esperando” pra mostrar esses erros em tela…
colocado o nohup foi normal..
Poh foi mal ocupar o tempo de vcs…. 😯