Email: service@parnassusdata.com 7 x 24 online support!

    You are here

    • You are here:
    • Home > Blogs > PDSERVICE's blog > ORACLEがora-600[2662]になったことを解決する:データブロックのSCNが既存するSCNより大きい

ORACLEがora-600[2662]になったことを解決する:データブロックのSCNが既存するSCNより大きい

ORACLEがora-600[2662]になったことを解決する:データブロックのSCNが既存するSCNより大きい

ORACLEデータベース によくあるエラ の解決策

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

目的:

内部エラ“ora-600[2662]”の意味と解決策を紹介する。

 

エラ:

フォーマット:ora-600[2662][a][b][c][d][e]

バーション:6.0到12.1

 

ディスクライブ:

データブロックのSCNが既存するSCNより大きい。

主に、UGA変数のdependent SCNと比べてみれば、既存するSCNがそれより小さい場合に、データベースがORA-600 [2662]になる。

バラメタ:

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.

機能:

Redoログファイル管理とIOメモリ管理

 

影响:

インスタンスシャットダウン

物理的なエラが現れるかもしれない

 

アドバイス:

異なった場合にもORA-600[2662]エラになる:

これはデータベースを起動するときに起こるかもしれない。

もしパラレルサーバを使っていなければ、二つのインスタンスが同じデータベースに属しているか確認してください。

SMONのトレースファイルよアラームログファイルを確認する。

SCNの相違、バラメタdとバラメタbを確認する

SCNがかなり近づいていれば、クロスして再起動する。

一部の場合に、SCNがデータベースを起動すると増やすかもしれない。

 

もし、以下の情報でトラブルを確認できなければ、トレースファイルとアラームログはOracle技術サポートに提供してください。

 

二つのタイプのエラ

タイプ1:

4/5バラメタ形式

データブロックのSCNは既存するSCNより早い。

タイプ2:

一つのバラメタ形式(7.2.3前のバーションしかい起こらない)

 

タイプ1

もしSCNは既存するSCNから場合に、DBAを0と格納してください。もし、uodo$から場合に、ロールバックセグメントは使えないから、DBAがundoセグメント番号を格納する。0番号ファイルのブロックに見える。もしSCNはredoログから(つまり、ブロック番号== 0の変更数値)。では、DBAはブロック0に関連するデータファイル。もし、それは別のデータベースのトランザクションなら、DBAはDBAINF()と意味している。もし、それはTXロックなら、DBAはUSN<<16 +と意味している。

 

タイプ2

ログブロック総計テスト

分析開始:

1、このエラはデータベースが運用しているうちに、あるいはデータベースを起動するときに現れる;

2、バラメタd及びバラメタbの違い

3、5つのバラメタの場合

DBAをファイル番号に変更する

データディクショナリーオブジェクトか否か(ファイル番号は1)

4、今のSQL文(trace次第)

どこのテーブルに指しているか?

前のステップで探し出したオブジェクトはここで指したものと同じなのか?

 

注意:これはDBAと関係ない。トラブルの原因は(blockdump)

より深刻に分析する:

(1)traceファイルを確認する:

これもまともなユーザートレースファイルあるいはsmonのトレースファイル。

(2)’buffer’を確認する

oracle7 dumpファイルの“buffer dba”

oracle8あるいはOracle9 dumpファイルの”buffer tsn”

これは2662エラの源を探し出せる。

 

このエラの原因:

1.隠しバラメタ_ALLOW_RESETLOGS_CORRUPTIONを使って、resetlogs、データベースを起動する

2.ハードウェアエラでデータベースが制御ファイルとredoログを書き込めなくなった。

3.データベースリカバリ

4.制御ファイルをリカバリしたが、recover database using backup controlfileを使っていない

5.データベースcrashしたあと_DISABLE_LOGGINGという隠しバラメタを設置した

6.パラレルサーバでDLMにトラブルが存在している

7、BUG

 

解决策:

 

(1)もしSCN番号の違いが小さい場合に、データベースを何度も再起動して、再起動するたびにSCN番号も増やす。dscn=scnの場合に、データベースを起動できる

(2)ADJUST_SCNトランザクションで既存するSCNを調整する。dependent SCNより大きいようにする。そして。データベースごとにエクスポートできることを保障してください。データベースを再構造してデータをインポートする。