一次不完全恢复中途Kill rman后的问题处理+坏块处理过程
最近有点忙，没有时间整理东西，今天周末，就整理下了...
问题描述：
Oracle Linux 6.0+oracle11gr2
昨天回家，一同事电话说自己误truncate了一张大表（约：20：40左右）
由于公司在西单，我住的地太远，暂时也不能远程操作
随即电话通知其进行不完全恢复，语句如下：（注：闪回没开）
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
shutdown immediate;
startup mount;
sql "alter session set nls_date_format=''yyyy-mm-dd hh24:mi:ss''";
set until time '2011-08-02 20:30:00';
restore database;
recover database;
alter database open resetlogs;}
库大概有4.2T左右
备份为前天晚上的0级增量备份
3号早上9：10查看，数据文件restore的差3个文件（文件都较大），由于业务需求，不得不将rman先kill，准备重新open库进行业务，就缺少时间，非常可惜。当shutdown immediate后再open时报数据库数据文件1需要介质恢复，数据库处于nomount阶段；此刻已经9：20左右了，高频库是用不了了，于是及时将数据切换至低频库进行落数据，估计损失了5分钟左右的数据量。（注：由于是金融数据库，每天9：15开始有大量数据入库，约600k/6s。）
完了，只能接着上次进行恢复了，这次调整相关参数后进行不完全的恢复，语句如下：
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
allocate channel c5 type disk;
allocate channel c6 type disk;
shutdown immediate;
startup mount;
sql "alter session set nls_date_format=''yyyy-mm-dd hh24:mi:ss''";
set until time '2011-08-02 20:30:00';
restore database;
recover database;
alter database open resetlogs;}
20分钟左右（注：归档文件也是很大的）完成，日志无错误信息。
当再次resetlogs打开后，以前truncate的表是回来了，不过又有出现下列错误：
SQL> select count(*) from level1.STOCKQUOTELevel1sh;
select count(*) from level1.STOCKQUOTELevel1sh
*
第 1 行出现错误:
ORA-01578: ORACLE 数据块损坏 (文件号 65, 块号 3038195)
ORA-01110: 数据文件 65: '/opt/M1HFData/oradata/m1hf/level1_P15.dbf'
ORA-26040: 数据块是使用 NOLOGGING 选项加载的
SQL> select count(*) from level1.STOCKQUOTELevel1sz;
select count(*) from level1.STOCKQUOTELevel1sz
*
第 1 行出现错误:
ORA-01578: ORACLE 数据块损坏 (文件号 50, 块号 3109427)
ORA-01110: 数据文件 50: '/opt/M1HFData/oradata/m1hf/level1_P0.dbf'
ORA-26040: 数据块是使用 NOLOGGING 选项加载的
由错误提示可知是数据文件损坏，故继续进行解决：
1、 先确定损坏的是表段还是索引段，若是后者，则就简单了
SQL> select * from dba_extents where file_id=50 and 3109427 between block_id and block_id+blocks-1;
OWNER
------------------------------
SEGMENT_NAME
--------------------------------------------------------------------------------
PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME
------------------------------ ------------------ ------------------------------
EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
---------- ---------- ---------- ---------- ---------- ------------
LEVEL1
STOCKQUOTELEVEL1SZ
P20110803 TABLE PARTITION LEVEL1
0 50 3109424 65536 8 50
显然没那么简单了
2、 使用诊断事件
SQL> alter system set events '10231 trace name context forever,level 10';
注：此事件跳过全表扫描时的坏块
系统已更改。
3、 创建表并跟换表名
SQL> create table STOCKQUOTELEVEL1SZ_tmp as select * from level1.STOCKQUOTELEVEL1SZ;
表已创建。
SQL> alter table STOCKQUOTELEVEL1SZ rename to STOCKQUOTELEVEL1SZ_bak;
表已更改。
SQL> alter table level1.STOCKQUOTELEVEL1SZ_tmp rename to STOCKQUOTELEVEL1SZ;
表已更改。
关闭事件：SQL> alter system set events '10231 trace name context off';
4、查看相关表数据
SQL> select count(*) from level1.STOCKQUOTELEVEL1SZ;
COUNT(*)
----------
749420
4、 做数据库日检无其他问题
切换开始使用高频库。此时已经10：10左右
至此，此次事件已经解决，后边再备份了。
总结：此次估计丢失高频库与低频库切换时间隔5mins的数据，数据量约：5mins*60/6*600k=29.29M
哎，很悲剧的一次不完全恢复.....记录于此，时刻警醒自己。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26143577/viewspace-704723/，如需转载，请注明出处，否则将追究法律责任。
