咨询微信： dbservice1234 7 x 24 在线支持！

简体中文
English
日本語

你在这里

You are here:

首页

博客

PDSERVICE的博客

Oracleデータベースの強制オープン例

Posted by PDSERVICE on 1月 16, 2016 In

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

_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-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-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

你在这里

Oracleデータベースの強制オープン例

Oracleデータベースの強制オープン例

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

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