Chinaunix首页 | 论坛 | 博客
  • 博客访问: 181713
  • 博文数量: 77
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 45
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-25 10:50
文章分类

全部博文(77)

文章存档

2018年(1)

2017年(3)

2016年(4)

2015年(4)

2014年(16)

2013年(7)

2012年(20)

2011年(22)

分类: Oracle

2012-05-24 19:02:28

使用工具 IMPDP 导入数据时 ORA-39002、ORA-39070 错误排查 今天在使用 IMPDP 完成数据导入的过程中遇到“ORA-39002、ORA-39070……”连续报错。 导致问题原因很简单,但是提示的错误信息内容比较“诡异” ,为了朋友们少走弯路,简单 记录一下这个问题的处理过程。
1.问题再现 sec@secDB /db_backup/dpump_dir$ impdp dumpfile=20100604020437_sec.dmp logfile=impdp.log sec/sec directory=dpump_dir Import: Release 10.2.0.3.0 - 64bit Production on Friday, 04 June, 2010 14:39:16 Copyright (c) 2003, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production With the Partitioning, OLAP and Data Mining options ORA-39002: invalid operation ORA-39070: Unable to open the log file. ORA-29283: invalid file operation ORA-06512: at "SYS.UTL_FILE", line 475 ORA-29283: invalid file operation
2.问题分析 这里的“ORA-39070”提到的“Unable to open the log file.”初看非常的“诡异” ,到底无法 打开什么日志文件呢?难道是没有权限在这个目录下写文件?经过“touch”测试排除了这 种可能性。 不管怎么说,这个问题与文件操作相关。顺着这个思路继续前行,终于发现原来数据库中的 directory 数据库对象所指向的目录为“/oradata/dpump_dir” ,而在该操作系统中根本没有这 个目录,因目录不存在,日志文件也就理所当然的无处可写。 不过这个报错的信息却是不够明显,如果能够给出更多的检查和明确的报错信息就更好了。
> col owner for a6
sys@ora10g> col DIRECTORY_NAME for a20
sys@ora10g> col DIRECTORY_PATH for a30 sys@ora10g> select * from dba_directories where DIRECTORY_NAME = 'DPUMP_DIR'; OWNER DIRECTORY_NAME DIRECTORY_PATH ------ -------------------- -----------------------------SYS DPUMP_DIR /oradata/dpump_dir
3.问题处理 发现问题后,处理方法就简单了许多,只需要重新创建 directory 数据库对象即可。 sys@sec> drop directory dpump_dir; Directory dropped. sys@sec> create directory dpump_dir as '/db_backup/dpump_dir'; Directory created. sys@sec> grant read, write on directory dpump_dir to public; Grant succeeded.
4.导致该问题的潜在原因 在 10g 环境中即使在创建 directory 数据库对象的过程中即使所引用的目录不存在,该命令 也是可以正常创建的,这就是容易误操作的根本原因。 sys@ora10g> create directory dpump_dir_test as '/sec/ool/er'; Directory created. 小心陷阱。
 5.小结 从该问题的处理过程中我们可以看到, 在报错信息不实很明显的时候我们往往手足无措。 越 是在这样的场景,我们越应该沉着冷静,从整个操作的源头一步一步的去排查,终有柳暗花 明之时。
阅读(1833) | 评论(0) | 转发(0) |
0

上一篇:tcp 三次握手协议

下一篇:JDR 与JRE 的区别

给主人留下些什么吧!~~