そのデータベース壊せますか？ そして直せますか？：データベースエンジニアへの道（6）（2/4 ページ）

[吉田知史，アクセンチュア・テクノロジー・ソリューションズ]

論理障害と物理障害

　データベースの障害には論理障害と物理障害の2種類があり、論理障害はデータベースに格納されたデータの障害、物理障害はデータの入れ物であるデータベースの障害と定義します。障害を起こした部分が論理的なもの（ソフトウェア）なのか、物理的なもの（ハードウェア）なのかという視点ではなく、データなのか、データベースなのかで分類します。例えば、データベースを構成するファイルの論理的な破損はデータベース障害＝物理障害になります（表2）。

障害の種類	障害の状況	障害の原因	障害の予防	障害の対応
論理障害 （データ障害）	・データ値の異常（値、組合せ） ・テーブル間の整合性の異常 ・データの消失	・ユーザーの操作ミス ・管理者の作業ミス ・バッチインプット／システム間インターフェイスの異常 ・プログラムのバグ	・制約の実装（データ型、Check制約、参照整合性制約など） ・データベーストリガーによるバリデーション ・アプリケーションプログラムによるバリデーション	・バッチ処理によるデータ整合性チェック ・データ分析による不正データ検出 ・プログラムの品質向上 ・データリカバリ ・データベース改修（プログラム改修）
物理障害 （データベース障害）	・データベース応答不能 ・データベースレスポンス低下	・電源異常 ・ハードウェア故障 ・OSクラッシュ ・ファイルシステム破損 ・インスタンス停止 ・ディスクの容量不足 ・管理者の作業ミス（表領域の削除など）	・ディスク、ファイルの多重化（RAIDなど） ・データベースの多重化（RAC、DataGuardなど） ・ハードウェアの二重化（ブレードサーバなど） ・ネットワークの二重化 ・バックアップの取得 ・監視	・ハードウェア部品交換・修理 ・ファイルシステムリカバリ ・データベースリカバリ ・データリカバリ
表2　論理障害と物理障害

論理障害の予防と対応

　論理障害の代表的な障害状況には次の3つがあります（図3）。以降では、これらの予防と対応について、事例を交えながら紹介します。

図3　論理障害の代表的な障害状況

論理障害　（1）データ値異常

障害の状況と原因

　データ値異常は論理障害の代表的な障害で、データベースに格納されているデータの値が本来の値と異なっている状態です。典型的な例としては、株式の誤発注やオンラインショップの価格設定ミスといった数値の入力ミスがあります。データ値異常の多くは人為的な入力ミスによって引き起こされるもので、間違ったデータ値を入力してもシステムが警告を出さなければ、その場で入力ミスに気付くことは困難です。

　先ほどのオンラインショップの例では、価格のデータを入力した翌日に大量の注文が入っていたため、調査をしてみたら入力ミスをしていたといった、時間が経過してから障害が発覚するケースが多いのが特徴です。

障害の予防

　人為的な入力ミスを予防するには、フールプルーフ（fool proof）といわれる「ミス防止に対するアプローチ」が有効です。具体的な実装としては、画面からのユーザーの自由な入力を排除して選択式に変更したり、入力された値をチェックして確認画面を出すなどの方法があります。フールプルーフの実装は難しくありませんが、次の2つのポイントに注意してください。

ポイント1　管理者向け機能にフールプルーフを実装する

　業務システムで利用者向けに提供されている機能と、管理者向けに提供されている機能のフールプルーフの実装を比べてみると、利用者向け機能の方が手厚く実装されているケースが多く見られます。利用者はシステムの習熟度が低くてミスをしやすく、さらに利用者数が多くなるほど利用回数が多いため、きめ細かく対応する必要があります。

　一方、管理者は習熟度が高いためミスをしにくく、管理作業の限られた利用しか行わないため、管理者向け機能はフールプルーフを実装する以前に機能が削られたり、単純化されることが珍しくありません。場合によっては機能そのものが開発されず、ミドルウェアやOSレベルのメンテナンスツールを手順書を見ながら操作する場合もあります。しかし、実際に入力ミスが起こった場合を考えると、管理者向け機能の方がシステムに与える影響が大きいのは明白です。障害発生のリスクを低減させるため、管理者向け機能にもフールプルーフの実装を行うことをお勧めします。

ポイント2　バリデーションチェックでデータ値の業務上の妥当性までチェックする

　業務システムでは、入力データに対して必ずバリデーションチェックを行います。ここで最低限行わなくてはならないのはデータ型、属性、けた数、制約といったデータベースの制約に合わせた格納目的のチェックですが、これではデータの値そのものが業務上正しいかという妥当性を判断するには不十分です。

　例えば、オンラインショップで販売価格を10万円と登録するところを間違えて1万円で登録してしまったとしましょう。このとき、10万円と1万円はどちらも金額としてはあり得る値のため異常とは判断されません。これを予防するには、仕入価格を参照して利益率を算出し、それがある一定の範囲を外れる場合はアラートを出す、といった仕組みが必要です。皆さんの記憶にも新しいかと思いますが、2005年12月に東京証券取引所で起こった株式誤発注も、データ入力時に値の妥当性チェックが行われていれば防げた問題です。

　このようにデータの値に対して、値範囲や平均値、他項目との比較、前年比／前月比など周期的なデータ分析などを行い、その分析範囲から外れたものに対してアラートを出すといった、値の業務上の妥当性チェックを実装することで論理障害を予防できます。

　また、画面からデータを入力する際は、重要度の高いデータのみに妥当性チェックを行い、そのほかのデータについては夜間処理で巡回チェックするなどの実装も考えられます。

Point　

データ値異常を予防するには、

• 管理者向け機能にフールプルーフを実装する
• バリデーションチェックでデータ値の業務上の妥当性までチェックする