そのデータベース壊せますか？ そして直せますか？：データベースエンジニアへの道（6）（4/4 ページ）
論理障害の対応 データリカバリ
論理障害の発生後にデータの回復を行うことをデータリカバリといいます。データリカバリの方法は、対象となるデータやアプリケーション機能の仕様によって異なるため、障害ごとに個別の調査方法、分析方法、回復方法などを検討する必要がありますが、既知の障害と未知の障害で大きく対応フローが異なります（図4）。
図4 障害対応フロー未知の障害は既知の障害に比べて回復に至るまでのステップが多く、データリカバリにより多くの時間を必要とします。データリカバリを迅速に行うためには、できる限り既知の障害として対処できることが望ましいといえます。
とはいえ、少なからず未知の障害は発生してしまいます。そこで、障害発生から問題解決までのすべての作業を網羅した障害対応フロー、障害対応手順をあらかじめ整備しておくことで作業品質を安定させ、作業時間を短縮できます。このフローには障害個別となるデータリカバリ作業そのものは含めませんが、一度対応した未知の障害を次回から既知の障害として対応していくナレッジ化の仕組みを含めておきましょう。
Point
障害対応フロー作成時の注意点
- 障害時の関係各所へ連絡方法、連絡タイミングを明記する
- フローの判断ポイントには、「判断基準」を明確に定義する
- 各作業用には「チェックリスト」と「作業手順」を整備する
コラム Oracle 10gのフラッシュバック機能
Oracle 10gの新機能であるフラッシュバックは、論理障害の調査や対応のために新たに用意された非常に便利な機能です。
フラッシュバックには、主に調査に利用する参照系と、対応の検証や実施に利用する更新系の機能があり、参照系の行履歴フラッシュバックはテーブルの更新履歴を参照して、どの時点でデータが異常になったのかを追跡調査できます。同じく参照系のトランザクション履歴フラッシュバックは、過去の特定トランザクションのREDO情報を取得して、その特定トランザクションの結果だけを取り消すようなデータリカバリが可能です。
また、更新系のフラッシュバックではデータベースのリストア／リカバリなしに、データベースを過去の状態に戻すことができるため、管理者が作業ミスをしても作業前バックアップのリストアは不要になりました。これも作業時間の短縮という点で非常に有用です。
このように便利なフラッシュバック機能ですが、フラッシュバックに割り当てられるストレージ容量によって巻き戻せる期間が決まるため、過去までさかのぼって論理障害を追跡するには相応のストレージを用意する必要があります。
| 機能名 | 機能詳細 | 論理障害における用途 | 操作 |
|---|---|---|---|
| フラッシュバッククエリ | SELECT文にAS OF句を付加することで、過去の特定時点のクエリ結果を取得できる | 論理障害時、どの時点までデータが正常だったのか、過去のクエリ結果を取得しながら調査できる | 参照 |
| 行履歴フラッシュバック | SELECT文にVERSIONS BETWEEN句を付加することで、テーブルの行データがいつどのように変更されたのか、更新履歴を取得できる | 論理障害時、行の更新履歴を参照することでどの時点でデータが異常になったのか、特定できる | 参照 |
| トランザクション履歴フラッシュバック | 特定のトランザクションで発行されたSQLとそれを元に戻すSQL文を取得できる | 論理障害を引き起こしたトランザクションを特定し、元に戻すSQL文を取得すれば、特定トランザクションのみを取り消し、データを正常に戻すことができる | 参照 |
| フラッシュバックドロップ | 削除した表（DROP TABLE）を元に戻すことができる | 管理者が誤ってテーブルを削除してしまった場合に、データベースリカバリ不要で元に戻すことができる | 更新 |
| フラッシュバックテーブル | テーブルの状態を任意の時点に戻すことができる | 誤ったテーブル操作をしてしまった場合に、リストアを行わずに作業前の状態に戻すことができる | 更新 |
| フラッシュバックデータベース | データベース全体の状態を任意の時点に戻すことができる | データベースに対して誤った操作を行ってしまった場合に、リストアを行わずに作業前の状態に戻すことができる | 更新 |
| 表3 Oracle 10gのフラッシュバック機能 | |||
まとめ
今回はデータベース運用設計の障害対策・障害回復設計から、論理障害を取り上げました。論理障害を予防するにはシステム設計、運用設計の段階で前もって対策を考え、フールプルーフやバリデーションチェックを組み込んでおくことが必要ですが、すべてを事前にやりきるのは困難です。そのため、システムの運用開始後も継続して障害対応をメンテナンスし、充実させていく仕組みを保守運用作業の中に用意しておくことが重要です。
論理障害は、物理障害のように冗長構成にしてハードウェア費用を積むのと違って、費用の見積もりが難しいですが、ぜひ設計フェイズで十分な検討を行って安定したシステムを構築してください。
連載のまとめ
これまで全6回の連載を通して、開発現場の視点からデータベースエンジニアの必須知識を紹介してきました。何か1つでも皆さんにとって新しい発見がありましたら筆者として幸いです。
データベースエンジニアへのキャリアパスは、プログラマとしてSQLを書くところから入り、データ設計、業務設計を経てデータ管理者（DA）になるケースや、オペレータとして保守運用から入り、データベース設計・実装のスキルを高めてデータベース管理者（DBA）へステップアップしていくなど、いろいろな道があります。
共通していえることは、上流工程になるほど必要員数が少なく、実際の作業にかかわれるチャンスが少ないということです。チャンスを与えられるのを待っている人はいつまでたっても成長できません。いまの場所でできることをやり、レディの状態になっている人だけが、少ないチャンスを拾うことができます。ぜひ自ら道を切り開いていってください。（連載完結）
筆者プロフィール
アクセンチュアから生まれた、企業改革のためのシステム開発を手掛けるエンジニア集団。安間裕が代表取締役社長を務める。下平浩由はネットワーク、データベースなどのインフラ／ミドルウェアに精通したシニア・システム・アナリスト。ネットワークエンジニア、Javaシステム開発者を経て、現在はパッケージシステムの分野でSAPの導入に携わっている。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。