あるアーカイブもバックアップもないテストデータベースを強制的に起動した。前にアクティブログファイル損害もあったから、隠しバラメタしか起動できない。
_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
Comment