データベース構造チェックの後、エラーを分析し、それらの修正を試みます。
データ構造のチェックが完了している必要があります。
...
1. カーネルログを照会します (ログファイルを参照)。
カーネルログでは、データベース構造チェックの開始はキーワード CHECK でマークされており、その後にデータベース構造チェックの結果およびエラーがあった場合にはエラーが示されます。
典型的なエラーメッセージ:
2005-04-08 09:40:30 0x37C ERR 53019 CHECK Base error:bad_datapage
2005-04-08 09:40:30 0x37C ERR 53019 CHECK Root pageNo: 104236
2. 各エラーについて、それぞれの B* ツリーのルートページ (ROOT) 番号を特定します。SAP liveCache データの場合は、それぞれのページチェーンのルートページを特定します。
3. ROOTS システムテーブルを使用するか、または SAP liveCache データの場合は CLASSCONTAINER_ROOTS システムテーブルを使用して、影響を受ける基本テーブルまたは索引をそのルートページ番号から推測します (参照マニュアル、システムテーブルの分析)。
4. エラーによって索引が影響を受ける場合は、損傷した索引をリストアします。参照
○ データベースマネージャ GUI、データベースリストア後の索引のリストア
○ データベースマネージャ CLI、sql_recreateindex
○ CCMS におけるデータベース管理: MaxDB、索引分析
5. エラーによって基本テーブルが影響を受ける場合は、以下に示すオプションがあります。
○ 基本テーブルを削除します。他のテーブルから基本テーブルの再構築を試みることができます。
○ データベースマネージャを使用して、データベースインスタンスをリストアします。これを行うには、最後に成功したデータベース構造チェックの前に作成されたバックアップを使用します。
6. データベースインスタンスのデータベース構造チェックをまだ実行していない場合は、バックアップのインポート後に損傷を受けたテーブルのデータベース構造チェックを再度実行します。データベースシステムによって再びエラーが見つかった場合は、古いバックアップをインポートします。参照
○ データベースマネージャ GUI、前のバックアップからのリストア
○ データベースマネージャ CLI、recover_start