Menu de navegação

[airoospParticipante]

Boa tarde,

Será que os(as) colegas podem ajudar, banco 10g ( Windows )o cenário é o seguinte:

Em um banco A tenho o schema COMPRAS com suas tabelas, views, trigger, procedure, etc, etc. Fiz a exportação usando o DATAPUMP, e na importação também.

Só que após importar as triggers no banco B, aconteceu o seguinte:

SCHEMA COMPRAS: ( banco A )

CREATE OR REPLACE TRIGGER COMPRAS.”TRG_BU_ALMOX”
before UPDATE on COMPRAS.ALMOX
for each row
.
.
.

SCHEMA COMPRAS2: ( banco B )

CREATE OR REPLACE TRIGGER COMPRAS2.”TRG_BU_ALMOX”
before UPDATE on COMPRAS.ALMOX
for each row
.
.
.

Foi criada com erro de compilação, pois mesmo sendo criada no COMPRAS2, a linha “before UPDATE on” continuou apontando para a tabela do schema COMPRAS.

A minha pergunta é, há alguma forma de no momento de importar já fazer o ajuste para a tabela do schema de destino?

Pergunto, pois por enquanto foi um teste com poucos objetos, mas se o schema tiver 50 triggers, alterar uma a uma?

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Então : pra variar vc *** não diz *** quais parâmetros usou (de repende ao usar o recomendado REMAP_SCHEMA ou o equivalente FROMUSER/TOUSER vc ao invés simplesmente conectou o import com o usuário destino, ou qquer asnice do tipo, sei lá) , mas que eu saiba, via de regra os objetos programados (como procedures, triggers, packages, etc) vão ser transferidos para o novo schema EXATAMENTE COMO ESTAVAM, apenas no usuário destino….

Um exemplo (envolvendo um banco 11gR2 EE e um banco XE, não tinha banco 10g pra simular seu caso) : veja que no schema possui triggers, inclusive triggers que chamam procedures, normal :

HR:@orcl:SQL>select table_name, trigger_name, trigger_body from user_triggers;

TABLE_NAME TRIGGER_NAME TRIGGER_BODY
—————————— —————————— ——————————————————————————–
EMPLOYEES UPDATE_JOB_HISTORY BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate,
:old.job_id, :old.department_id);
END;

EMPLOYEES SECURE_EMPLOYEES BEGIN
secure_dml;
END secure_employees;

HR:@orcl:SQL>exec DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, ‘SQLTERMINATOR’, true);

PL/SQL procedure successfully completed.

HR:@orcl:SQL>exec DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, ‘PRETTY’, true);

PL/SQL procedure successfully completed.

HR:@orcl:SQL> SELECT TABLE_NAME, TRIGGER_NAME, DBMS_METADATA.get_ddl (‘TRIGGER’, trigger_name, user) from user_triggers;
HR:@orcl:SQL>/

TABLE_NAME TRIGGER_NAME
—————————— ——————————
DBMS_METADATA.GET_DDL(‘TRIGGER’,TRIGGER_NAME,USER)
——————————————————————————–
EMPLOYEES UPDATE_JOB_HISTORY

CREATE OR REPLACE TRIGGER “HR”.”UPDATE_JOB_HISTORY”
AFTER UPDATE OF job_id, department_id ON employees
FOR EACH ROW
BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate,
:old.job_id, :old.department_id);
END;
/
ALTER TRIGGER “HR”.”UPDATE_JOB_HISTORY” ENABLE;

EMPLOYEES SECURE_EMPLOYEES

CREATE OR REPLACE TRIGGER “HR”.”SECURE_EMPLOYEES”
BEFORE INSERT OR UPDATE OR DELETE ON employees
BEGIN
secure_dml;
END secure_employees;
/
ALTER TRIGGER “HR”.”SECURE_EMPLOYEES” DISABLE;

HR:@orcl:SQL>

==> Só para conhecimento, vou contar os objetos que pertencem ao schema HR ** e ** os que o HR tem acesso, neste banco :

HR:@orcl:SQL>select owner, object_type, status, count(*) from ALL_OBJECTS group by owner, object_type, status order by 1,2,3;

OWNER OBJECT_TYPE STATUS COUNT(*)
—————- ——————- ——- ———-
A TABLE VALID 1
APEX_040100 FUNCTION VALID 4
APEX_040100 INDEX VALID 1238
APEX_040100 PACKAGE VALID 56
APEX_040100 PROCEDURE VALID 13
APEX_040100 SEQUENCE VALID 2
APEX_040100 SYNONYM VALID 56
APEX_040100 TABLE VALID 436
APEX_040100 TYPE VALID 2
APEX_040100 VIEW VALID 184
APPQOSSYS SYNONYM VALID 1
APPQOSSYS TABLE VALID 4
B TABLE VALID 1
BI SYNONYM VALID 8
CACHEADM INDEX VALID 6
CACHEADM TABLE VALID 6
CTXSYS INDEX VALID 59
CTXSYS INDEXTYPE VALID 4
CTXSYS OPERATOR VALID 6
CTXSYS PACKAGE VALID 13
CTXSYS TABLE VALID 49
CTXSYS TYPE VALID 9
CTXSYS VIEW VALID 76
DBSNMP INDEX VALID 13
DBSNMP PACKAGE VALID 1
DBSNMP SYNONYM VALID 1
DBSNMP TABLE VALID 25
DBSNMP VIEW VALID 7
DEMO INDEX VALID 8
DEMO TABLE VALID 7
EXFSYS FUNCTION VALID 4
EXFSYS INDEX VALID 39
EXFSYS INDEXTYPE VALID 1
EXFSYS JAVA CLASS VALID 1
EXFSYS OPERATOR VALID 1
EXFSYS PACKAGE VALID 7
EXFSYS PROCEDURE VALID 1
EXFSYS TABLE VALID 47
EXFSYS TYPE VALID 27
EXFSYS VIEW VALID 57
FLOWS_FILES INDEX VALID 4
FLOWS_FILES SYNONYM VALID 5
FLOWS_FILES TABLE VALID 1
HR INDEX VALID 19
HR PROCEDURE VALID 2
HR SEQUENCE VALID 3
HR TABLE VALID 8
HR TRIGGER VALID 2
HR VIEW VALID 1
HR1 INDEX VALID 19
HR1 TABLE VALID 7
HR1 VIEW VALID 1
IX INDEX VALID 14
IX TABLE VALID 17
IX VIEW VALID 8
MDSYS FUNCTION VALID 73
MDSYS INDEX VALID 114
MDSYS INDEXTYPE VALID 2
MDSYS JAVA CLASS VALID 531
MDSYS JAVA RESOURCE VALID 3
MDSYS OPERATOR VALID 25
MDSYS PACKAGE INVALID 1
MDSYS PACKAGE VALID 40
MDSYS SEQUENCE VALID 6
MDSYS TABLE VALID 123
MDSYS TYPE VALID 139
MDSYS VIEW VALID 86
OBE INDEX VALID 59
OBE TABLE VALID 29
OBE VIEW VALID 9
OE INDEX VALID 24
OE SYNONYM INVALID 5
OE SYNONYM VALID 1
OE TABLE VALID 9
OE VIEW VALID 5
OE1 INDEX VALID 23
OE1 SYNONYM VALID 6
OE1 TABLE VALID 8
OE1 VIEW VALID 5
OLAPSYS INDEX VALID 137
OLAPSYS PACKAGE VALID 3
OLAPSYS SEQUENCE VALID 1
OLAPSYS TABLE VALID 126
OLAPSYS VIEW VALID 307
ORDDATA INDEX VALID 129
ORDDATA TABLE VALID 73
ORDDATA VIEW VALID 25
ORDPLUGINS PACKAGE VALID 5
ORDSYS FUNCTION VALID 32
ORDSYS INDEX VALID 4
ORDSYS JAVA CLASS VALID 1871
ORDSYS JAVA RESOURCE VALID 72
ORDSYS PACKAGE VALID 19
ORDSYS PROCEDURE VALID 7
ORDSYS TABLE VALID 5
ORDSYS TYPE VALID 485
ORDSYS VIEW VALID 5
OUTLN INDEX VALID 4
OUTLN TABLE VALID 3
OWBSYS INDEX VALID 1
OWBSYS TABLE VALID 1
OWBSYS_AUDIT SYNONYM VALID 12
PHPDEMO INDEX VALID 25
PHPDEMO TABLE VALID 23
PHPDEMO VIEW VALID 1
PLS INDEX VALID 6
PLS TABLE VALID 5
PM INDEX VALID 4
PM TABLE VALID 3
PUBLIC SYNONYM INVALID 29
PUBLIC SYNONYM VALID 27898
SCOTT INDEX VALID 8
SCOTT SYNONYM VALID 1
SCOTT TABLE VALID 11
SH INDEX VALID 27
SH INDEX PARTITION VALID 196
SH MATERIALIZED VIEW VALID 2
SH TABLE VALID 17
SH TABLE PARTITION VALID 56
SH VIEW VALID 1
SI_INFORMTN_SCHE SYNONYM VALID 8
MA

SYS CLUSTER VALID 10
SYS CONSUMER GROUP VALID 2
SYS DESTINATION VALID 2
SYS DIRECTORY VALID 9
SYS EDITION VALID 2
SYS EVALUATION CONTEXT VALID 1
SYS FUNCTION VALID 88
SYS INDEX VALID 1037
SYS INDEX PARTITION VALID 53
SYS JAVA CLASS VALID 20421
SYS JAVA RESOURCE VALID 763
SYS JOB CLASS VALID 2
SYS OPERATOR VALID 7
SYS PACKAGE VALID 319
SYS PROCEDURE VALID 17
SYS PROGRAM VALID 11
SYS SCHEDULE VALID 3
SYS SCHEDULER GROUP VALID 4
SYS SEQUENCE VALID 3
SYS SYNONYM VALID 9
SYS TABLE VALID 1012
SYS TABLE PARTITION VALID 51
SYS TABLE SUBPARTITION VALID 32
SYS TYPE VALID 769
SYS VIEW INVALID 5
SYS VIEW VALID 3850
SYS WINDOW VALID 9
SYSMAN INDEX VALID 953
SYSMAN MATERIALIZED VIEW VALID 1
SYSMAN TABLE VALID 729
SYSMAN VIEW VALID 471
SYSTEM INDEX VALID 217
SYSTEM INDEX PARTITION VALID 52
SYSTEM SYNONYM VALID 9
SYSTEM TABLE VALID 175
SYSTEM TABLE PARTITION VALID 39
SYSTEM VIEW VALID 12
TIMESTEN TABLE VALID 2
TTHR INDEX VALID 19
TTHR TABLE VALID 7
TTHR VIEW VALID 1
WMSYS FUNCTION VALID 4
WMSYS INDEX VALID 61
WMSYS OPERATOR VALID 9
WMSYS PACKAGE VALID 6
WMSYS TABLE VALID 45
WMSYS TYPE VALID 8
WMSYS VIEW INVALID 9
WMSYS VIEW VALID 101
XDB FUNCTION VALID 5
XDB INDEX VALID 129
XDB INDEXTYPE VALID 2
XDB OPERATOR VALID 7
XDB PACKAGE VALID 33
XDB SEQUENCE VALID 1
XDB TABLE VALID 86
XDB TYPE VALID 91
XDB VIEW VALID 6
XDB XML SCHEMA VALID 57
XDBEXT INDEX VALID 63
XDBEXT PACKAGE VALID 5
XDBEXT TABLE VALID 31
XDBEXT TYPE VALID 1
XDBEXT VIEW VALID 2
XDBPM INDEX VALID 7
XDBPM JAVA CLASS VALID 4
XDBPM PACKAGE VALID 20
XDBPM SEQUENCE VALID 1
XDBPM SYNONYM VALID 22
XDBPM TABLE VALID 9
XDBPM TRIGGER VALID 1
XDBPM TYPE VALID 5
XDBPM VIEW VALID 11
XFILES INDEX VALID 57
XFILES PACKAGE VALID 17
XFILES TABLE VALID 30
XFILES VIEW VALID 18
ZEZINHO TABLE VALID 1

199 rows selected.

HR:@orcl:SQL>

===>>> AGORA vou fazer o export a nível de Schema :

[oracle@localhost ~]$ expdp system/oracle directory=data_pump_dir schemas=HR dumpfile=dump_schema_hr logfile=dump_schema_hr.expdp

Export: Release 11.2.0.2.0 – Production

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting “SYSTEM”.”SYS_EXPORT_SCHEMA_01″: system/******** directory=data_pump_dir schemas=HR dumpfile=dump_schema_hr logfile=dump_schema_hr.expdp
Estimate in progress using BLOCKS method…
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 512 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported “HR”.”AVG_SALARY” 5.007 KB 1 rows
. . exported “HR”.”COUNTRIES” 6.367 KB 25 rows
. . exported “HR”.”DEPARTMENTS” 7.023 KB 28 rows
. . exported “HR”.”EMPLOYEES” 16.79 KB 107 rows
. . exported “HR”.”JOBS” 6.984 KB 19 rows
. . exported “HR”.”JOB_HISTORY” 7.054 KB 10 rows
. . exported “HR”.”LOCATIONS” 8.273 KB 23 rows
. . exported “HR”.”REGIONS” 5.476 KB 4 rows
Master table “SYSTEM”.”SYS_EXPORT_SCHEMA_01″ successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
/home/oracle/app/oracle/admin/orcl/dpdump/dump_schema_hr.dmp
Job “SYSTEM”.”SYS_EXPORT_SCHEMA_01″ successfully completed

[oracle@localhost ~]$

===> Movo o dump file para a outra máquina (Windows no caso) onde está o XE que vai servir de banco-destino…
Isso feito, vou pré-criar o usuário :

system@XE:SQL> create user H2 identified by H2 default tablespace USERS temporary tablespace temp;

Usuário criado.

system@XE:SQL> grant connect, resource to h2;

Concessão bem-sucedida.

SQL>exit;

==> Agora faço o import, *** PASSANDO O ARGUMENTO DE TROCAR DE USUÁRIO ***, cfrme :

C:oraclexeapporacleadminXEdpdump>impdp system/oracle directory=DATA_PUMP_DIR dumpfile=dump_schema_hr.dmp logfile=dump_schema_hr.impdp fromuser=hr touser=h2

Import: Release 11.2.0.2.0 – Production

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Conectado a: Oracle Database 11g Express Edition Release 11.2.0.2.0 – 64bit Production
Modo Legado Ativo devido aos seguintes parâmetros:
Parâmetro do Modo Legado: “fromuser=hr” Localização: Command Line, Substituído com: “remap_schema”
Tabela-mestre “SYSTEM”.”SYS_IMPORT_FULL_01″ carregada/descarregada com sucesso
Iniciando “SYSTEM”.”SYS_IMPORT_FULL_01″: system/******** directory=DATA_PUMP_DIR dumpfile=dump_schema_hr.dmp logfile=dump_schema_hr.impdp remap_schema=hr:h2
Processando o tipo de objeto SCHEMA_EXPORT/USER
ORA-31684: O tipo de objeto USER:”H2″ já existe
Processando o tipo de objeto SCHEMA_EXPORT/SYSTEM_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/ROLE_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/DEFAULT_ROLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLESPACE_QUOTA
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
. . importou “H2″.”AVG_SALARY” 5.007 KB 1 linhas
. . importou “H2″.”COUNTRIES” 6.367 KB 25 linhas
. . importou “H2″.”DEPARTMENTS” 7.023 KB 28 linhas
. . importou “H2″.”EMPLOYEES” 16.79 KB 107 linhas
. . importou “H2″.”JOBS” 6.984 KB 19 linhas
. . importou “H2″.”JOB_HISTORY” 7.054 KB 10 linhas
. . importou “H2″.”LOCATIONS” 8.273 KB 23 linhas
. . importou “H2″.”REGIONS” 5.476 KB 4 linhas
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/COMMENT
Processando o tipo de objeto SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processando o tipo de objeto SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processando o tipo de objeto SCHEMA_EXPORT/VIEW/VIEW
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TRIGGER
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
O job “SYSTEM”.”SYS_IMPORT_FULL_01″ foi concluído com 1 erro(s)

C:oraclexeapporacleadminXEdpdump>

===>> No caso o “erro” foi simplesmente eu ter pré-criado o usuário, sem probs… OK, vou conectar no banco XE com o usuário H2 que foi o destino e veja o resultado :

H2@XE:SQL>exec DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, ‘SQLTERMINATOR’, true);

Procedimento PL/SQL concluído com sucesso.

H2@XE:SQL>exec DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, ‘PRETTY’, true);

Procedimento PL/SQL concluído com sucesso.

H2@XE:SQL>select table_name, trigger_name, trigger_body from user_triggers;

TABLE_NAME TRIGGER_NAME
—————————— ——————————
TRIGGER_BODY
——————————————————————————–
EMPLOYEES UPDATE_JOB_HISTORY
BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate,

EMPLOYEES SECURE_EMPLOYEES
BEGIN
secure_dml;
END secure_employees;

TABLE_NAME TRIGGER_NAME
—————————— ——————————
TRIGGER_BODY
——————————————————————————–

H2@XE:SQL>set pages 50000 lines 138
H2@XE:SQL>/

TABLE_NAME TRIGGER_NAME
—————————— ——————————
TRIGGER_BODY
——————————————————————————–
EMPLOYEES UPDATE_JOB_HISTORY
BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate,

EMPLOYEES SECURE_EMPLOYEES
BEGIN
secure_dml;
END secure_employees;

H2@XE:SQL>

H2@XE:SQL>SELECT TABLE_NAME, TRIGGER_NAME, DBMS_METADATA.get_ddl (‘TRIGGER’, trigger_name, user) from user_triggers;

TABLE_NAME TRIGGER_NAME
—————————— ——————————
DBMS_METADATA.GET_DDL(‘TRIGGER’,TRIGGER_NAME,USER)
——————————————————————————–
EMPLOYEES UPDATE_JOB_HISTORY

CREATE OR REPLACE TRIGGER “H2″.”UPDATE_JOB_HISTORY”
AFTER UPDATE OF job_id, department_id ON employees
FOR EACH ROW
BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate,
:old.job_id, :old.department_id);
END;

/
ALTER TRIGGER “H2″.”UPDATE_JOB_HISTORY” ENABLE;

EMPLOYEES SECURE_EMPLOYEES

CREATE OR REPLACE TRIGGER “H2″.”SECURE_EMPLOYEES”
BEFORE INSERT OR UPDATE OR DELETE ON employees
BEGIN
secure_dml;
END secure_employees;

/
ALTER TRIGGER “H2″.”SECURE_EMPLOYEES” DISABLE;

H2@XE:SQL>

==> vamos ver a listagem de Objetos :

H2@XE:SQL>select owner, object_type, status, count(*) from ALL_OBJECTS group by owner, object_type, status order by 1,2,3;

OWNER OBJECT_TYPE STATUS COUNT(*)
—————————— ——————- ——- ———-
APEX_040000 FUNCTION VALID 4
APEX_040000 INDEX VALID 1177
APEX_040000 PACKAGE VALID 54
APEX_040000 PROCEDURE VALID 13
APEX_040000 SEQUENCE VALID 2
APEX_040000 SYNONYM VALID 54
APEX_040000 TABLE VALID 426
APEX_040000 TYPE VALID 2
APEX_040000 VIEW VALID 175
APPQOSSYS SYNONYM VALID 1
APPQOSSYS TABLE VALID 4
BI SYNONYM VALID 8
CTXSYS INDEX VALID 59
CTXSYS INDEXTYPE VALID 4
CTXSYS OPERATOR VALID 6
CTXSYS PACKAGE VALID 13
CTXSYS TABLE VALID 49
CTXSYS TYPE VALID 9
CTXSYS VIEW VALID 76
DBSNMP INDEX VALID 10
DBSNMP SYNONYM VALID 1
DBSNMP TABLE VALID 20
DBSNMP VIEW VALID 7
FLOWS_FILES INDEX VALID 4
FLOWS_FILES SYNONYM VALID 5
FLOWS_FILES TABLE VALID 1
HR INDEX VALID 22
HR TABLE VALID 16
HR VIEW VALID 1
H2 INDEX VALID 19
H2 PROCEDURE VALID 2
H2 SEQUENCE VALID 3
H2 TABLE VALID 8
H2 TRIGGER VALID 2
H2 VIEW VALID 1
IX INDEX VALID 14
IX TABLE VALID 17
IX VIEW VALID 8
MDSYS FUNCTION VALID 72
MDSYS INDEX VALID 91
MDSYS INDEXTYPE VALID 2
MDSYS OPERATOR VALID 25
MDSYS PACKAGE VALID 19
MDSYS SEQUENCE VALID 3
MDSYS TABLE VALID 76
MDSYS TYPE VALID 145
MDSYS VIEW VALID 65
OE INDEX VALID 33
OE SYNONYM VALID 6
OE TABLE VALID 14
OE VIEW VALID 13
OUTLN INDEX VALID 4
OUTLN TABLE VALID 3
PM INDEX VALID 3
PM TABLE VALID 2
PUBLIC SYNONYM VALID 3982
SCOTT INDEX VALID 3
SCOTT TABLE VALID 10
SCOTT VIEW VALID 2
SH INDEX VALID 12
SH TABLE VALID 12
SYS CLUSTER VALID 10
SYS CONSUMER GROUP VALID 2
SYS DESTINATION VALID 2
SYS DIRECTORY VALID 10
SYS EDITION VALID 1
SYS EVALUATION CONTEXT VALID 1
SYS FUNCTION VALID 84
SYS INDEX VALID 1009
SYS INDEX PARTITION VALID 74
SYS JOB CLASS VALID 2
SYS OPERATOR VALID 7
SYS PACKAGE VALID 277
SYS PROCEDURE VALID 16
SYS PROGRAM VALID 11
SYS SCHEDULE VALID 3
SYS SCHEDULER GROUP VALID 4
SYS SEQUENCE VALID 3
SYS SYNONYM VALID 9
SYS TABLE VALID 968
SYS TABLE PARTITION VALID 71
SYS TABLE SUBPARTITION VALID 32
SYS TYPE VALID 750
SYS VIEW VALID 3755
SYS WINDOW VALID 9
SYSTEM INDEX VALID 212
SYSTEM INDEX PARTITION VALID 52
SYSTEM SYNONYM VALID 8
SYSTEM TABLE VALID 161
SYSTEM TABLE PARTITION VALID 39
SYSTEM VIEW VALID 12
XDB FUNCTION VALID 6
XDB INDEX VALID 110
XDB INDEXTYPE VALID 2
XDB OPERATOR VALID 7
XDB PACKAGE VALID 28
XDB SEQUENCE VALID 1
XDB TABLE VALID 79
XDB TYPE VALID 90
XDB VIEW VALID 5
XDB XML SCHEMA VALID 31
ZEZINHO TABLE VALID 1

102 linhas selecionadas.

H2@XE:SQL>
==> Veja que no schema origem (HR do banco EE) existiam :

HR INDEX VALID 19
HR PROCEDURE VALID 2
HR SEQUENCE VALID 3
HR TABLE VALID 8
HR TRIGGER VALID 2
HR VIEW VALID 1

==> e no schema H2 que importou os objetos do HR lá no banco XE destino o H2 ficou com :

H2 INDEX VALID 19
H2 PROCEDURE VALID 2
H2 SEQUENCE VALID 3
H2 TABLE VALID 8
H2 TRIGGER VALID 2
H2 VIEW VALID 1

===>> TUDO IGUALZINHO, válido… OK ??

Então pra mim se não foi EXATAMENTE ISSO que vc obteve, OU vc ecnontrou um bug OU vc falhou em algum dos passos…

[]s

Chiappa

[C-S-RParticipante]

Opa Airton blz?

Então cara acredito que o Remap_schema e o touser from user não afete o conteúdo das triggers, igual ao conteúdo de funções e procedures.

O teste do Chiappa não esta com o schema cravado no body da trigger por isso deu certo.

Para Remap_schema

For triggers, REMAP_SCHEMA affects only the trigger owner.

https://docs.oracle.com/database/121/SUTIL/GUID-619809A6-1966-42D6-9ACC-A3E0ADC36523.htm#SUTIL927

Para touser from user

Schema names that appear inside functional indexes, functions, procedures, triggers, type bodies, views, and so on, are not affected by FROMUSER or TOUSER processing.

https://docs.oracle.com/cd/B10501_01/server.920/a96652/ch02.htm#1005426

Acredito que se vc tirar os schemas da base original resolva, mas seria o mesmo que arrumar na base destino. kkkkkkk

Espero ter ajudado

Att

Cesar Moraes

[C-S-RParticipante]

Ah dei uma olhada rápida na documentação. Não consegui efetuar testes.

Sempre o teste é a melhor opção. rsrsrs

[José Laurindo ChiappaModerador]

Isso aí , C-S-R : como eu disse na minha resposta, “os objetos programados (como procedures, triggers, packages, etc) vão ser transferidos para o novo schema EXATAMENTE COMO ESTAVAM, apenas no usuário destino” : mais que Óbvio, se por qualquer motivo a trigger no schema origem foi codificada com :

BEGIN
COMPRAS.nomedeumaprocedure;
…
END;

===> Claro que o comando de importação mesmo que vc use FROMUSER/TOUSER ou REMAP_SCHEMA apontando para um schema COMPRAS2, ele vai conectar no schema COMPRAS2 e mandar lá exatamente o mesmo código :

BEGIN
COMPRAS.nomedeumaprocedure;
…
END;

que estava codificado…. Realmente, no meu exemplo onde o código da trigger estava como :

BEGIN
add_job_history(:old.employee_id, :old.hire_date, sysdate, :old.job_id, :old.department_id);
END;
/

e como :

BEGIN
secure_dml;
END secure_employees;
/

SEM referenciar o schema-dono das procedures/functions add_job_history e secure_dml dentro do código da trigger, aí sem probs…

O FATO é esse mesmo, o FROMUSER/TOUSER ou REMAP_SCHEMA simplesmente pega o código-fonte no schema origem e o recompila no schema destino DO JEITINHO EXATO que estava, se qquer código PL/SQL referencia outros schemas dentro de si tal código NÂO SERÁ re-escrito…

Airton, se é realmente este o seu caso, IMHO o procedimento mais fácil para alterar esse schema COMPRAS hard-coded em tuas triggers sem ter que editar na mão cada um deles seria escrever uma rotina que obtenha uma string com o código-fonte (normalmente via DBMS_METADATA, mas iirc vc estava com problemas na sua versão 10g pra isso, então talvez tenha que apelar pra DBA/ALL/USER_SOURCE ou DBA/ALL/USER_TRIGGERS) , depois usar as funções string do RDBMS Oracle (principalmente a TRANSLATE) para trocar ‘COMPRAS.’ por ‘COMPRAS2.’ e finalmente executar esse DDL alterado no banco-destino, é isso…

[]s

Chiappa

[José Laurindo ChiappaModerador]

Airton, só complementando : pelo jeito, esse comportamente de criar o programa PL/SQL com erro/inválida se houver algum schema hard-coded inacessível no código dele tal como vc relata é algo que existia no 10g (que vc disse que era a sua versão, E que não tenho no momento uma instância pra testar) – no 11g de acordo com meu teste abaixo a programa PL/SQL (trigger no meu caso, tal como o que vc relata) simplesmente não é criada :

==> No banco origem o schema PLS (que vai ser duplicado com outro nome no banco-destino) tem uma trigger que chama uma procedure com o schema-owner hard-coded :

PLS:@orcl:SQL>select table_name, trigger_body from user_triggers;

TABLE_NAME TRIGGER_BODY
—————————— ——————————————————————————–
ACCOUNTS BEGIN
PLS.PROC_TESTE_PLS;
END;

PLS:@orcl:SQL>

==> faço o export , só do schema PLS :

[oracle@localhost ~]$ expdp system/oracle directory=data_pump_dir schemas=PLS dumpfile=dump_schema_pls logfile=dump_schema_pls.expdp

Export: Release 11.2.0.2.0 – Production

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting “SYSTEM”.”SYS_EXPORT_SCHEMA_01″: system/******** directory=data_pump_dir schemas=PLS dumpfile=dump_schema_pls logfile=dump_schema_pls.expdp
Estimate in progress using BLOCKS method…
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 256 KB
….
etc, etc
…
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
. . exported “PLS”.”ACCOUNTS” 6.328 KB 1 rows
. . exported “PLS”.”BRANCHES” 5.867 KB 1 rows
. . exported “PLS”.”SBTEST” 8.546 KB 12 rows
. . exported “PLS”.”TELLERS” 6.484 KB 10 rows
. . exported “PLS”.”HISTORY” 0 KB 0 rows
Master table “SYSTEM”.”SYS_EXPORT_SCHEMA_01″ successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
/home/oracle/app/oracle/admin/orcl/dpdump/dump_schema_pls.dmp
Job “SYSTEM”.”SYS_EXPORT_SCHEMA_01″ successfully completed

[oracle@localhost ~]$

==> transferi o .dmp pra máquina-destino onde roda a minha base XE 11g que vai importar o schema com outro nome, e faço o import : *** OBVIAMENTE ***, nessa base Já Existem as tablespaces necessárias – relembremos que TABLESPACES são objetos a nível de BANCO, então Obviamente não vão ser criadas por um export de schema…
Assim :

C:oraclexeapporacleadminXEdpdump>impdp system/oracle directory=data_pump_dir fromuser=PLS touser=PLS2 dumpfile=dump_schema_pls logfile=dump_schema_pls.impdp

Import: Release 11.2.0.2.0 – Production

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Conectado a: Oracle Database 11g Express Edition Release 11.2.0.2.0 – 64bit Production
Modo Legado Ativo devido aos seguintes parâmetros:
Parâmetro do Modo Legado: “fromuser=PLS” Localização: Command Line, Substituído com: “remap_schema”
Tabela-mestre “SYSTEM”.”SYS_IMPORT_FULL_01″ carregada/descarregada com sucesso
Iniciando “SYSTEM”.”SYS_IMPORT_FULL_01″: system/******** directory=data_pump_dir remap_schema=PLS:PLS2 dumpfile=dump_schema_pls logfile=dump_schema_pls.impdp
Processando o tipo de objeto SCHEMA_EXPORT/USER
Processando o tipo de objeto SCHEMA_EXPORT/SYSTEM_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/ROLE_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/DEFAULT_ROLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLESPACE_QUOTA
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
. . importou “PLS2″.”ACCOUNTS” 6.328 KB 1 linhas
. . importou “PLS2″.”BRANCHES” 5.867 KB 1 linhas
. . importou “PLS2″.”SBTEST” 8.546 KB 12 linhas
. . importou “PLS2″.”TELLERS” 6.484 KB 10 linhas
. . importou “PLS2″.”HISTORY” 0 KB 0 linhas

==>> casualmente, o owner PLS tinha dado GRANTs / permissões para OUTROS usuários lá no banco-origem, sendo que esses usuários não existem no banco-destino : veja os Warnings sobre isso :

Processando o tipo de objeto SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
ORA-39083: Tipo de objeto OBJECT_GRANT falhou ao ser criado com o erro:
ORA-01917: o usuário ou a atribuição ‘CACHEADM’ não existe
O código sql com falha é:
GRANT DELETE, INSERT, SELECT, UPDATE ON “PLS2″.”ACCOUNTS” TO “CACHEADM”
ORA-39083: Tipo de objeto OBJECT_GRANT falhou ao ser criado com o erro:
ORA-01917: o usuário ou a atribuição ‘CACHEADM’ não existe
O código sql com falha é:
GRANT DELETE, INSERT, SELECT, UPDATE ON “PLS2″.”BRANCHES” TO “CACHEADM”
ORA-39083: Tipo de objeto OBJECT_GRANT falhou ao ser criado com o erro:
ORA-01917: o usuário ou a atribuição ‘CACHEADM’ não existe
O código sql com falha é:
GRANT DELETE, INSERT, SELECT, UPDATE ON “PLS2″.”TELLERS” TO “CACHEADM”
ORA-39083: Tipo de objeto OBJECT_GRANT falhou ao ser criado com o erro:
ORA-01917: o usuário ou a atribuição ‘CACHEADM’ não existe
O código sql com falha é:
GRANT DELETE, INSERT, SELECT, UPDATE ON “PLS2″.”HISTORY” TO “CACHEADM”
ORA-39083: Tipo de objeto OBJECT_GRANT falhou ao ser criado com o erro:
ORA-01917: o usuário ou a atribuição ‘CACHEADM’ não existe
O código sql com falha é:
GRANT DELETE, INSERT, SELECT, UPDATE ON “PLS2″.”SBTEST” TO “CACHEADM”
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/INDEX
….

==> Abaixo é o ponto : o impdp vai tentar fazer o CREATE da trigger, como o código-fonte da trigger tem um elemento que ele não entende/não existe, dá erro :

Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processando o tipo de objeto SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processando o tipo de objeto SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TRIGGER
ORA-39083: Tipo de objeto TRIGGER falhou ao ser criado com o erro:
ORA-00942: a tabela ou view não existe
O código sql com falha é:
CREATE TRIGGER “PLS2″.”TRG_PROC_TESTE_PLS”
BEFORE DELETE OR INSERT OR UPDATE ON PLS.ACCOUNTS
BEGIN
PLS.PROC_TESTE_PLS;
END;
O job “SYSTEM”.”SYS_IMPORT_FULL_01″ foi concluído com 6 erro(s)

C:oraclexeapporacleadminXEdpdump>

==> As tabelas e demais objetos não-programados vieram Certinho :

PLS2:@XE:SQL>select object_type, object_name, status from user_objects order by 1,2;

OBJECT_TYPE OBJECT_NAME STATUS
——————- —————————— ——-
INDEX K_IDX VALID
INDEX SYS_C007452 VALID
INDEX SYS_C007453 VALID
INDEX SYS_C007454 VALID
INDEX SYS_C007455 VALID
INDEX SYS_C007456 VALID
PACKAGE WORKLOAD VALID
PACKAGE BODY WORKLOAD VALID
PROCEDURE PROC_TESTE_PLS VALID
SEQUENCE HISTORY_SEQ VALID
SEQUENCE SBTEST_SEQ VALID
TABLE ACCOUNTS VALID
TABLE BRANCHES VALID
TABLE HISTORY VALID
TABLE SBTEST VALID
TABLE TELLERS VALID

16 linhas selecionadas.

PLS2:@XE:SQL>

==> MAS a trigger que ele foi incapaz de compilar ao invés de criar com erro aqui neste 11g ele simplesmente não criou – como eu disse, ao que parece foi esse o comportamento alterado desde o seu 10g até esse 11g :

PLS2:@XE:SQL>select table_name, trigger_body from user_triggers;

não há linhas selecionadas

PLS2:@XE:SQL>

[]s

Chiappa

OBS : neste caso específico onde o obejto com código inválido não é criado no banco-destino Logicamente eu apelaria para outras possibilidades, que INCLUSIVE vc também pode lançar mão, como extrair o código lá do banco-origem pra um arquivo-texto (via DBMS_METADATA com SPOOL, ou uma rotininha PL/SQL que abre curor na DBA/ALL/USER_TRIGGERS, ou coisas assim), OU então extrair o código-fonte de dentro do próprio dumpfile via impdp mesmo pra um arquivo-texto, que depois vc simplesmente troca a string via editor de texto ou via grep/awk/qquer utilitário que vc tiver…
Já dei em outras threads aqui deste Fórum mesmo um exemplinho extraindo código do banco, segue um exeplinho extraindo código do dumpfile (no caso só o DDL das triggers me interessa) :

C:oraclexeapporacleadminXEdpdump>impdp system/oracle directory=data_pump_dir fromuser=PLS touser=PLS2 dumpfile=dump_schema_pls logfile=dump_schema_pls_DDL.impdp sqlfile=dump_schema_pls_DDL.sql include=trigger

Import: Release 11.2.0.2.0 – Production

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Conectado a: Oracle Database 11g Express Edition Release 11.2.0.2.0 – 64bit Production
Modo Legado Ativo devido aos seguintes parâmetros:
Parâmetro do Modo Legado: “fromuser=PLS” Localização: Command Line, Substituído com: “remap_schema”
Tabela-mestre “SYSTEM”.”SYS_SQL_FILE_FULL_01″ carregada/descarregada com sucesso
Iniciando “SYSTEM”.”SYS_SQL_FILE_FULL_01″: system/******** directory=data_pump_dir remap_schema=PLS:PLS2 dumpfile=dump_schema_pls logfile=dump_schema_pls_DDL.impdp sqlfile=dump_sc
hema_pls_DDL.sql include=trigger
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TRIGGER
O job “SYSTEM”.”SYS_SQL_FILE_FULL_01″ foi concluído com sucesso em 09:27:19

==> O resultado :

C:oraclexeapporacleadminXEdpdump>type dump_schema_pls_DDL.sql

— CONNECT SYSTEM
ALTER SESSION SET EVENTS ‘10150 TRACE NAME CONTEXT FOREVER, LEVEL 1’;
ALTER SESSION SET EVENTS ‘10904 TRACE NAME CONTEXT FOREVER, LEVEL 1’;
ALTER SESSION SET EVENTS ‘25475 TRACE NAME CONTEXT FOREVER, LEVEL 1’;
ALTER SESSION SET EVENTS ‘10407 TRACE NAME CONTEXT FOREVER, LEVEL 1’;
ALTER SESSION SET EVENTS ‘10851 TRACE NAME CONTEXT FOREVER, LEVEL 1’;
ALTER SESSION SET EVENTS ‘22830 TRACE NAME CONTEXT FOREVER, LEVEL 192 ‘;
— new object type path: SCHEMA_EXPORT/TABLE/TRIGGER
— CONNECT PLS2
CREATE TRIGGER “PLS2″.”TRG_PROC_TESTE_PLS”
BEFORE DELETE OR INSERT OR UPDATE ON PLS.ACCOUNTS
BEGIN
PLS.PROC_TESTE_PLS;
END;
/

ALTER TRIGGER “PLS2″.”TRG_PROC_TESTE_PLS” ENABLE;

ALTER TRIGGER “PLS2″.”TRG_PROC_TESTE_PLS”
COMPILE
PLSQL_OPTIMIZE_LEVEL= 2
PLSQL_CODE_TYPE= INTERPRETED PLSCOPE_SETTINGS= ‘IDENTIFIERS:ALL’
;

C:oraclexeapporacleadminXEdpdump>

[Autor]

Posts