一个最小化不完全恢复案例的处理及思索

 这里讨论的并不单单是恢复上的技巧问题，还有如何对你的DB管理规划的问题。

案例情形：
某个生产环境的业务表(不大，100M左右）被误删除了一个字段，现在要尽快找回这些被删除的业务数据（数据库容量为700多G,有一个实时恢复的物理备库，主要的表空间为该所在表空间BIS和另外一个表空间,各自300多G,单个数据文件统一8G一个).

    情况很乐观：有误操作之前RMAN全备份和到现在连续的归档日志，也就是说用RMAN的不完全恢复可以找到为删除之前的数据。
    这是一个看似很基础和简单的案例，但作为DB的管理维护人员，尤其是作为服务型的人员角色来说，如何缩短故障的解决时间，将直接决定你的服务质量和客户的满意度。
   不妨让我们思考一下，面对这个案例，有什么样的技巧可以缩短恢复的进度时间呢？

    也许很多人都认同这个这么一个方法：采用基于表空间的不完全恢复。恢复system表空间、undo表空间和故障表所在的表空间，将其余表空间全部 offline。在我们这个案例中，单故障表所在的表空间有将近300G的数据，去恢复这个大的容量，花费的时间无疑还是不容乐观的。
    有没有更快的办法呢？
    对于这种情形，实际上我们只需要去恢复几个文件即可。因为表是被drop列的，误操作前后该object的物理位置并没有多大改变，我们可以获得该表所在 的datafile。由于表所在的表空间datafile为8G一个，所以，需要恢复的文件只是system文件,undo文件和1(2)个8G的 datafile文件。单从数字上你就会明白两种恢复方法速度上的差别—一个涉及的文件30多G,而另外一个足有300G多。
   查询误操作表所在的文件和需要恢复的系统文件：

SQL> select file_id,FILE_NAME,TABLESPACE_NAME from dba_data_files where tablespace_name in (’SYSTEM’,'UNDOTBS1′) union all
select distinct a.FILE_ID,b.file_name,b.tablespace_name from dba_extents a,dba_data_files b where a.segment_name=’TB_NEW_CONFIG’ and a.file_id=b.file_id;

FILE_ID FILE_NAME TABLESPACE_NAME
———- —————————— ——————————
1 /data/NL/system01.dbf SYSTEM
2 /data/NL/undotbs01.dbf UNDOTBS1
3 /data/NL/undotbs02.dbf UNDOTBS1
14 /data/NL/bis04.dbf BIS

因此接下来只需要恢复1.2.3.14这个四个文件即可。
(1).使用rman进行文件restore

[oracle@bisdb ~]$ rman target /
[uniread] Loaded history (180 lines)
Recovery Manager: Release 10.2.0.4.0 - Production on Mon Jul 13 19:14:37 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: BISDB (DBID=1978090465, not open)
RMAN> restore datafile 1,2,3,14;
Starting restore at 13-JUL-09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /data/NL/system01.dbf
channel ORA_DISK_1: reading from backup piece /backup/full_172_1
…………………

(2).将datafile 1，2，3，14之外的全部文件offline drop

SQL>alter database datafile 4 offline drop;
…..(略)…….
SQL>alter database datafile 101 offline drop;

(3).进行不完全恢复
   特别需要注意这一步：该步需要使用sqlplus进行。如果你使用rman做recover，你会发现行不通。因为rman依然会对表空间内 offline过的文件做recover，因为我们只restore了表空间其中的一个文件，所以使用rman恢复该表空间的时候被报错,具体可自行验 证。

SQL> recover database until change 129856635;
ORA-00279: change 129853929 generated at 07/13/2009 17:54:52 needed for thread 1
ORA-00289: suggestion : /arch/NL/1_1165_689680541.dbf
ORA-00280: change 129853929 for thread 1 is in sequence #1165
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 129856633 generated at 07/13/2009 19:02:06 needed for thread 1
ORA-00289: suggestion : /arch/NL/1_1166_689680541.dbf
ORA-00280: change 129856633 for thread 1 is in sequence #1166
ORA-00278: log file ‘/arch/NL/1_1165_689680541.dbf’ no longer needed for this
recovery
————-
SQL> recover database until change 129856635;
ORA-00279: change 129856635 generated at 07/13/2009 19:02:07 needed for thread 1
ORA-00289: suggestion : /arch/NL/1_1177_689680541.dbf
ORA-00280: change 129856635 for thread 1 is in sequence #1177
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

(4).alter database open resetlogs

   之后，进行数据的业务逻辑处理补入。

后记：
这个案例可以引起我们的一些思索：
1. 数据文件大小规划
比较幸运的是，这个案例中单个数据文件比较小，这对我们缩短恢复时间提供了关键因素。在实际环境中，过大的数据文件并不可取。
2.Datadurd规划
这是个有dataguard环境的主库，可以设置备库延迟主库一段时间的日志文件应用。这样可以在及时捕获误操作的情况下降低故障处理时间。在delay的时间策略上，需要我们根据业务系统要求灵活处理。