Expdp

[ssaraujo]

Estou tendo problemas com o expdp e se puder me ajudar, vou agradecer muito.

Explicando ...

A base de um cliente é composta por três schemas e estou refazendo o script de backup para um que seja mais simples e mais rápido para os momentos de virada de versão do sistema. Então para fazer o backup tenho que fazer o expdp dos três schemas e na hora de restaurar fazer o impdp e refazer os sinonimos e views materializadas cridas entre os schemas.

O problema está na hora de fazer o expdp. Em um .sh eu coloco o comando de export para os três schemas em sequência, mas não consegue criar os três arquivos .dmp, dá certo no primeiro, o segundo não faz e consegue o terceiro, ou as vezes consegue o primeiro e os outros dois não, ou mesmo não consegue o primeiro e consegue os outro dois. O erro que aparece é o seguinte:

ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-31641: unable to create dump file "<arquivo>.dmp"
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3
Additional information: 18

Achei que fosse a montagem do diretótio, mas o DBA daqui refez como mostra abaixo e nada ..
mount -o hard,rw,noac,rsize=32768,wsize=32768,suid,proto=tcp,vers=3

Monitorei as tabelas dba_datapump_jobs, dba_datapump_sessions e v$session_longops e nada de estranho.
Tentei separar as execuções do expdp do script original e criei um segundo .sh que é chamado pelo original passando os parametros necessários. Fiz isso pq achei que "talvez" o expdp dependesse de se fechar a sessão corrente para iniciar outro, ou coisa assim.

Pedi para o DBA alterar os valores dos parametros JOB_QUEUE_PROCESSES para 10 e STREAMS_POOL_SIZE para 100, que estavam com 4 e 0 respectivamente. Achei que poderia ser um problema com espaço ou com os jobs do datapump, mas não surgiu nenhum efeito.
Eu acredito que por ser muito mais rápido que os antigos comandos de export/import, deve disparar vários comandos que, talvez, se mantenham "abertos" por um momento impedindo que o próximo expdp execute com sucesso. Talvez exista alguma maneira de saber que realmente finalizou a execução e que não vai atrapalhar uma próxima.

Não sei se estou viajando nas teorias ...., mas se tiver alguma ideia, sou toda ouvidos, dedos e teclado.

Att,

Simone

[Rodrigo Almeida]

Olá Simone,

Vamos lá as dúvidas e sugestões sobre o seu ambiente, vou comentar e ajudar por parágrafo.

A base de um cliente é composta por três schemas e estou refazendo o script de backup para um que seja mais simples e mais rápido para os momentos de virada de versão do sistema. Então para fazer o backup tenho que fazer o expdp dos três schemas e na hora de restaurar fazer o impdp e refazer os sinonimos e views materializadas cridas entre os schemas.

R: Um ponto importante de analisar essa opção é verificar se o EXP vai estar íntegro para viradas de sistema, talvez dependendo dos horários, pode ocorrer de perda de dados recentes da aplicação, é um ponto de analise e sugestão. Para os sinônimos e MV's, vai ter que reconstruir se tiver tabelas de outros owners ou sinônimos públicos, não tem jeito nessa.

O problema está na hora de fazer o expdp. Em um .sh eu coloco o comando de export para os três schemas em sequência, mas não consegue criar os três arquivos .dmp, dá certo no primeiro, o segundo não faz e consegue o terceiro, ou as vezes consegue o primeiro e os outros dois não, ou mesmo não consegue o primeiro e consegue os outro dois. O erro que aparece é o seguinte:

R: Precisamos verificar como fez o shell para poder contornar esse erro. Talvez, possa fazer os 3 schemas em única chamada de EXPDP.

ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-31641: unable to create dump file "<arquivo>.dmp"
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3
Additional information: 18

Achei que fosse a montagem do diretótio, mas o DBA daqui refez como mostra abaixo e nada ..
mount -o hard,rw,noac,rsize=32768,wsize=32768,suid,proto=tcp,vers=3

R: Sobre os erros do NFS, dá uma analisa em:

• No arquivo /etc/mtab e /etc/fstab, veja como ele está configurado;
• Verifique se o usuário ORACLE tem acesso ao NFS;
• Verifica se o NFS server é a mesma versão nos 2 servidores (Destino e Origem) para os pacotes nfs-utils e nfs-utils-lib;
• Posta o resultado do comando nfsstat -m para nós;

Outra opção, tente montar o NFS com essas opções:

mount -o hard,bg,proto=tcp,suid,rsize=32768,wsize=32768,noac <seu MountPoint>

Retire a opção vers=3 e adicione o BG.

Monitorei as tabelas dba_datapump_jobs, dba_datapump_sessions e v$session_longops e nada de estranho.
Tentei separar as execuções do expdp do script original e criei um segundo .sh que é chamado pelo original passando os parametros necessários. Fiz isso pq achei que "talvez" o expdp dependesse de se fechar a sessão corrente para iniciar outro, ou coisa assim.

R: Não é necessário, pois para cada operação do Data Pump é criada uma tabela chamada de MASTER, que faz toda a instrumentação das operações do EXPDP, então poderia abrir vários EXPDP por schema diferentes, que não teria problemas, pode ter problemas se for vários EXPDP para o mesmo schema.

Pedi para o DBA alterar os valores dos parametros JOB_QUEUE_PROCESSES para 10 e STREAMS_POOL_SIZE para 100, que estavam com 4 e 0 respectivamente. Achei que poderia ser um problema com espaço ou com os jobs do datapump, mas não surgiu nenhum efeito.
Eu acredito que por ser muito mais rápido que os antigos comandos de export/import, deve disparar vários comandos que, talvez, se mantenham "abertos" por um momento impedindo que o próximo expdp execute com sucesso. Talvez exista alguma maneira de saber que realmente finalizou a execução e que não vai atrapalhar uma próxima.

R: Bom, os parâmetros JOB_QUEUE_PROCESS e STREAMS_POOL_SIZE não tem muito haver com esses problemas de EXPDP, o que pode estar acontecendo de verdade é algum problemas nas variáveis do seu shell, o modo que está realizando o EXPDP e como está configurado o NFS. Mesmo pq, caso queira fazer um EXPDP através do banco de dados, deverá usar o Oracle Scheduler para ter a iteração com o SO.

Sobre performance, existem vários pontos do Data Pump que podem ser ajustados, desde os parâmetros de buffer, parallel, METADATA do Data Pump por comando, até mesmo, ajustes de parâmetros específicos da instância Oracle, tais como SHARED, SORT, LARGE e PGA.

Publique as novas dúvidas, que vamos lhe auxiliando neste problema.

Abraços,

Não sei se estou viajando nas teorias ...., mas se tiver alguma ideia, sou toda ouvidos, dedos e teclado.

[ssaraujo]

Olá,

Desculpe a demora em responder, mas o ritmo no trabalho está violento.

Segui uma de suas dicas ... a de executar os três backups com apenas um comando e não deu certo, o erro continuava acontecendo quando eu executava um backup seguido de outro. Fiz um teste com execuções paralelas e deu o seguinte erro:


Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORA-31626: job does not exist
ORA-31637: cannot create job SYS_EXPORT_SCHEMA_02 for user OPS$VISION
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT_INT", line 672
ORA-39147: cannot migrate Data Pump queue table ownership to this instance

Deu a entender que o Datapump achava que eu estava alternando a instancia, então fiz um teste de colocar um nó especifico ao invés do nome da instancia RAC, e funcionou. Coloquei 4 execuções em paralelo e as intermitências pararam. Já no restore não tive problemas, e fiz vários testes na aplicação para ter certeza que nada foi corrompido.

Não sei se faz sentido só funcionar quando se aponta um nó específico. O que poderia estar de errado em executar backups seguidos ou em paralelo usando nós diferentes do RAC?

No mais, muito obrigada pela ajuda

[Rodrigo Almeida]

Simone,

Quando se realiza muitas atividades de Data Pump em um ambiente RAC, o mais aconselhável é sempre definir uma instãncia como o master node, para todas as suas atividades de manutenção, que podem variar desde várioas Data Pump até mesmo RMAN. Porque o erro que foi gerado (ORA-39147) é bem explícito, já tinha jobs de Data Pump criados em uma outra instância no banco de dados e não pode criar um novo para a instância que você chamou.

A Solução, seria esperar acabar a execução dos jobs ou executar todos os jobs, mesmo sendo em paralelo usando a mesma instância do RAC. Por esse motivo que quando você parou de utilizar o service name do cluster, seus jobs começaram a funcionar, pois começou a mencionar somente um nó específico.

E recomendação, crie um serviço no clusterware apenas para as atividades de manutenção, tais como RMAN/Data Pump, pois assim evita usar configurações de TAF do RAC para sua conexão administrativa, escapa do Load Balance, e ainda pode ajustar a instância que está utilizando com valores específicos que ajudam na performance dessas atividades, como LARGE_POOL, JAVA_POOL, SHARED, SORT e etc... essa atividade de nomear um nó do RAC para esses serviços exclusivos é o que chamamos de MASTER NODE.

Lembrando, que se estiver trabalhando com a versão 11g, qualquer DP no RAC11gR2 está usando cluster=y, ou seja, será PARALLEL e poderá ficar muito lento.

Abraços,