Menu de navegação

[airoospParticipante]

Bom dia pessoal,

Estou fazendo um teste com o EXPDP no banco de homologação que é 11g R2 com Windows Server 2012. Ao executar o EXPDP com o usuário SYSTEM, aparece o erro abaixo:

Estimativa em andamento com o método BLOCKS…
>>> ORA-31642: a seguinte instrução SQL falhou:
BEGIN “SYS”.”DBMS_RULE_EXP_RULES”.SCHEMA_CALLOUT(:1,0,1,’11.02.00.04.00′); END;
ORA-01950: não há privilégios no tablespace SYSAUX’
Processando o tipo de objeto DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

Pesquisei sobre o erro e em alguns sites informa que é necessário atribuir privilégio a tablespace SYSAUX.

Isso foi feito mas não funcionou, o erro continua.

Se alguém tiver alguma dica, agradeço.

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Blz ? Então, primeira coisa nos mostre aí a sua linha de comando ** completa ** executando o expdp : é muito provável que o que acontece é que o expdp vai tentar “se passar” pelo usuário sendo exportado, então é ESSE usuário que precisa ser privilegiado – veja exemplo em https://tobeimpact.blogspot.com.br/2018/01/datapump-export-fails-with-ora-1950-no.html , onde o usuário SYSMAN teve que ser privilegiado… A nota metalink ‘Datapump Export Fails with ORA-1950: “no privileges on tablespace”‘ (Doc ID 1633698.1) e a “ORA-39126, ORA-31642 And ORA-01950 When Performing Full DataPump Export” (Doc ID 1340932.1)também registra casos similares….

Não sendo isso, a próxima coisa que se pensa é que há Diretivas de segurança customizadas nesse database (VPD, trigger de DDL, Auditoria via AUDIT ou DBMS_FGA, etc) que estão impedindo o export : VERIFIQUE essa possibilidade… Dois testes práticos e simples que vc pode fazer pra CONFIRMAR ou NEGAR a possibilidade são :

1. rodar o export como SYSDBA

e

2. tenta rodar exatamente o mesmo export num OUTRO database seu, de teste, onde vc tem 100% de certeza que NENHUMA DIRETIVA DE SEGURANÇA extra tá ativa/foi criada

E veja o que vc vai ver…

==> Opção final : se nenhum dos casos anteriores se confirmou, peça pro RDBMS (alinhando com o DBA do ambiente, se não for você mesmo) criar um ** TRACE EXTENDIDO ** quando encontrar esse ORA-01950 , isso se faz conectando no banco como SYSDBA no sqlplus, executando um :
alter system set events ‘1950 trace name ERRORSTACK level 3’;

aí numa outra janela vc faz o export normalmente, depois volta ao sqlplus e desativa com um :

alter system set events ‘1950 trace name ERRORSTACK off’;

Com isso vc vai ver no arquivo de trace que será gerado no servidor EXATAMENTE o SQL que causou esse “erro”…

[]s

Chiappa

[airoospParticipante]

Chiappa,

Fiz o que você falou, através do arquivo de trace foi possível ver o erro, segue abaixo:

.
.
.
*** 2018-01-18 11:54:31.097
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
—– Error Stack Dump —–
ORA-01950: não há privilégios no tablespace SYSAUX’
—– Current SQL Statement for this session (sql_id=5uy7d392fuu4q) —–
create table “TEST”.re$action_imp_tab(owner varchar2(30), name varchar2(30), action sys.re$nv_node) tablespace SYSAUX
—– PL/SQL Stack —–
—– PL/SQL Call Stack —–
object line object
handle number name
00000003CCBC70D8 354 package body SYS.DBMS_RULE_EXP_RL_INTERNAL
00000003CC3E13C0 109 package body SYS.DBMS_RULE_EXP_RULES
000000025F6B93D8 1 anonymous block
00000003CDE58C78 1876 package body SYS.DBMS_METADATA
00000003CDE58C78 2651 package body SYS.DBMS_METADATA
.
.
.
.

Neste banco que é de homologação, o usuário TEST que aparece no trace foi criado para fazer uns de com o scheduler do banco.

Ao atribuir permissão na tablespace SYSAUX o erro não apareceu mais.

Obrigado pela ajuda.

Abraço,

Airton

[José Laurindo ChiappaModerador]

ok , teu caso era a opção 1, mais simples…. Fico contente de poder ter ajudado, e espero que mais do que a solução do problema imediato, tenha conseguido também te passar um pouco de Metodologia e Métodos de debug/error troubleshooting….

[]s

Chiappa

[Autor]

Posts