Oracle資料庫REDO損壞ora-00333修複手劄

標籤：ora-00333

1.   事情起因

接到電話，周日意外斷電，資料庫起不了，報REDO CRASH,ora-00333錯誤。

相關環境如下：RAC oracle_11.2.0.3，無備份，開歸檔。

2 處理

一到現場，既然對方沒有備份，那就做一個冷備份咯；oracle 11g嘛，把asm裡datafile,logfile,controlfile(如果有必要spfile.ora)copy出來就可以了。拼的sql 如下：

select ‘cp ‘||name ||‘ /databak/datafile/‘ fromv$datafile union

select ‘cp ‘||member||‘ /databak/logfile/‘ from v$logfile unionselect ‘cp ‘||name ||‘ /databak/controlfile/‘ fromv$controlfile;

轉到grid使用者下,asmcmd,執行就可以了。時間嘛，那就得看你的資料檔案大小和儲存的IO速度了。

2.1修改隱含參數

由於有了冷備，可以參數（如果沒冷備，改這個參數，那再後面就沒那個磚家來陪你玩了）

SQL>create pfile=’/databak/pfile.ora’ from spfile;

修改pfile.ora，增加如下部分

_allow_resetlogs_corruption=TRUE

*.undo_management=‘MANUAL‘

*.rollback_segments=‘SYSTEM‘

可能有人要問，你resetlogs，關undo啥事，但通常事情是這樣，redo出問題了，那就意味著有事務沒提交完，那undo必然不一致，所以乾脆把undo也改了吧。

2.2 啟庫

改完了，重啟咯

SQL>shutdown immediate;

SQL>startup mount pfile=’/databak/pfile.ora’

SQL>RECOVERDATABASE until cancel;

這時資料庫會提示你輸入下一個logseq，這裡沒有，直接輸cancel;這裡你會很高興的看到那個壞的redo被清掉了，可以歡呼了，起來了，但是世界是非富多彩地，馬上就把你的高興打破：

ORA-01555caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0db2.73a0c8cd):select ctime,mtime, stime from obj$ where obj# = :1Errors in file/oracle/app/oracle/diag/rdbms/oradb/oradb1/trace/jmrk1_ora_4608.trc:Errors in file/oracle/app/oracle/diag/rdbms/oradb/oradb1/trace/jmrk1_ora_4364.trc:ORA-00704:bootstrap process failureORA-00704:bootstrap process failureORA-00604:error occurred at recursive SQL level 1ORA-01555:snapshot too old: rollback segment number 20 with name"_SYSSMU20_3214617278$" too small

這裡一看，似乎和undo有關係，但看官莫急，仔細看一下

select ctime,mtime, stime from obj$ where obj# = :1這個語句好眼熟，不是初始化最早的語句麼，那估計SCN有問題了。

SQL>Selectcurrent_scn from v$database;-------------------------------------------------------------------0

為0.HOHO.

這裡用兩種方法來解決囉：

1設定10046trace

SQL> oradebug setmypid

Statement processed.

SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12

Statement processed.

SQL> oradebug TRACEFILE_NAME

2 oradebugpoke推進scn

3設定隱含參數_minimum_giga_scn

我這裡採用第三種：

selectksppinm,ksppdesc from x$ksppi   whereksppinm like ‘%giga%‘KSPPINM                        KSPPDESC---------------------------------------------------------------------------_minimum_giga_scn              Minimum SCN to start with in 2^30unitsselectto_char(checkpoint_change#,‘99999999999999‘) from v$database;TO_CHAR(CHECKPO--------------- 15060095276784selectdistinct(to_char(checkpoint_change#,‘99999999999999‘))  from v$datafile_header;(TO_CHAR(CHECKP--------------- 15060095276784SQL> select15060095276784/1024/1024/1024 from dual; 15060095276784/1024/1024/1024-----------------------------                   14025.8067

修改pfile改修改：

_minimum_giga_scn=14026

現次啟動資料庫，順利open，但有一堆JOB報錯，估計掉電時正在跑JOB.也就解釋了為啥周日掉電也會把資料庫redo 搞垮。

SQL> alter system setjob_queue_processes=0;

匯出全部做一個邏輯匯出咯。

expdp system/systemdirectory=full dumpfile=dump_%u.dmp logfile=export.log full=y parallel=4

匯出時也報了一個錯，說復原段不可用，忘了把undo改成真正的undo了，

SQL> create undotablespace  undotbs3 datafile‘+ordata(datafile)‘ size 8G;

修改pfile，改成成undotbs3;再次重啟，OK。

2.3 MOS _ALLOW_RESETLOGS_CORRUPTION說明

DB_Parameter _ALLOW_RESETLOGS_CORRUPTION

========================================

 

This documentation has been preparedavoiding the mention of the complex

structures from the code and to simply givean insight to the ‘damage it could

cause‘. The usage of this parameter leads to an in-consistent Database with no

other alternative but to rebuild thecomplete Database.  This parameter could

be used when we realize that there are nostardard options available and are

convinced that the customer understands theimplications of using the Oracle‘s

secret parameter.  The factors to be considered are ;--

 

1. Customer does not have a good backup.

2. A lot of time and money has beeninvested after the last good backup and    

  there is no possibility for reproduction of the lost data.

3. The customer has to be ready to exportthe full database and import it    

  back after creating a new one.

4. There is no 100% guarantee that by usingthis parameter the database would

  come up.

5. Oracle does not support the databaseafter using this parameter for      

  recovery.   

6. ALL OPTIONS including the ones mentionedin the action part of the error  

  message have been tried.

簡單點來說，就是_ALLOW_RESETLOGS_CORRUPTION這個參數沒有100%保證，你redo壞了能用他來OPEN庫的，並且了用了這個後不支援恢複了(rman)，僅僅支援export.

3總結：

  沒啥好說的，有運氣成份在裡面，如果datafile block有環塊那就更麻煩了，如果壞了一片也就沒得完了,沒事還是不要玩掉電吧，把UPS電池時間弄長一點，加個停電警示，省了一片心，再就是有空建個dataguard吧。

本文出自 “snowhill” 部落格，請務必保留此出處http://snowhill.blog.51cto.com/339421/1836704

Oracle資料庫REDO損壞ora-00333修複手劄