【データリカバリ】ORA-8103エラを解析する

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

  ORA-8103は我々Database Consultant がよく見られるトラブルである。 ORA-8103の 原因は主に二つがある:

• データブロックのタイプが無効的なものあるいはブロックタイプがOracleが予想したものと違っている。例えばOracleがデータタイプをdata(type=6)と見なしているが実際にはそうじゃない。
• データブロックのdata_object_id とデータディクショナリーのdata_object_idがマッチしていない。

  ORA-8103トラブルに対して、以下の処置を勧めている： ORA-08103トラブルの診断は8103エラのERROR STACK TRACEを作成して、TRACEで8103を引き起こしたOBJとOBJDを記録する。これはcorruptionがある相手を定義できる。 トラブルはフォアグラウンドプロセスがORA-08103エラになった場合に、バックグラウンドでTRACEファイルを作成しない。それで、人工的に8103を設定して、ERRORSTACKのEVENTSを引き起こす必要がある: ALTER SYSTEM SET EVENTS ‘8103 TRACE NAME ERRORSTACK LEVEL 3’; 解決策は以下の通り： 1. OBJDとDBAで具体的テーブル名とブロック名を探し出す 2. できればそのテーブルをanalyze .. validate structureしてください 3. できればそのテーブルを含むtablespaceに対して dbms_space_admin.ASSM_TABLESPACE_VERIFYしてください 4. できればそのテーブルを関するパーティションに移して、トラブルを避けてみてください 5. できれば。そのテーブルあるいはパーティションをMSSMテーブルスペースに移してトラブルを避けてください execute dbms_space_admin.tablespace_verify(‘&tablespace_name’) oradebug setmypid oradebug tracefile_name execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS) oradebug setmypid oradebug tracefile_name     異なる analyze validate structureした結果に対して、初期的な結論を下せる：   flush buffer cacheを実行したあと再びanalyze validate structureするときにORA-8103エラが現れないとは： これは正常の現象かもしれない。前に言ったORA-8103はオブジェクトがDROP/TRUNCATEされて、SELECTがORA-8103になった。一般的にCall Stackはプロセスがプロセスがそのセグメントヘッダをアクセスできる。より多くの情報はBUG 7441661に参考できる。 これもbuffer cacheだけに起こるかもしれない。flush buffer_cacheで解決できるなら、大体こういう場合に限っている。それにいつもBuffer Cacheが管理するBUGである 。     flush buffer cacheを実行したら、再びanalyze validate structureするときにORA-8103なったとは： 該当するデータブロックをダンプするときに、そのブロックがロジックに一致している。（bed/dbvツールで検証できる)。Lost Writeの可能性もあって、ほかのオブジェクトに再びフォーマットされない。 ここでLost Writeを判断する大事な手段とはブロックにrecover/blockrecoverする。もしリカバリできるなら、ORA-8103エラがLost Writeで引き起こした。そうでなければ99%はBUGによるものである。 よくある状況はほかのツールでデータベースを起動したままにデータベースをコピしてたが、ツールのBUGによって、古いバーションのblockを新たなデータベースにコピするかもしれない。   もう一つの可能は extentレベルが一致していない。同じデータブロックが同時に二つのデータセグメントに属していて、あとのセグメントに上書きされるかもしれない。このようなロジックエラがテーブルスペースレベルのエクステント情報に起こるから、リカバリするだけで修復できない。dba_extents/dba_segments/dba_free_spaceなどのインメージを検証することによって、これらのブロックが複数のオブジェクトに属しているかを確認できる。あるいはあるデータブロックが同時にdba_extents/dba_segments/dba_free_space 三つのインメージに現れたが、 used extentがdba_free_spaceに現れるはずがないから。それにfree extentもdba_extentsに現れるわけがない。Recyclebinのオブジェクトの影響を除いて、大多数の場合に、こういうロジックが一致していない状況はextent overlap と呼ばれている。これは一般的にOracle Space Managementスペース管理のBUG。   ORA-8103エラに対する診断プロセスで、トラブルのOBJDを探し出すことはとっても大切である。けど、ORA-8103エラとBUGとつながるとはとっても難しい。 これはredo dumpに関わっている。一部のBUGで、変数が古いから、作成したobjd構造が削除されていない。そしてブロックのobjdが間違えたと気づいた。それはORA-8103あるいはORA-1410かもしれない。これは後のロジックエラを引き起こしたからTRACE/REDO LOG DUMPで原始なトラブルの場合を見つかりにくくなった。これもロジックエラの分析と処置は物理的なエラより難しいと言った理由である。   Macleanの経験は大量なOracle DBを持っている環境で、一年に何度ロジック/物理ベッドブロックが現れるのはごく普通なことである。物理的な場合に対して、バックアップすればいい。ロジックベッドブロックの場合にやることがあんまりない。   ORA-8103のBug Noteを読んで、 LOB、APPEND INSERT、PARALLEL INSERT、exchange partition 、Split partition、advanced compression、HCC 混ぜた列凍結をするのはORA-8103になるかもしれない。けど実際には以上の操作を諦めるわけにはいかない。   今までORA-8103に関するBUGリスト：