天天看点

Database Force open example

帮网友强制打开了一个没有备份的测试库,这个库没有备份也没有打开归档,因为之前也出现过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&gt; </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&gt; col current_scn format 999,999,999,999</code>

<code>SQL&gt; </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&gt; shutdown immediate;</code>

<code>Database</code> <code>closed.</code>

<code>Database</code> <code>dismounted.</code>

<code>ORACLE instance shut down.</code>

<code>SQL&gt; 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&gt; </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&gt; </code><code>alter</code> <code>database</code> <code>open</code><code>;</code>

<code>Database</code> <code>altered.</code>

<code>SQL&gt;  </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&gt;  </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&gt;</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&gt; </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