幫網友強制打開了一個沒有備份的測試庫,這個庫沒有備份也沒有打開歸檔,因為之前也出現過active日志檔案損毀,一直使用隐式參數才能正常打開:
<a href="http://blog.51cto.com/maclean/1277138#">?</a>
<code>_allow_resetlogs_corruption= </code><code>TRUE</code>
這次一開始這個庫報ORA-600[2662]錯誤:
<code>Mon Aug 23 09:37:00 2010</code>
<code>Errors </code><code>in</code> <code>file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:</code>
<code>ORA-00600: internal error code, arguments: [2662], [0], [130131504], [0], [130254136], [4264285], [], []</code>
<code>Mon Aug 23 09:37:02 2010</code>
<code>ORA-00600: internal error code, arguments: [2662], [0], [130131506], [0], [130254136], [4264285], [], []</code>
ORA-600 [2662] "Block SCN is ahead of Current SCN"錯誤是當資料塊中的SCN領先于current SCN,由于背景程序或服務程序都會比對UGA中的dependent SCN和資料庫目前的SCN,如果資料庫目前SCN小于dependent SCN,那麼該程序就會報ORA-600 [2662]錯誤,如果遭遇該錯誤的是服務程序,那麼服務程序一般會異常終止;如果遭遇該錯誤的是背景程序譬如SMON,則會導緻執行個體CRASH。 ORA-600 [2662]錯誤可以能由以下幾種情況引起: 1.啟用隐含參數_ALLOW_RESETLOGS_CORRUPTION後,以resetlogs形式打開資料庫;這種情況下發生2662錯誤,根本原因是沒有完全前滾導緻控制檔案中的SCN滞後于資料塊中的SCN。 2.硬體故障導緻資料庫沒法寫控制檔案和聯機日志檔案 3.錯誤的部分恢複資料庫 4.恢複了控制檔案,但是沒有使用recover database using backup controlfile進行恢複 5.資料庫crash後設定了_DISABLE_LOGGING隐含參數 6.在并行伺服器環境中DLM存在問題 該錯誤的5個參數的具體含義如下: ARGUMENTS: Arg [a] Current SCN WRAP Arg [b] Current SCN BASE Arg [c] dependent SCN WRAP Arg [d] dependent SCN BASE Arg [e] Where present this is the DBA where the dependent SCN came from. 我們的case當中dependent SCN為130254136,而目前SCN為130131506,其內插補點為122630;從以上告警日志中可以看到資料庫的目前SCN是在不斷緩慢增長的,當我們遭遇到2662錯誤時,很滑稽的一點是隻要不斷重新開機資料庫保持current SCN的增長,一段時間後2662錯誤會不藥而愈。當然我們也可以不用這種笨辦法,10015事件可以幫助我們調整資料庫目前SCN:
<code>/* 當資料庫處于mount狀态,可以使用10015事件來調整scn */</code>
<code>alter</code> <code>session </code><code>set</code> <code>events </code><code>'10015 trace name adjust_scn level 1'</code><code>;</code>
<code>/* 這裡可以設定</code><code>level</code> <code>2..10等 (</code><code>level</code> <code>1是在每次打開資料庫時scn增加1000k)*/</code>
<code>/* 需要注意的是10g某些版本不同于9i,需要設定隐式參數_allow_error_simulation,才能真正增進scn */</code>
<code>SQL> </code><code>select</code> <code>* </code><code>from</code> <code>v$version;</code>
<code>BANNER</code>
<code>----------------------------------------------------------------</code>
<code>Oracle </code><code>Database</code> <code>10g Enterprise Edition Release 10.2.0.4.0 - 64bi</code>
<code>PL/SQL Release 10.2.0.4.0 - Production</code>
<code>CORE 10.2.0.4.0 Production</code>
<code>TNS </code><code>for</code> <code>Linux: Version 10.2.0.4.0 - Production</code>
<code>NLSRTL Version 10.2.0.4.0 - Production</code>
<code>SQL> col current_scn format 999,999,999,999</code>
<code>SQL> </code><code>select</code> <code>current_scn </code><code>from</code> <code>v$</code><code>database</code><code>;</code>
<code>CURRENT_SCN</code>
<code>-----------</code>
<code> </code><code>1141408</code>
<code>SQL> shutdown immediate;</code>
<code>Database</code> <code>closed.</code>
<code>Database</code> <code>dismounted.</code>
<code>ORACLE instance shut down.</code>
<code>SQL> startup mount;</code>
<code>ORACLE instance started.</code>
<code>Total System </code><code>Global</code> <code>Area 1653518336 bytes</code>
<code>Fixed </code><code>Size</code> <code>2213896 bytes</code>
<code>Variable </code><code>Size</code> <code>989857784 bytes</code>
<code>Database</code> <code>Buffers 654311424 bytes</code>
<code>Redo Buffers 7135232 bytes</code>
<code>Database</code> <code>mounted.</code>
<code>SQL> </code><code>alter</code> <code>session </code><code>set</code> <code>events </code><code>'10015 trace name adjust_scn level 1'</code><code>;</code>
<code>Session altered.</code>
<code>SQL> </code><code>alter</code> <code>database</code> <code>open</code><code>;</code>
<code>Database</code> <code>altered.</code>
<code>SQL> </code><code>select</code> <code>current_scn </code><code>from</code> <code>v$</code><code>database</code><code>;</code>
<code> </code><code>1142031</code>
<code>/* 可以看到current_scn并未大量增加,10.2.0.4上預設10015 adjust_scn不被觸發 */</code>
<code>SQL> </code><code>alter</code> <code>system </code><code>set</code> <code>"_allow_error_simulation"</code><code>=</code><code>true</code> <code>scope=spfile;</code>
<code>System altered.</code>
<code>SQL></code><code>select</code> <code>current_scn </code><code>from</code> <code>v$</code><code>database</code><code>;</code>
<code> </code><code>CURRENT_SCN</code>
<code>----------------</code>
<code> </code><code>1,073,741,980</code>
在接手之前該網友已經通過反複重新開機資料庫将資料庫的目前SCN提高到dependent SCN的127037138;原以為這樣就可以打開資料庫了,誰知道又出現了一下錯誤:
<code>Wed Aug 25 07:43:53 2010</code>
<code>Errors </code><code>in</code> <code>file /oracle/QAS/saptrace/usertrace/qas_ora_929958.trc:</code>
<code>ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], []</code>
<code>ORA-00704: bootstrap process failure</code>
<code>Error 704 happened during db </code><code>open</code><code>, shutting down </code><code>database</code>
bootstrap自舉過程中遭遇了ORA-600 [4000]錯誤,該錯誤一般當Oracle嘗試讀取資料字典(主要是undo$基表)中記錄的USN對應的復原段失敗引起.,通過設定隐式參數_corrupted_rollback_segments可以一定程度上規避該錯誤,強制打開資料庫,其Argument[a]代表造成讀取失敗的USN(undo segment number),但實際上有問題的復原段可能不止這一個:
<code>/* 通過strings工具從system表空間上找回各復原段的名字 */</code>
<code>$strings system.dbf |grep _SYSSMU|less</code>
<code>_SYSSMU1$</code>
<code>_SYSSMU2$</code>
<code>_SYSSMU3$</code>
<code>_SYSSMU4$</code>
<code>_SYSSMU5$</code>
<code>_SYSSMU6$</code>
<code>_SYSSMU7$</code>
<code>_SYSSMU8$</code>
<code>_SYSSMU9$</code>
<code>.........</code>
<code>alter</code> <code>system </code><code>set</code> <code>"_corrupted_rollback_segments"</code><code>=</code><code>'(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$, _SYSSMU11$, _SYSSMU12$)'</code> <code>scope=spfile;</code>
<code>/* 即便設定了_corrupted_rollback_segments隐式參數,也還有一定機率遭遇4000錯誤,嘗試加上10513事件,并多次重新開機資料庫 */</code>
<code>SQL> </code><code>alter</code> <code>system </code><code>set</code> <code>event=</code><code>'10513 trace name context forever,level 2'</code> <code>scope=spfile;</code>
<code>/* 再次出現4000 錯誤 */</code>
<code>Errors </code><code>in</code> <code>file /oracle/QAS/saptrace/usertrace/qas_ora_1016014.trc:</code>
<code>Thu Aug 26 09:43:39 2010</code>
<code>/* 再次重新開機後發現4000錯誤不再出現 * /</code>
再次重新開機發現不再出現ORA-600[4000]錯誤,但在字典檢查階段Oracle認為資料檔案227不比對于目前的incarnation:
<code>Thu Aug 26 11:13:22 2010</code>
<code>Dictionary </code><code>check</code> <code>beginning</code>
<code>Thu Aug 26 09:46:00 2010</code>
<code>Errors </code><code>in</code> <code>file /oracle/QAS/saptrace/usertrace/qas_ora_897162.trc:</code>
<code>ORA-01177: data file does </code><code>not</code> <code>match dictionary - probably old incarnation</code>
<code>ORA-01110: data file 227: </code><code>'/oracle/QAS/sapdata2/qas_192/qas.data196'</code>
<code>Error 1177 happened during db </code><code>open</code><code>, shutting down </code><code>database</code>
<code>USER</code><code>: terminating instance due </code><code>to</code> <code>error 1177</code>
<code>Instance terminated </code><code>by</code> <code>USER</code><code>, pid = 897162</code>
初步判斷出現ORA-01177可能為2種可能性: 1.資料字典出現訛誤,227号檔案對應的incarnation資訊不正确 2.在之前的某次resetlogs open過程中,227号檔案頭由于某些原因沒有正确更新incarnation資訊 針對這樣的情況如果一定要找回該資料檔案上的資料的話隻能通過手動修改資料字典或檔案頭,當然也可以嘗試使用一些直接從資料檔案上抽取資料的工具。 因為這是一次友情協助,就沒有繼續深入下去,通過重建控制檔案并跳過該資料檔案解決了:
<code>CREATE</code> <code>CONTROLFILE REUSE </code><code>DATABASE</code> <code>"QAS"</code> <code>RESETLOGS NOARCHIVELOG</code>
<code>-- SET STANDBY TO MAXIMIZE PERFORMANCE</code>
<code> </code><code>MAXLOGFILES 255</code>
<code> </code><code>MAXLOGMEMBERS 3</code>
<code> </code><code>MAXDATAFILES 254</code>
<code> </code><code>MAXINSTANCES 50</code>
<code> </code><code>MAXLOGHISTORY 36302</code>
<code>LOGFILE</code>
<code> </code><code>GROUP</code> <code>1 (</code>
<code> </code><code>'/oracle/QAS/redolog/redolog11A.dbf'</code><code>,</code>
<code> </code><code>'/oracle/QAS/redolog/redolog11B.dbf'</code>
<code> </code><code>) </code><code>SIZE</code> <code>500M,</code>
<code> </code><code>GROUP</code> <code>2 (</code>
<code> </code><code>'/oracle/QAS/redolog/redolog12A.dbf'</code><code>,</code>
<code> </code><code>'/oracle/QAS/redolog/redolog12B.dbf'</code>
<code> </code><code>) </code><code>SIZE</code> <code>500M</code>
<code>-- STANDBY LOGFILE</code>
<code>DATAFILE</code>
<code> </code><code>'/oracle/QAS/sapdata1/system_1/system.data1'</code><code>,</code>
<code>........</code>
<code> </code><code>'/oracle/QAS/sapdata2/qas_192/qas.data195'</code>
<code>CHARACTER</code> <code>SET</code> <code>WE8DEC</code>
<code>Thu Aug 26 14:04:50 2010</code>
<code>Successful mount </code><code>of</code> <code>redo thread 1, </code><code>with</code> <code>mount id 2117500093</code>
<code>Completed: </code><code>CREATE</code> <code>CONTROLFILE REUSE </code><code>DATABASE</code> <code>"QAS"</code> <code>RESETLOGS</code>
<code>Thu Aug 26 14:05:05 2010</code>
<code>alter</code> <code>database</code> <code>mount</code>
<code>ORA-1100 signalled during: </code><code>alter</code> <code>database</code> <code>mount...</code>
<code>Thu Aug 26 14:05:15 2010</code>
<code>alter</code> <code>database</code> <code>open</code> <code>resetlogs</code>
<code>RESETLOGS </code><code>is</code> <code>being done without consistancy checks. This may result</code>
<code>in</code> <code>a corrupted </code><code>database</code><code>. The </code><code>database</code> <code>should be recreated.</code>
<code>RESETLOGS </code><code>after</code> <code>incomplete recovery UNTIL CHANGE 1125281471596</code>
<code>Resetting resetlogs activation ID 0 (0x0)</code>
<code>Online log 1 </code><code>of</code> <code>thread 1 was previously cleared</code>
<code>Thu Aug 26 14:05:36 2010</code>
<code>Assigning activation ID 2117500093 (0x7e367cbd)</code>
<code>Thread 1 opened </code><code>at</code> <code>log </code><code>sequence</code> <code>1</code>
<code> </code><code>Current</code> <code>log# 2 seq# 1 mem# 0: /oracle/QAS/redolog/redolog12A.dbf</code>
<code> </code><code>Current</code> <code>log# 2 seq# 1 mem# 1: /oracle/QAS/redolog/redolog12B.dbf</code>
<code>Successful </code><code>open</code> <code>of</code> <code>redo thread 1</code>
<code>SMON: enabling cache recovery</code>
<code>Tablespace </code><code>'PSAPTEMP'</code> <code>#2 found </code><code>in</code> <code>data dictionary,</code>
<code>but </code><code>not</code> <code>in</code> <code>the controlfile. Adding </code><code>to</code> <code>controlfile.</code>
<code>File #227 found </code><code>in</code> <code>data dictionary but </code><code>not</code> <code>in</code> <code>controlfile.</code>
<code>Creating OFFLINE file </code><code>'MISSING00227'</code> <code>in</code> <code>the controlfile.</code>
<code>This file can </code><code>no</code> <code>longer be recovered so it must be dropped.</code>
<code>File #228 found </code><code>in</code> <code>data dictionary but </code><code>not</code> <code>in</code> <code>controlfile.</code>
<code>Creating OFFLINE file </code><code>'MISSING00228'</code> <code>in</code> <code>the controlfile.</code>
<code>File #229 found </code><code>in</code> <code>data dictionary but </code><code>not</code> <code>in</code> <code>controlfile.</code>
<code>Creating OFFLINE file </code><code>'MISSING00229'</code> <code>in</code> <code>the controlfile.</code>
<code>Dictionary </code><code>check</code> <code>complete</code>
<code>Thu Aug 26 14:05:38 2010</code>
<code>SMON: enabling tx recovery</code>
<code>Database</code> <code>Characterset </code><code>is</code> <code>WE8DEC</code>
<code>replication_dependency_tracking turned </code><code>off</code> <code>(</code><code>no</code> <code>async multimaster replication found)</code>
<code>Completed: </code><code>alter</code> <code>database</code> <code>open</code> <code>resetlogs</code>
本文轉自maclean_007 51CTO部落格,原文連結:http://blog.51cto.com/maclean/1277138