ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次不完全恢复中途Kill rman后的问题处理+坏块处理过程

一次不完全恢复中途Kill rman后的问题处理+坏块处理过程

原创 Linux操作系统 作者:YallonKing 时间:2011-08-12 12:16:01 0 删除 编辑

最近有点忙,没有时间整理东西,今天周末,就整理下了...

问题描述:

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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-08-07

  • 博文量
    72
  • 访问量
    260367