あるアーカイブもバックアップもないテストデータベースを強制的に起動した。前にアクティブログファイル損害もあったから、隠しバラメタしか起動できない。 _allow_resetlogs_corruption= TRUE

プロのOracle Databaseの復旧サービスを提供 携帯番号: +86 13764045638 メール:service@parnassusdata.com

  まずはORA-600[2662]エラの場合: Mon Aug 23 09:37:00 2010 Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc: ORA-00600: internal error code, arguments: [2662], [0], [130131504], [0], [130254136], [4264285], [], [] Mon Aug 23 09:37:02 2010 Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc: ORA-00600: internal error code, arguments: [2662], [0], [130131506], [0], [130254136], [4264285], [], [] ORA-600 [2662] “Block SCN is ahead of Current SCN”エラは今のデータブロックのSCNがcurrent SCNを上回っていると意味している。バックグラウンドプロセスあるいはサビースプロセスはUGAのdependent SCNとデータベースに既存するSCNと比べるから、ORA-600 [2662]エラになる。もしサビースプロセスでこのエラが起こったら、そのプロセスは中止される。バックグラウンドプロセスでこのエラが起こったら、インスタンスを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.Parallel Server環境でDLMにトラブルが起こった。 そのエラの五つのバラメタの意味は以下の通り: 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. これらのケースでdependent SCNは130254136だが、今のSCNが130131506で差値が122630である;以上のアラームログで、データベース今のSCNは持続的に増やしている。2662エラになった場合に、データベースを再起動することを繰り返して、current SCNが持続的に増やしていることを確保していれば、2662エラがなくなる。もちろん、こんなばかなやり方を取らなくとも、10015トランザクションでデータベースのSCNを調整できる: /* データベースがmount状態にいれば、10015トランザクションでscnを調整できる */   alter session  set events '10015 trace name adjust_scn level 1';   /*ここで level 2..10などを設定する (level 1はデータベースを起動するたびにscnが1000kを増やす)*/   /* 10gのあるバーションは9iと違って、隠しバラメタ_allow_error_simulationを設定する必要がある。 */   SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE    10.2.0.4.0      Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production   SQL> col current_scn format 999,999,999,999   SQL> select current_scn from v$database; CURRENT_SCN ----------- 1141408   SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started.   Total System Global Area 1653518336 bytes Fixed Size                  2213896 bytes Variable Size             989857784 bytes Database Buffers          654311424 bytes Redo Buffers                7135232 bytes Database mounted.   SQL> alter session set events '10015 trace name adjust_scn level 1'; Session altered.   SQL> alter database open; Database altered.   SQL>  select current_scn from v$database; CURRENT_SCN ----------- 1142031   /* current_scnが大量に増やしていないことを見られる。10.2.0.4でディフォルトは10015 adjust_scnを起こせない */   SQL>  alter system set "_allow_error_simulation"=true scope=spfile; System altered.   SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.   SQL> startup mount; ORACLE instance started. Total System Global Area 1653518336 bytes Fixed Size                  2213896 bytes Variable Size             989857784 bytes Database Buffers          654311424 bytes Redo Buffers                7135232 bytes Database mounted.   SQL> alter session set events '10015 trace name adjust_scn level 1'; Session altered.   SQL> alter database open; Database altered.   SQL>select current_scn from v$database; CURRENT_SCN ---------------- 1,073,741,980 ユーザーがデータベースを再起動することを繰り返すことで今のSCNをdependent SCNの127037138に高めた;これでデータベースを原以为这样就可以打开数据库了,谁知道又出现了一下错误: Wed Aug 25 07:43:53 2010 Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_929958.trc: ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], [] Wed Aug 25 07:43:53 2010 Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_929958.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], [] Wed Aug 25 07:43:53 2010 Error 704 happened during db open, shutting down database BootstrapはブートストラッププロセスでORA-600 [4000]エラが起こった。そのエラはOracleがデータファイルを読み取るときに(主にundo$ベーステーブル)記録されたUSNが該当するロールバックセグメント失敗したことで引き起こした。隠しバラメタ_corrupted_rollback_segmentsを設定することによって、このエラを避けられて、データベースを強制的に起動できる。そのArgument[a]は読み取りが失敗したUSN(undo segment number)と意味しているが実際にトラブルがあるロールバックセグメントはこれだけではない。 /* stringsツールでsystemテーブルスペースから各ロールバックセグメントの名前を見つけ出せる。*/ $strings system.dbf |grep _SYSSMU|less _SYSSMU1$ _SYSSMU2$ _SYSSMU3$ _SYSSMU4$ _SYSSMU5$ _SYSSMU6$ _SYSSMU7$ _SYSSMU8$ _SYSSMU9$ ......... alter system set "_corrupted_rollback_segments"='(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$, _SYSSMU11$, _SYSSMU12$)' scope=spfile; System altered.   /* たとえ_corrupted_rollback_segments隠しバラメタを設定したところで、4000エラも現れるかもしれない。10513トランザクションを加えて、データベースを再起動することを繰り返してください。*/   SQL> alter system set event='10513 trace name context forever,level 2' scope=spfile; System altered.   /* 再び4000エラになった */ Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_1016014.trc: ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], [] Thu Aug 26 09:43:39 2010 Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_1016014.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], [] Thu Aug 26 09:43:39 2010 Error 704 happened during db open, shutting down database   /* 再起動したら4000エラが現れていない。 * / 再起動したら4000エラが現れていないが、ディクショナリー検証段階でOracleはデータファイル227が今のincarnationとマッチしていないと見なされている: Thu Aug 26 11:13:22 2010 Dictionary check beginning Thu Aug 26 09:46:00 2010 Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_897162.trc: ORA-01177: data file does not match dictionary - probably old incarnation ORA-01110: data file 227: '/oracle/QAS/sapdata2/qas_192/qas.data196' Error 1177 happened during db open, shutting down database USER: terminating instance due to error 1177 Instance terminated by USER, pid = 897162 ORA-01177の原因は主に二つがある: 1.データディクショナリーがエラになり,227ファイルに該当するincarnation情報は正確ではない。 2.前回のresetlogs openプロセスで、227号ファイルヘッダがある原因で正確にincarnation情報をアップグレードしていない。 このような場合に対して、データファイルのデータをリカバリしたい場合に、人工的にデータディクショナリーあるいはファイルヘッダを修正するしかない。 そしてコントロールファイルを再構造することで済ませた: CREATE CONTROLFILE REUSE DATABASE "QAS" RESETLOGS  NOARCHIVELOG --  SET STANDBY TO MAXIMIZE PERFORMANCE MAXLOGFILES 255 MAXLOGMEMBERS 3 MAXDATAFILES 254 MAXINSTANCES 50 MAXLOGHISTORY 36302 LOGFILE GROUP 1 ( '/oracle/QAS/redolog/redolog11A.dbf', '/oracle/QAS/redolog/redolog11B.dbf' ) SIZE 500M, GROUP 2 ( '/oracle/QAS/redolog/redolog12A.dbf', '/oracle/QAS/redolog/redolog12B.dbf' ) SIZE 500M -- STANDBY LOGFILE DATAFILE '/oracle/QAS/sapdata1/system_1/system.data1', ........ '/oracle/QAS/sapdata2/qas_192/qas.data195' CHARACTER SET WE8DEC Thu Aug 26 14:04:50 2010 Successful mount of redo thread 1, with mount id 2117500093 Thu Aug 26 14:04:50 2010 Completed: CREATE CONTROLFILE REUSE DATABASE "QAS" RESETLOGS Thu Aug 26 14:05:05 2010 alter database mount Thu Aug 26 14:05:05 2010 ORA-1100 signalled during: alter database mount... Thu Aug 26 14:05:15 2010 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 1125281471596 Resetting resetlogs activation ID 0 (0x0) Online log 1 of thread 1 was previously cleared Thu Aug 26 14:05:36 2010 Assigning activation ID 2117500093 (0x7e367cbd) Thread 1 opened at log sequence 1 Current log# 2 seq# 1 mem# 0: /oracle/QAS/redolog/redolog12A.dbf Current log# 2 seq# 1 mem# 1: /oracle/QAS/redolog/redolog12B.dbf Successful open of redo thread 1 Thu Aug 26 14:05:36 2010 SMON: enabling cache recovery Thu Aug 26 14:05:36 2010 Dictionary check beginning Tablespace 'PSAPTEMP' #2 found in data dictionary, but not in the controlfile. Adding to controlfile. File #227 found in data dictionary but not in controlfile. Creating OFFLINE file 'MISSING00227' in the controlfile. This file can no longer be recovered so it must be dropped. File #228 found in data dictionary but not in controlfile. Creating OFFLINE file 'MISSING00228' in the controlfile. This file can no longer be recovered so it must be dropped. File #229 found in data dictionary but not in controlfile. Creating OFFLINE file 'MISSING00229' in the controlfile. This file can no longer be recovered so it must be dropped. Dictionary check complete Thu Aug 26 14:05:38 2010 SMON: enabling tx recovery Thu Aug 26 14:05:38 2010 Database Characterset is WE8DEC replication_dependency_tracking turned off (no async multimaster replication found) Completed: alter database open resetlogs