一次不完全恢復中途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/，如需轉載，請註明出處，否則將追究法律責任。