ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 数据泵无法导入JOB

数据泵无法导入JOB

原创 Linux操作系统 作者:yangtingkun 时间:2008-01-29 11:21:51 0 删除 编辑

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

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

连接到: 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

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

连接到: 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

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

连接到: 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

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

连接到: 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

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

连接到: 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;

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

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

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-163544/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10487240