好久好久没有写过Oracle相关的文章了好像。作为一个DBA着实有些惭愧，人eygle都出书了。 😀 上个周六晚上借着首届杰出数据库工程师评选活动之机，吃了eygle一顿，然后去了eygle新家，说是小坐一会儿，却被大雨挡在了屋子里面，结果后来开始看Mr. Bean，一帮人前仰后合，饶有兴味。准备回家的时候，当晚最大的暴雨出现了，幸好桔子开着一辆…开着一辆…开着一辆啥来着？反正4个轮子的车，先送大师和汪海回酒店，有幸见到了第一次那么清晰的一个区域瓢泼大雨，过了一座立交桥，地面就干的没事儿人一样，诡异。 好吧，我承认又多扯了一堆家常，言归正传。 周日上午酣睡中被电话吵醒，说，客户查不到数据了，一个客户化功能的重新移植将原来已经有很多数据的表drop掉然后重新创建了。 这个drop的操作发生在上周五，也就是接到电话的一天多前，一天多的新业务一定是不能丢掉的，所以不允许直接把数据库恢复到上周五。接到电话以后大略想了一下操作的步骤，后来去公司又做了一些调整，最后的恢复过程大体如下。 1。停产品数据库 （因为允许当库，所以down下来比较保险），将原有数据文件所在的文件系统umount，新做一个文件系统，挂载到原来数据文件所在的目录下。现在就有了一个没有数据文件的Oracle环境。 2。先恢复控制文件，DP的GUI界面连接不上（VNC那边有防火墙），以下均是在RMAN中执行的。 set dbid 1296121177; –dbid在下面的控制文件备份名称中就可以看到 run { allocate channel ‘dev_0’ type ‘sbt_tape’ parms ‘ENV=(some ob2 parameters)’; restore controlfile from ‘c-1296121177-20060806-00’; –因为最新的备份是在删除了表以后，所以要指定控制文件名以恢复倒数第二次的有效备份，否则直接from autobackup就可以 } 3。再恢复数据文件 alter database mount; run { allocate channel ‘dev_0’ type ‘sbt_tape’ parms ‘ENV=(some ob2 parameters)’; restore database; } 4。recover数据库到DROP表之前的时间点（因为客户化移植的具体时间系统中有记录，所以这个时间点很好确定） run{ sql “alter session…