第11章. データベースの整合性を維持する

改訂履歴
改訂 V5.5-000/10 2012年9月28日

“O5 – 損傷したスパニング・ノードの回復”“破損したバイナリ抽出からデータをリカバリ” の2つの新しいセクションを追加

改訂 V5.5-000/2 2012年3月19日 “O4 –失われたインデックスを持つデータ・ブロックの回復” の中の参考例でシンタックス・エラーを修正
改訂 V5.4-002B 2011年10月24日 各章の改訂履歴を含むGT.Mのリリースを反映したドキュメント改訂履歴への変換

目次

データベースの整合性を検証する
定期的にスケジュールされた検証
メジャーな転送の前後
致命的なイベントの後、直ちに
実行時のデータベースエラーの後、直ちに
データベース修復の後、直ちに
データベースの回復へのアプローチ
ジャーナリングからの回復
バックアップから復元
DSEの修復
予防的な保守
DSEのを使用してデータベースを修復する
適切なデータベースファイルの使用
DSEを使用した構造の位置を見つける
修復の安全性
データ破棄
同時に修復
プロセスを終了
破損したバイナリ抽出からデータをリカバリ
データベースエラーを見つけて修正する
C1 - キャッシュ可能な制御の問題
H1 - プロセス・ハング
H3 - データベース・アクセスの問題
H4 - データベース・キャッシュの問題
H5 - クリティカル・セクションの問題
H6 - UNIXの問題
H7 - ディスク・ハードウェアの問題
H8 - アプリケーションの問題
I1 - MUPIP INTEGエラー
I2 - GT.Mバージョン・ミスマッチ
I3 - ファイル・ヘッダー・エラー
I4 - ファイル・サイズ・エラー
I5 - データベース・アクセスに関するその他の問題
I6 - 一過性エラー
I7 - データベースのRundown問題
I8 - 修復を誘発する問題
K1 - Badキー
K2 - キーの付け間違い
K3 - ブロック二重割り付け
K4 - ポインタの問題
K5 - スター・キーの問題
K6 - 圧縮カウント・エラー
K7 - キーの警告
M1–ビットマップ・エラー
M2 - ビットマップ・ヘッダの問題
O1 –不良ブロック
O2 - レコード・エラー
O3 – データ・ブロック・エラー
O4 – 失われたインデックスを持つデータ・ブロックの回復
O5 – 損傷したスパニング・ノードの回復
P1 - プロセス・ダメージ
Q1 - データベース・アクセスの制限
R1 – GT.Mランタイム・エラー
R2 - データベース構造の整合性エラー
R3 - ランタイム・データベース・キャッシュの問題
R4 - 停止されたプロセス
R5 – ファイル内に空き領域がない
R6 - GTMASSERTおよびGTMCHECKエラー
R7 - 連動型キュー・ハードウェアの問題
R8 - データベース・ツリーの最大レベル超過
R9 - 読み取り専用プロセスがブロックされている

この章では、データの可用性と整合性を維持するために、GT.Mにおける方法について説明します。

GDSの整合性を持つデータベースは、アプリケーションデータのview(ビュー)の観点から、一貫性がないかもしれません。つまり、GDSデータベース構造を損傷しない特定の障害タイプは、すべてではないが、適切な更新の一部の中で "非論理的な(illogical)" 状態で停止することにより、論理トランザクション(アプリケーション内で複数のデータベース更新で構成)を引き起こす可能性があります。トランザクションプロセッシングとデータベース ジャーナリングは、アプリケーションデータの整合性を維持するための良い方法です。トランザクションプロセッシングの詳細については、GT.Mプログラマーズ·ガイド の "Mの一般的な言語仕様" と "コマンド" の章 を参照してください。ジャーナリングの詳細については、このマニュアルの "GT.Mジャーナリング" の章を参照してください。

データベースの整合性を維持することは、GT.Mの動作に不可欠です; もしジャーナリングを使用するならば、特別に、この章の資料を必要とするべきことははほとんどありません。しかし、データベースは、ハードウェア障害、電源の突然の損失、オペレーティングシステム障害や不適切なオペレータの操作などのような異常なイベントによって破損することがあります。そのようなすべてのイベントでは、データベース整合性チェックに従うべきです。

この章では、次の項目について説明します。

inserted by FC2 system