数据泵无法导入JOB

最新推荐文章于 2021-06-25 15:25:06 发布

ckawt40802

最新推荐文章于 2021-06-25 15:25:06 发布

阅读量145

点赞数

文章标签：数据库

10g的数据泵在进行IMPDP的时候无法导入JOB。

通过一个例子来说明这个问题：

SQL> CREATE USER A IDENTIFIED BY A DEFAULT TABLESPACE YANGTK;

用户已创建。

SQL> GRANT CONNECT, RESOURCE TO A;

授权成功。

SQL> CREATE OR REPLACE DIRECTORY D_OUTPUT AS 'E:\';

目录已创建。

SQL> GRANT READ, WRITE ON DIRECTORY D_OUTPUT TO A;

授权成功。

SQL> CONN A/A@YTK102
已连接。
SQL> DECLARE
2 V_JOB NUMBER;
3 BEGIN
4 DBMS_JOB.SUBMIT(V_JOB, 'NULL;', SYSDATE, 'SYSDATE + 1');
5 COMMIT;
6 END;
7 /

PL/SQL 过程已成功完成。

SQL> COL WHAT FORMAT A30
SQL> SELECT JOB, WHAT FROM USER_JOBS;

JOB WHAT
---------- ------------------------------
66 NULL;

下面用A用户执行数据泵的导出：

E:\>expdp a/a@ytk102 directory=d_output dumpfile=a.dp

Export: Release 10.2.0.1.0 - Production on 星期二, 29 1月, 2008 9:49:18

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
启动 "A"."SYS_EXPORT_SCHEMA_01": a/********@ytk102 directory=d_output dumpfile=
a.dp
正在使用 BLOCKS 方法进行估计...
处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA
使用 BLOCKS 方法的总估计: 0 KB
处理对象类型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
处理对象类型 SCHEMA_EXPORT/TABLE/TABLE
处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/INDEX
处理对象类型 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
处理对象类型 SCHEMA_EXPORT/TABLE/COMMENT
处理对象类型 SCHEMA_EXPORT/JOB
已成功加载/卸载了主表 "A"."SYS_EXPORT_SCHEMA_01"
******************************************************************************
A.SYS_EXPORT_SCHEMA_01 的转储文件集为:
E:\A.DP
作业 "A"."SYS_EXPORT_SCHEMA_01" 已于 09:49:37 成功完成

下面删除A用户下的JOB：

SQL> EXEC DBMS_JOB.REMOVE(66)

PL/SQL 过程已成功完成。

SQL> COMMIT;

提交完成。

尝试通过数据泵IMPDP进行导入：

E:\>impdp a/a@ytk102 directory=d_output dumpfile=a.dp

Import: Release 10.2.0.1.0 - Production on 星期二, 29 1月, 2008 9:55:59

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORA-39154: 外部方案中的对象已从导入中删除
已成功加载/卸载了主表 "A"."SYS_IMPORT_FULL_01"
启动 "A"."SYS_IMPORT_FULL_01": a/********@ytk102 directory=d_output dumpfile=a.
dp
处理对象类型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
作业 "A"."SYS_IMPORT_FULL_01" 已于 09:56:01 成功完成

检查JOB是否导入：

SQL> SELECT JOB, WHAT FROM USER_JOBS;

未选定行

JOB没有导入，其实观察上面导入操作的输出就可以看到问题。首先导入报错了，而错误信息是“外部方案中的对象已从导入中删除”。而从导入的对象类型中也看不到JOB的信息，似乎JOB被当前其他SCHEMA的对象被屏蔽了。

E:\>impdp yangtk/yangtk@ytk102 directory=d_output dumpfile=a.dp remap_schema=a:a

Import: Release 10.2.0.1.0 - Production on 星期二, 29 1月, 2008 10:25:52

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
已成功加载/卸载了主表 "YANGTK"."SYS_IMPORT_FULL_01"
启动 "YANGTK"."SYS_IMPORT_FULL_01": yangtk/********@ytk102 directory=d_output d
umpfile=a.dp remap_schema=a:a
处理对象类型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
处理对象类型 SCHEMA_EXPORT/JOB
作业 "YANGTK"."SYS_IMPORT_FULL_01" 已于 10:25:54 成功完成

如果使用DBA用户执行导入，采用REMAP_SCHEMA方式，发现导入的时候处理了JOB，而且错误也消失了，那么是否问题解决了呢：

SQL> SELECT JOB, WHAT FROM USER_JOBS;

未选定行

SQL> CONN YANGTK/YANGTK@YTK102
已连接。
SQL> SELECT JOB, LOG_USER, WHAT FROM DBA_JOBS;

       JOB LOG_USER               WHAT
---------- ---------------------- -----------------------------------
         1 SYSMAN                   EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
        66 YANGTK                   NULL;

JOB虽然导入了，但是没有导入A用户，而是导入了YANGTK用户。这显然不是预期的结果。说明Oracle在处理REMAP_SCHEMA的时候，根本没有把JOB当作SCHEMA A的对象。

既然可以用YANGTK导入，那么使用A导入的时候也是可以的，唯一的区别是A用户没有DBA权限。

SQL> EXEC DBMS_JOB.REMOVE(66)

PL/SQL 过程已成功完成。

SQL> COMMIT;

提交完成。

SQL> GRANT IMP_FULL_DATABASE TO A;

授权成功。

将IMP_FULL_DATABASE角色授权给A用户，再次使用A用户执行导入：

E:\>impdp a/a@ytk102 directory=d_output dumpfile=a.dp

Import: Release 10.2.0.1.0 - Production on 星期二, 29 1月, 2008 10:43:22

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
已成功加载/卸载了主表 "A"."SYS_IMPORT_FULL_01"
启动 "A"."SYS_IMPORT_FULL_01": a/********@ytk102 directory=d_output dumpfile=a.
dp
处理对象类型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
处理对象类型 SCHEMA_EXPORT/JOB
作业 "A"."SYS_IMPORT_FULL_01" 已于 10:43:24 成功完成

发现已经处理了JOB，检查数据库中JOB的情况：

SQL> SELECT JOB, LOG_USER, WHAT FROM DBA_JOBS;

       JOB LOG_USER                 WHAT
---------- ------------------------ --------------------------------------------
         1 SYSMAN                  EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
        66 A                       NULL;

JOB已经成功导入。不过这种方式需要给用户授予一个远远超过自身需求的角色，存在比较大的安全问题，需要在导入结束后回收权限。而且对于多个用户的导出，采用这种方式将变得十分麻烦，必须对每个用户分别处理。

还有一种方式，采用NETWORK_LINK的方式可以解决JOB的导入问题：

SQL> CONN TEST/TEST@172.25.88.92/TESTZJ
已连接。
SQL> DECLARE
2 V_JOB NUMBER;
3 BEGIN
4 DBMS_JOB.SUBMIT(V_JOB, 'NULL;', SYSDATE, 'SYSDATE + 1');
5 COMMIT;
6 END;
7 /

PL/SQL 过程已成功完成。

SQL> CONN YANGTK/YANGTK@YTK102
已连接。
SQL> REVOKE IMP_FULL_DATABASE FROM A;

撤销成功。

SQL> GRANT CREATE DATABASE LINK TO A;

授权成功。

SQL> CONN A/A@YTK102
已连接。
SQL> CREATE DATABASE LINK TESTZJ CONNECT TO TEST IDENTIFIED BY TEST USING '172.25.88.92/TESTZJ';

数据库链接已创建。

SQL> SELECT * FROM GLOBAL_NAME@TESTZJ;

GLOBAL_NAME
-------------------------------------------
TESTZJ

在导入的时候指定NETWORK_LINK参数：

E:\>impdp a/a@ytk102 directory=d_output remap_schema=test:a network_link=testzj
include=job

Import: Release 10.2.0.1.0 - Production on 星期二, 29 1月, 2008 10:59:08

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
自动启用 FLASHBACK 以保持数据库完整性。
启动 "A"."SYS_IMPORT_SCHEMA_01": a/********@ytk102 directory=d_output remap_sch
ema=test:a network_link=testzj include=job
正在使用 BLOCKS 方法进行估计...
处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA
使用 BLOCKS 方法的总估计: 0 KB
处理对象类型 SCHEMA_EXPORT/JOB
作业 "A"."SYS_IMPORT_SCHEMA_01" 已于 10:59:12 成功完成

查询用户的JOB，发现JOB已经导入：

SQL> SELECT JOB, WHAT FROM USER_JOBS;

       JOB WHAT
---------- ------------------------------
        66 NULL;
     42862 NULL;

不过这种方法有的时候并不适用。很多时候使用数据泵的原因就是网络无法连通，或者处于安全性的考虑也无法使用数据库链。因此，这种方法虽然很方便，但是使用范围比较有限。

查询了metalink，metalink上有不少篇文章和这个问题类似，Oracle并没有给出什么好的解决方案，而是推荐使用SCHEDULE来替代JOB，或者使用IMP/EXP来替换数据泵。这显然是一种回避的方法。Oracle在Bug No. 5856954中进行了描述。Oracle并没有给出具体FIX这个bug的版本。在10204计划修订bug列表中也没有找到fix这个问题的计划。