19データ-ブロック破損の検出と修復

Oracleは、データ-ブロック破損の検出と修正のためのさまざまな方法を提供しています。 一つの方法は、破損が検出された後にオブジェクトを削除して再作成することですが、これは常に可能であるか、または望ましいとは限りません。 データブロックの破損が行のサブセットに制限されている場合は、破損した行を除くすべてのデータを選択してテーブルを再構築することもできます。データ・ブロックの破損を管理するもう1つの方法は、DBMS_REPAIRパッケージを使用することです。 DBMS_REPAIRを使用すると、表および索引の破損ブロックを検出および修復できます。 この方法を使用すると、可能な限り破損に対処し、オブジェクトを再構築または修復しようとしている間もオブジェクトを使用し続けることがで DBMS_REPAIRでは、破損に対処するために次の方法を使用します:

• ステップ1:破損の検出とレポート
• ステップ2:DBMS_REPAIR
• を使用したコストと利点の評価ステップ3:オブジェクトを使用可能にする
• ステップ4:破損の修復と失われたデータの再構築
  注:DBMS_REPAIRを使用したコストと利点の評価

• ステップ3:オブジェクトを使用可能にする
• ステップ4:破損の修復と失われたデータの再構築
  :

  データの損失を伴う破損は、そのデータがデータベースシステム全体にどのように適合するかを分析し、理解する必要があります。 したがって、DBMS_REPAIRは魔法の杖ではありません-このパッケージによって提供される修復アプローチが、特定の破損の問題ごとに適切なツールであるかどうか 修復の性質によっては、データが失われ、論理的な不整合が発生する可能性があるため、DBMS_REPAIRの使用に関連する損益を比較検討する必要があります。

表19-1に、DBMS_REPAIRパッケージを構成する手順を示します。表19-1DBMS_REPAIR手順

手順名	説明
check_object	テーブルまたはインデックスの破損を検出して報告します。
fix_corrupt_blocks	(以前にcheck_objectプロシージャによって識別された)ブロックを破損としてマークします。
dump_orphan_keys	破損したデータブロック内の行を指すインデックスエントリを報告します。
rebuild_freelists	オブジェクトのフリーリストを再構築します。
skip_corrupt_blocks	使用すると、テーブルとインデックスのスキャン中に破損とマークされたブ 使用しない場合は、破損とマークされたブロックが検出されたときにエラー ORA-1578が発生します。
admin_tables	DBMS_REPAIR修復および孤立キー表の管理機能(create、drop、purge)を提供します。 注:これらのテーブルは、常にSYSスキーマ内に作成されます。

ステップ1:破損の検出と報告

DBMS_REPAIRを使用する前の最初のタスクは、破損の検出と報告である必要があります。 レポートは、ブロックの何が問題であるかを示すだけでなく、関連する修復指令も識別します。 破損を検出するには、DBMS_REPAIRに加えて、いくつかのオプションがあります。 表19-2に、さまざまな検出方法を説明します。

表19-2破損検出方式の比較

検出方法	説明
DBMS_REPAIR	指定されたテーブル、パーティション、またはインデックスのブロックチェックを実行します。 は、repairテーブルに結果を設定します。
DB_VERIFY	オフラインデータベースでブロックチェックを実行する外部コマンドラインユーティリティ。
分析	VALIDATE STRUCTUREオプションと共に使用すると、インデックス、テーブル、またはクラスターの構造の整合性を検証し、テーブルとインデックスが同期しているかどうかを
DB_BLOCK_CHECKING	破損したブロックが実際に破損しているとマークされる前に識別します。 チェックは、ブロックに変更が加えられたときに実行されます。

DBMS_REPAIR:check_objectおよびadmin_tablesプロシージャー

を使用すると、check_objectプロシージャーは、指定されたオブジェクトのブロック破損をチェックおよびレポートします。 分析に似ています。..VALIDATE STRUCTURE文索引および表については、索引およびデータ・ブロックについてそれぞれブロック・チェックが実行されます。

check_objectは破損を報告するだけでなく、オブジェクトでfix_corrupt_blocksがその後実行された場合に発生する修正も識別します。 この情報は、最初にadmin_tablesプロシージャによって作成される必要がある修復テーブルを移入することによって使用可能になります。

check_object プロシージャを実行した後、repairテーブルに対する単純なクエリに、オブジェクトの破損および修復ディレクティブが表示されます。 この情報を使用すると、報告された問題にどのように対処するのが最適かを評価できます。

DB_VERIFY:オフラインデータベースチェックの実行

通常、データ破損の問題が発生した場合は、オフライン診断ユーティリティとしてDB_VERIFYを使用します。

も参照: DB_VERIFYの詳細は、Oracle8Iユーティリティを参照してください。

ANALYZE:破損報告

ANALYZEテーブル。..VALIDATE STRUCTURE文は、分析されたオブジェクトの構造を検証します。 構造が正常に検証されると、その検証を確認するメッセージが返されます。 オブジェクトの構造が破損した場合は、エラー・メッセージが返されます。 この場合、オブジェクトを削除して再作成します。ANALYZE文の詳細は、Oracle8I SQLリファレンスを参照してください。

DB_BLOCK_CHECKING(ブロックチェック初期化パラメータ)

DB_BLOCK_CHECKINGパラメータ(デフォルト値はTRUE)を介してインスタンスのブロックチェックを設定できます。 DB_BLOCK_CHECKINGは動的パラメータで、ALTER SYSTEM SET文で変更可能です。 ステップ2:DBMS_REPAIRの使用によるコストと便益の評価DBMS_REPAIRを使用する前に、その使用の便益を負債との関係で比較検討する必要があります。; また、破損したオブジェクトをアドレス指定するために使用可能な他のオプ

最初のステップは、次の質問に答えることです:

1. 腐敗の程度は何ですか？

   破損と修復アクションがあるかどうかを判断するには、check_objectプロシージャを実行し、修復テーブルを照会します。

2. ブロック破損に対処するために他にどのようなオプションがありますか？

   データが別のソースから利用可能であると仮定して、オブジェクトを削除し、再作成し、再入力します。 別のオプションは、CREATE TABLEを発行することです。..新しいものを作成するために破損したテーブルからSELECT文として。

   selectステートメントから破損した行を除外することで、破損を無視できます。

   メディアリカバリを実行します。 DBMS_REPAIRを使用してオブジェクトを使用可能にすると、どのような論理的な破損または副作用が発生しますか。 これらに対処することはできますか？ そうするために必要な努力は何ですか？

   破損しているとマークされたブロック内の行にアクセスできない場合があります。 ただし、有効にアクセスできる行が残っている場合でも、ブロックが破損しているとマークされることがあります。

   ブロックが破損していると、参照整合性制約が壊れている可能性があります。 これが発生した場合は、制約を無効にして再度有効にします。 すべての問題を修正した後、制約を正常に再度有効にすることができます。

   テーブルにトリガーが定義されている場合、論理的な破損が発生する可能性があります。 たとえば、行が再挿入された場合、insertトリガーを起動する必要がありますか？ これらの問題に対処できるのは、インストールでのトリガーとその使用方法を理解している場合のみです。

   フリーリストブロックにアクセスできない可能性があります。 破損したブロックがフリーリストの先頭または末尾にある場合、スペース管理はフリーリストを再初期化します。 これに対処するには、rebuild_freelistsプロシージャを実行します。

   インデックスとテーブルが同期していない可能性があります。 これに対処するには、最初にdump_orphan_keysプロシージャを実行します(破損したデータの再構築に役立つ可能性のあるキーから情報を取得します)。 次に、ALTER INDEX REBUILD ONLINE文を発行して、表とその索引を同期に戻します。

3. 修復にデータの損失が含まれている場合、このデータを取得できますか？

   データブロックが破損している場合は、インデックスからデータを取得できます。 この情報を取得するには、dump_orphan_keysプロシージャを使用します。 もちろん、この方法でデータを取得することは、インデックスとテーブル間の冗長性の量に依存します。

ステップ3:オブジェクトを使用可能にする

このステップでは、DBMS_REPAIRは、表および索引のスキャン中に破損を無視してオブジェクトを使用可能にします。

: Fix_corrupt_blocksおよびskip_corrupt_blocksプロシージャ

を使用すると、DBMS_REPAIRの修復機能の範囲外の破損をスキップする環境を確立することによって、破損オブジェクトを使

データブロック内の不正な行など、破損にデータの損失が伴う場合、そのようなすべてのブロックはfix_corrupt_blocksプロシージャによって破損とマークされます。 次に、skip_corrupt_blocksプロシージャを実行すると、オブジェクトの破損とマークされたブロックがスキップされます。 Skipが設定されている場合、tableスキャンとindexスキャンは破損とマークされたすべてのブロックをスキップします。 これは、メディアとソフトウェアの破損ブロックの両方に適用されます。

壊れたブロックをスキップするときの影響

インデックスとテーブルが同期していない場合、あるクエリがインデックスのみをプローブし、後続のクエリがインデックスとテーブルの両方をプローブする状況では、SET TRANSACTION READ ONLY transactionに矛盾が生じる可能性があります。 テーブルブロックが破損とマークされている場合、2つのクエリは異なる結果を返し、読み取り専用トランザクションのルールを破ることになります。 これに対処する1つの方法は、SET TRANSACTION READ ONLY transactionの場合に破損をスキップしないことです。

チェーンされている行を選択すると、同様の問題が発生します。 基本的に、同じ行のクエリが破損にアクセスする場合とアクセスしない場合があり、それによって異なる結果が得られます。

ステップ4:破損を修復し、失われたデータを再構築

オブジェクトを使用可能にした後、次の修復アクティビティを実行できます。

dump_orphan_keysプロシージャを使用したデータのリカバリ

dump_orphan_keysプロシージャは、破損したデータブロック内の行を指すインデックスエントリについて報告します。 このような索引エントリはすべて、破損のキーとrowidを格納する孤立キー表に挿入されます。

索引エントリ情報を取得した後、ALTER INDEX REBUILD ONLINE文を使用して索引を再構築できます。

rebuild_freelistsプロシージャを使用したFreelistの修復

freelistの先頭または末尾に”corrupt”とマークされたブロックが見つかった場合、freelistは再初期化され、エラーが返されます。 これにより、問題のあるブロックがフリーリストから削除されますが、破損したブロックに続いているすべてのブロックへのフリーリストのアクセ

rebuild_freelistsプロシージャを使用して、フリーリストを再初期化できます。 オブジェクトがスキャンされ、ブロックがフリーリスト上にあることが適切であれば、それはマスターフリーリストに追加されます。 フリーリストグループは、公平な方法でブロックを満たすことによって処理されます-一度にブロック。 オブジェクト内で”破損”とマークされたブロックは、再構築中に無視されます。

制限事項および制限事項

DBMS_REPAIRプロシージャには次の制限事項があります:

• LOB、ネストされた表およびVARRAYを含む表はサポートされますが、out of line列は無視されます。
• クラスターはskip_corrupt_blocksおよびrebuild_freelistプロシージャでサポートされていますが、check_objectプロシージャではサポートされていません。
• 索引構成表およびLOB索引はサポートされていません。
• dump_orphan_keysプロシージャは、ビットマップインデックスまたは関数ベースのインデックスでは動作しません。
• dump_orphan_keysプロシージャは、最大で3,950バイトの長さのキーを処理します。

DBMS_REPAIRプロシージャ

この項では、DBMS_REPAIRプロシージャの詳細について説明します。

check_object

check_objectプロシージャは、指定されたオブジェクトをチェックし、破損および修復ディレクティブに関する情報をrepairテーブルに移入します。 検証は、オブジェクト内のすべてのブロックをチェックするブロックで構成されます。 オブジェクトの一部をチェックする場合は、必要に応じて範囲、パーティション名、またはサブパーティション名を指定できます。

procedure check_object(schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN binary_integer DEFAULT NULL, relative_fno IN binary_integer DEFAULT NULL, block_start IN binary_integer DEFAULT NULL, block_end IN binary_integer DEFAULT NULL, corrupt_count OUT binary_integer)

表19-3check_objectプロシージャー

引数	説明
schema_name	チェックするオブジェクトのスキーマ名。
object_name	チェックするテーブルまたはインデックスの名前。
partition_name (optional)	チェックするパーティション名またはサブパーティション名。 これがパーティション化されたオブジェクトで、partition_nameが指定されていない場合、すべてのパーティションとサブパーティションがチェックされます。 これがパーティション化されたオブジェクトで、指定されたパーティションにサブパーティションが含まれている場合は、すべてのサブパーティ
object_type (optional)	処理されるオブジェクトの型。 TABLE_OBJECTまたはINDEX_OBJECTのいずれかである必要があります。 デフォルトはTABLE_OBJECTです。
repair_table_name (optional)	移入する修復表の名前。 テーブルはSYSスキーマ内に存在する必要があります。 Repairテーブルを作成するには、admin_tables手順を使用します。 デフォルトの名前は’REPAIR_TABLE’です。
flags (optional)	将来の使用のために予約されています。
relative_fno (optional)	相対ファイル番号。 ブロック範囲を指定するときに使用します。
block_start (optional)	ブロック範囲を指定する場合に処理する最初のブロック。 オブジェクトが単一のテーブル、パーティション、またはサブパーティションの場合にのみ指定できます。
block_end (optional)	ブロック範囲を指定する場合に処理する最後のブロック。 オブジェクトが単一のテーブル、パーティション、またはサブパーティションの場合にのみ指定できます。 block_startまたはblock_endのいずれか一方のみが指定された場合、もう一方はそれぞれファイル内の最初または最後のブロックにデフォルト設定されます。
corrupt_count	報告された破損の数。

fix_corrupt_blocks

この手順を使用して、check_objectプロシージャによって以前に生成されたrepairテーブルの情報に基づいて、指定されたオブジェクトの破損ブロックを修正します。 ブロックへの変更を行う前に、ブロックが破損していることを確認するためにブロックがチェックされます。 破損したブロックは、ブロックソフトウェアが破損しているとマークすることによって修復されます。 修復が実行されると、修復テーブル内の関連する行が修正タイムスタンプで更新されます。

procedure fix_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN boolean DEFAULT NULL, fix_count OUT binary_integer)

表19-4fix_corrupt_blocksプロシージャ

引数	説明
schema_name	スキーマ名。
object_name	修正するブロックが破損しているオブジェクトの名前。
partition_name (optional)	処理されるパーティション名またはサブパーティション名。 これがパーティション化されたオブジェクトで、partition_nameが指定されていない場合、すべてのパーティションとサブパーティションが処理されます。 これがパーティション化されたオブジェクトで、指定されたパーティションにサブパーティションが含まれている場合は、すべてのサブパーティ
object_type (optional)	処理されるオブジェクトの型。 TABLE_OBJECTまたはINDEX_OBJECTのいずれかである必要があります。 デフォルトはTABLE_OBJECTです。
repair_table_name (optional)	repairディレクティブを含むrepairテーブルの名前。 SYSスキーマ内に存在する必要があります。
flags (optional)	将来の使用のために予約されています。
fix_count	ブロックの数は固定されています。

dump_orphan_keys

は、破損したデータブロック内の行を指すインデックスエントリを報告します。 このような索引エントリが検出されるたびに、指定された孤立表に行が挿入されます。

repair tableが指定されている場合、ソフトウェア破損とマークされているすべてのデータ-ブロックに加えて、ベース-テーブルに関連付けられている破損ブロック それ以外の場合は、破損とマークされたブロックのみが処理されます。

この情報は、テーブル内の失われた行を再構築したり、診断の目的で使用したりする場合に役立ちます。

procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', orphan_table_name IN varchar2 DEFAULT 'ORPHAN_KEY_TABLE', key_count OUT binary_integer)

表19-5dump_orphan_keysプロシージャ

引数	説明
schema_name	スキーマ名。
object_name	オブジェクト名。
partition_name (optional)	処理されるパーティション名またはサブパーティション名。 これがパーティション化されたオブジェクトで、partition_nameが指定されていない場合、すべてのパーティションとサブパーティションが処理されます。 これがパーティション化されたオブジェクトで、指定されたパーティションにサブパーティションが含まれている場合は、すべてのサブパーティ
object_type (optional)	処理されるオブジェクトの型。 デフォルトはINDEX_OBJECTです。
repair_table_name (optional)	ベーステーブル内の破損ブロックに関する情報を持つ修復テーブルの名前。 指定されたテーブルは、SYSスキーマ内に存在する必要があります。 テーブルを作成するには、admin_tablesプロシージャを使用します。
orphan_table_name (optional)	破損したデータブロック内の行を参照する各インデックスエントリに関する情報を移入する孤立キー表の名前。 指定されたテーブルは、SYSスキーマ内に存在する必要があります。 テーブルを作成するには、admin_tablesプロシージャを使用します。
key_count	処理されたインデックスエントリの数。

rebuild_freelists

指定されたオブジェクトのfreelistsを再構築します。 すべての無料のブロックは、マスターフリーリストに配置されます。 他のフリーリストはすべてゼロになっています。 オブジェクトに複数のフリーリストグループがある場合、フリーブロックはすべてのフリーリストに分散され、ラウンドロビン方式で異なるグループに割

procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);

表19-6rebuild_freelistsプロシージャ

引数	説明
schema_name	スキーマ名。
object_name	フリーリストを再構築するオブジェクトの名前。
partition_name (optional)	フリーリストを再構築するパーティション名またはサブパーティション名。 これがパーティション化されたオブジェクトで、partition_nameが指定されていない場合、すべてのパーティションとサブパーティションが処理されます。 これがパーティション化されたオブジェクトで、指定されたパーティションにサブパーティションが含まれている場合は、すべてのサブパーティ
object_type (optional)	処理されるオブジェクトの型。 TABLE_OBJECTまたはINDEX_OBJECTのいずれかである必要があります。 デフォルトはTABLE_OBJECTです。

skip_corrupt_blocks

指定されたオブジェクトのインデックスおよびテーブルスキャン中に破損したブロックのスキップを有効または無効にします。 オブジェクトがテーブルの場合、skipはテーブルとそのインデックスに適用されます。 オブジェクトがクラスターの場合、そのオブジェクトはクラスター内のすべてのテーブルとそれぞれのインデックスに適用されます。

procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN boolean DEFAULT SKIP_FLAG);

表19-7skip_corrupt_blocksプロシージャ

引数	説明
schema_name	処理されるオブジェクトのスキーマ名。
object_name	オブジェクトの名前。
partition_name (optional)	処理されるパーティション名またはサブパーティション名。 これがパーティション化されたオブジェクトで、partition_nameが指定されていない場合、すべてのパーティションとサブパーティションが処理されます。 これがパーティション化されたオブジェクトで、指定されたパーティションにサブパーティションが含まれている場合は、すべてのサブパーティ
object_type (optional)	処理されるオブジェクトの型。 TABLE_OBJECTまたはCLUSTER_OBJECTのいずれかである必要があります。 デフォルトはTABLE_OBJECTです。
flags (optional)	SKIP_FLAGが指定されている場合、インデックスおよびテーブルのスキャン中にオブジェクトのソフトウェア破損ブロックのスキップをオンにします。 NOSKIP_FLAGが指定されている場合、ソフトウェア破損ブロックが検出されたスキャンはORA-1578を返します。

admin_tables

は、修復および孤立したキーテーブルの管理関数を提供します。

procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL); 

表19-8admin_tablesプロシージャ

引数	説明
table_name	処理されるテーブルの名前。 デフォルトは、指定されたtable_typeに基づいて’ORPHAN_KEY_TABLE’または’REPAIR_TABLE’になります。 テーブル名を指定する場合は、適切な接頭辞’ORPHAN_’または’REPAIR_’を持つ必要があります。
table_type	表のタイプは、ORPHAN_TABLEまたはREPAIR_TABLEのいずれかである必要があります。
action	実行する管理アクションを示します。 CREATE_ACTION、PURGE_ACTION、またはDROP_ACTIONである必要があります。 テーブルが既に存在し、CREATE_ACTIONが指定されている場合は、エラーが返されます。 PURGE_ACTIONは、存在しないオブジェクトに関連付けられているテーブル内のすべての行を削除することを示します。 テーブルが存在せず、DROP_ACTIONが指定されている場合は、エラーが返されます。CREATE_ACTIONおよびDROP_ACTIONを指定すると、dba_<table_name>という名前の関連ビューがそれぞれ作成および削除されます。 ビューは、存在しないオブジェクトに関連付けられている行が削除されるように定義されます。SYSスキーマで作成された 。
tablespace (optional)	表の作成時に使用する表領域を示します。 デフォルトでは、SYSのデフォルト表領域が使用されます。 表領域が指定されていて、アクションがCREATE_ACTIONでない場合は、エラーが返されます。

DBMS_REPAIR例外

942	修復テーブルが存在しません
1418	指定されたインデックスが存在しません
24120	無効なパラメータ
24121	CASCADE_FLAGとブロック範囲を指定できません
24122	無効なブロック範囲
24124	無効なアクションパラメータが指定されています
24126	CASCADE_FLAG 指定されており、オブジェクトがテーブルではありません
24127	表領域が指定されており、actionがCREATE_ACTIONではありません
24128	パーティション化されていないオブジェクトに指定されたパーティション
24129	無効な孤立キーテーブル名-‘ORPHAN_’接頭辞を持つ必要があります
24129	指定された修復テーブルが’REPAIR_’接頭辞で開始されません
24131	修復テーブルの列が正しくありません
24132	修復テーブル名が長すぎます