Email: service@parnassusdata.com 7 x 24 online support!
オブジェクト破損時の対応:その1(破損ブロックの確認)(KROWN:135804)
[概要] 本文書は、ブロック破損が発生した際の破損ブロックの確認方法について説明し ます。 破損ブロックの確認、復旧および原因調査について、それぞれ以下の文書を参照 して下さい。 Document 1746539.1(KROWN:135804) オブジェクト破損時の対応:その1(破損ブロックの確認) Document 1746576.1(KROWN:135925) オブジェクト破損時の対応:その2(破損ブロックの復旧) Document 1746577.1(KROWN:135926) オブジェクト破損時の対応:その3(原因調査のアプローチ) [対象リリース] すべてのリリース [対象プラットフォーム] すべてのプラットフォーム [詳細] 破損ブロックの確認 ================== ■ オブジェクトの特定 1) DBA が特定できている場合 1. 以下 SQL文を使用して DBA から FILE#, BLOCK# を確認します。 SQL> SELECT dbms_utility.data_block_address_file(DBA#) "FILE#", 2 dbms_utility.data_block_address_block(DBA#) "BLOCK#" FROM dual; Document 1702410.1(KROWN:11887) データ・ブロック・アドレスからファイル番号とブロック番号を得る方法 2. 確認した FILE#,BLOCK# より以下の SQL文を使用して破損オブジェクトを 特定します。 SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS 2 WHERE <FILE#> = FILE_ID AND <BLOCK#> BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS -1; 2) FILE#,BLOCK# が特定できている場合 以下の SQL文 を使用して破損オブジェクトを特定します。 SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS 2 WHERE <FILE#> = FILE_ID AND <BLOCK#> BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS -1; ** 注意 ** SQL文 や alert ログ、トレースファイルから確認した FILE# は、相対 ファイル番号のため dba_data_files.relative_fno から相対ファイル が複数存在するか確認して下さい。 Document 1710756.1(KROWN:32555) Oracle8からのファイル番号に関する注意事項 ********** ■ 破損の確認 特定したオブジェクトの破損を確認します。 1) ANALYZE の実行 SQL> ANALYZE TABLE <TABLE_NAME> VALIDATE STRUCTURE; SQL> ANALYZE TABLE <TABLE_NAME> VALIDATE STRUCTURE CASCADE; SQL> ANALYZE INDEX <INDEX_NAME> VALIDATE STRUCTURE; * analyze コマンドでは、バッファ上のデータを使用します。 ディスク上で破損していなく、バッファ上でのみ破損しているケース でもエラーを検知するため、可能な限り再起動を実施後に analyze を実行して下さい。 2) dbv の実行 $ dbv file=<datafile_path> blocksize=<block_size> * ASM 環境の場合には、dbv の代わりに RMAN を使用してチェックを行い ます。 RMAN> BACKUP CHECK LOGICAL VALIDATE DATABASE; 3) 論理ダンプの取得 SQL> ALTER SYSTEM DUMP DATAFILE <絶対ファイル番号> 2 BLOCK MIN <BLOCK#-10> BLOCK MAX <BLOCK#+10>; 4) 物理ダンプの取得 - HP-UX の場合 % dd bs=<block_size> if=<datafile_path> skip=<block#-10> count=21 | od -x > dump.txt - Solaris, Linux, AIX の場合 % dd bs=<block_size> if=<datafile_path> skip=<block#-10> count=21 | od -x -v > dump.txt * 前後合わせて合計21ブロック取得します。 ■ バックアップの確認 どのようなバックアップを取得しているか確認します。 - ユーザ管理のオンライン(オフライン)バックアップ - RMAN を使用したオンライン(オフライン)バックアップ - exp/imp (もしくはDatapump) ユーティリティを使用した論理バックアップ - csv 形式でのバックアップ など DBA_EXTENTS を検索する際の注意点 -------------------------------- オブジェクトの特定で確認を行った DBA_EXTENTS への SELECT の結果が "no rows selected" になる場合があります。 "no rows selected" となるケースは以下です。 - EXTENT が既に開放されたブロック(未使用ブロック) dbv では EXTENT が獲得されていないブロックもチェックするため、場合 によっては対処不要な Corrupt も出力させます。 詳細は以下 KROWN を確認下さい。 Document 1720681.1(KROWN:60310) DBV使用時にエラーが発生 ※ EXTENT が開放されているブロックでの破損は対処不要です。 - ローカル管理表領域のビットマップブロック ローカル管理表領域のビットマップブロックは、セグメントではないため エクステントを獲得しないことから DBA_EXTENTS で確認できません。 データファイルヘッダーから 64KB 分がビットマップブロックとなるため、 ブロック番号は小さい値ですがブロックダンプより確認を行って下さい 上記のどちらのケースか確認するために、取得したブロックダンプから ブロックタイプを調べます。 ブロックタイプが、 "KTFB Bitmapped File Space Header" (0x1D)もしくは "KTFB Bitmapped File Space Bitmap" (0x1E)であるか確認します。 "KTFB Bitmapped File ..." では、対象ブロックがビットマップブロックで、 それ以外のブロックタイプでは、EXTENT が開放されているブロックです。 ブロックダンプの以下の箇所から確認できます。 ------------------ buffer tsn: 0 rdba: 0x00400062 (1/98) scn: 0x0000.000fee5a seq: 0x01 flg: 0x06 tail: 0xee5a0601 frmt: 0x02 chkval: 0x5b40 type: 0x06=trans data ^^^^^^^^^^^^^^^^^^^^^ <--- ★ この type を確認します。 ------------------ 論理ダンプが取得できないケースでは、バイナリで確認します。 ブロックタイプが 0x1D もしくは 0x1E となっている場合には、ビットマップ ブロックです。 ------------------ CEE1C00 0000A206 00400062 000FEE5A 06010000 ^^<--- ★ この 0x06 がブロックタイプです。 CEE1C10 00005B40 00000002 0000000B 000FEE59 CEE1C20 00000000 00020002 00000000 00000000 CEE1C30 00000000 00000000 00000000 00000000 CEE1C40 00000000 00200003 000001EF 00801CE3 CEE1C50 000500BD 00002001 000FEE5A 01800000 CEE1C60 00000000 00A80042 1B5F1BFA 00000000 CEE1C70 00000000 00000000 00000008 00001F60 CEE1C80 1F531F47 1F2D1F3A 1F131F20 1EF91F06 ------------------ * Linux の出力例です。ビッグエンディアンとリトルエンディアンでブロック タイプが格納される位置が異なるためご注意下さい。