由于要实施网上查询，一个同事h在本机导数据，本想到他机器上看看是否导完数据，但看到的桌面让我大吃一惊：

　　加truncate参数，使用oracle的impdp在生产环境导数据！

　　立马打开查询窗口，查询相关的表，结果返回：no rows selected.数据已经全部清掉了。

　　一瞬间一下子就懵了：怎么能把生产机的数据truncate掉？马上打电话给h，第一句话：怎么在生产机上导数据？为什么动生产机的数据？

　　h给出的答复是由于刚才导网上查询数据时误操作把一张表的数据删掉了，没有把问题反馈上来，直接就想通过18：30左右的备份恢复该表，由于缺乏impdp的相关知识，以为导出文件有的表，在impdp的时候都必须制定，结果把其他十来各表都全部truncate。

　　出现问题没有反馈，掩盖问题试图自己解决，由于缺乏相关的知识，结果误操作导致更严重的后果。

　　由于有下班后的expdp备份，本来是一张表的数据，而且该表数据在下班后不会变化，简单的通过impdp就可以恢复，结果用truncate选项把其他表统统清除掉，当时心里那个苦啊！

　　事已至此，没有办法，马上组织其他人手先通过备份恢复数据。

　　1.把大表和小表分开，大表先drop索引再导入，小表直接导入。

　　2.大表导入完毕后同步建立索引。

　　其他表都比较顺利，最后有两张表（大表a和中表b），死活导不进去。当时已经是凌晨0点10分左右。出现的现象是：

　　大表a导入了1.5个小时，没有任何反应，中表b导入时通过后台查询发现有其他进程lock该表，进程是oracle.exe(dw01)。

　　再等了十分钟，还是如此，觉得不能这样坐以待毙，重启数据库，重写执行导入数据，还是如此。

　　大表a的导入没有任何异常情况，就是hang着不动，这时候想到该表是复合分区表，如果改成普通表是否可以？通过rename原来的表，通过ctas创建普通表，重新导入，it works！数据导入后，通过insert into as select导入到正式表，然后通过rename等操作把正式表恢复到正常的表名。

　　大表a导完后，发现中表b还是在等待oracle.exec(dw01)，本想着通过alter system kill session把相关的session kill掉，半个小时过去，没有kill掉，只是mark kill。这时候查询session时发现相关schema是xdb，把xdb用户account lock，再导入，还是如此。这时候已经凌晨一点，就

[1] [2]