给人搽屁股......数据恢复一例

ALLSTARS_ORACLE

本文可任意转载，但请注明作者和出处。
http://space.itpub.net/6906/viewspace-250333

主题词：误删数据  恢复数据 问题反馈  凌晨

08年4月23日，一个值得“纪念”的日子。
晚上10点刚过抄起家当，准备回宿舍。由于要实施网上查询，一个同事H在本机导数据，本想到他机器上看看是否导完数据，但看到的桌面让我大吃一惊：
加Truncate参数，使用Oracle的Impdp在生产环境导数据！
立马打开查询窗口，查询相关的表，结果返回：no rows selected.数据已经全部清掉了。
一瞬间一下子就懵了：我Kao，搞什么鬼？怎么能把生产机的数据truncate掉？是不是脑子进水了？马上打电话给H，电话占线，Shit，再打，还是占线...... 急，先上洗手间，掏出手机，继续打，终于通了，第一句话：怎么在生产机上导数据？为什么动生产机的数据？
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，再导入，还是如此。这时候已经凌晨一点，就剩下这张表，头都有点大了，再仔细分析session的信息，发现module是Data pump，不是Oracle的必须后台进程，同时想起几年前在windows平台可以用orakill杀掉windows线程，抱着试试的心态，用 orakill杀掉了ORACLE.EXE(DW01)的线程，然后用impdp尝试导入，God，It works！谢天谢地，总算，数据都恢复了，这时候是凌晨1：30.
索引都创建完毕后，再次一张一张表检查一次，确保数据和索引都存在。
最后执行dbms_stats.gather_table_stats过程对相关的表执行一遍信息，并设定定时任务对数据库进行备份。
大功告成，凌晨2：30，可以躺一下了......

环境:
Oracle10.2.0.3
Windows2003 64bit
Inter Xeon CPU 8X

相关的SQL脚本：
1.查询等待或给锁定的object脚本
SELECT /*+ rule */ lpad(‘ ‘,decode(l.xidusn ,0,3,0))||l.oracle_username User_name,
o.owner,o.object_name,o.object_type,s.sid,s.serial#
FROM v$locked_object l,dba_objects o,v$session s
WHERE l.object_id=o.object_id
AND l.session_id=s.sid
ORDER BY o.object_id,xidusn DESC
2.查询v$session，可获取MODULE等信息。
3.orakill的用法可通过orakill -help获取
c:>orakill -help
Usage:  orakill sid thread

  where sid    = the Oracle instance to target
        thread = the thread id of the thread to kill

  The thread id should be retrieved from the spid column of a query such as:

        select spid, osuser, s.program from
        v$process p, v$session s where p.addr=s.paddr

在本例中用法为:
orakill prod 2203




在用impdp导入B表时发现另一session S1锁住了该表：
1.通过sid，不断查询v$session时发现schema出现过XDB，当时认为可能是XDB用户的某些后台进程lock表，结果发现不是。
2.锁定表B的S1的module是data pump，断定不会影响到oracle的后台进程，才会试着用orakill把该thread杀掉。