バックアップとリカバリーの計画の作成

データベース・リカバリー計画では、 データベース・リカバリーのために必要になった時点ですべての情報を使用できるようにしておく必要があります。 データベースのバックアップを取るための定期的なスケジュールを組み込み、パーティション・データベース環境の場合はシステム規模の変更時 (データベース・パーティション・サーバーまたはノードの追加やドロップによる) のバックアップも組み込む必要があります。 またコマンド・スクリプト、アプリケーション、ユーザー定義関数 (UDF)、 オペレーティング・システム・ライブラリー中のストアード・プロシージャー・コード、 およびロード・コピーのリカバリー手順も計画全体に組み込む必要があります。

以下に、各種のリカバリー方式について説明し、業務環境に最適なリカバリー方式を判別する方法を示します。

データベース・バックアップ の概念は、 他のデータ・バックアップの概念と同じです。 つまり、オリジナルで障害または損傷が起こる場合のために、 データのコピーを取り、異なるメディアに保管します。 一番単純なバックアップでは、 データベースをシャットダウンして、 トランザクションがこれ以上生じないようにしてから、 単純にそのバックアップを取ります。 その後何らかの原因でデータベースが損傷したり破壊されたりした場合に、そのデータベースを再作成することができます。

このデータベースの再作成のことをリカバリー といいます。 バージョン・リカバリーは、以前のバージョンのデータベースの修復であり、バックアップ操作で作成されたイメージを使用して行われます。 ロールフォワード・リカバリー では、 データベースまたは表スペースのバックアップ・イメージがリストアされた後で、 データベース・ログ・ファイル中に記録されているトランザクションが再度適用されます。

クラッシュ・リカバリー では、 1 つまたは複数の作業単位 (トランザクション) の一部となるすべての変更内容が完了しコミットされる前に障害が発生すると、 データベースが自動的にリカバリーされます。 これは、未完了のトランザクションをロールバックし、 故障発生時にメモリーに残っていたコミット済みトランザクションを完了することによって行われます。

リカバリー・ログ・ファイルとリカバリー履歴ファイルは、データベースの作成時に自動的に作成されます (図 1)。 消失または損傷したデータをリカバリーする必要がある場合には、それらのログ・ファイルは重要になります。

それぞれのデータベースにはリカバリー・ログ が含まれており、 これはアプリケーションまたはシステム・エラーからリカバリーするときに使用します。 データベース・バックアップと組み合わせて、 これらはデータベースの整合性をエラーが生じた時点までリカバリーするために使用されます。

リカバリー履歴ファイル には、 指定した時点までデータベースのすべてまたは一部をリカバリーする必要のある場合に、 リカバリー・オプションを判別するために使用できるバックアップ情報のサマリーが含まれています。 これは特に、バックアップ操作やリストア操作などのリカバリー関連のイベントを追跡するために使用します。 このファイルは、データベース・ディレクトリーにあります。

表スペース変更ヒストリー・ファイル (これもデータベース・ディレクトリーにある) は、 特定の表スペースのリカバリーにどのログ・ファイルが必要かを判別するために使用できる情報を含んでいます。

リカバリー履歴ファイルや表スペース変更ヒストリー・ファイルは直接変更できません。しかし、PRUNE HISTORY コマンドを使用して、ファイルから (履歴) レコードを削除できます。 さらに、rec_his_retentn データベース構成パラメーターを使用して、 これらの履歴ファイルが保持される日数を指定することもできます。

容易に再作成できるデータは、リカバリー不能データベースに保管できます。 リカバリー不能データベースは、少量のロギングしか行っていないため、ログ・ファイルの管理およびリストア操作後のロールフォワードのより複雑な操作に対応できません。そのため、これには、読み取り専用アプリケーションに使用される外部ソースからのデータや、頻繁に更新されない表を含めます。 logarchmeth1 および logarchmeth2 データベース構成パラメーターが両方とも OFF に設定されている場合、データベースはリカバリー不能 になります。 これは、クラッシュ・リカバリーに必要なログのみ保管されていることを意味します。 これらのログは、アクティブ・ログ と呼ばれ、 現在のトランザクション・データを含んでいます。 オフライン・バックアップによるバージョン・リカバリーとは、基本的にはリカバリー不能データベースのリカバリーを行うことを意味します。 (オフライン・バックアップは、バックアップ操作の進行中は、 他のアプリケーションがこのデータベースを使用できないという意味です。) このようなデータベースは、オフラインでのみリストアできます。 リストアすると、バックアップ・イメージが取られたときの状態に戻ります。ただし、ロールフォワード・リカバリーはサポートされません。

容易に再作成できない データは、 リカバリー可能データベースに保管する必要があります。 これには、ロード後にソースが破棄されるデータ、表の中に手動で入力するデータ、 およびデータベースにロードした後にアプリケーション・プログラムまたはユーザーによって修正されるデータが含まれます。 リカバリー可能データベース では、logarchmeth1 または logarchmeth2 データベース構成パラメーターが OFF 以外の値が設定されたものです。 アクティブ・ログをクラッシュ・リカバリーで使用できますが、 アーカイブ・ログ もあり、 これにはコミット済みトランザクション・データが含まれています。 このようなデータベースは、オフラインでのみリストアできます。 リストアすると、バックアップ・イメージが取られたときの状態に戻ります。 しかし、ロールフォワード・リカバリーによって、アクティブ・ログおよびアーカイブ・ログを使用して、特定の時点またはアクティブ・ログの最後までデータベースをロール・フォワードする (つまり、バックアップ・イメージが取られたときよりも進める) ことができます。

リカバリー可能データベースのバックアップ操作はオフラインでもオンライン でも実行できます (オンラインとは、 バックアップ操作中に他のアプリケーションがそのデータベースに接続できるという意味です)。 オンライン表スペースのリストアおよびロールフォワード操作は、 データベースがリカバリー可能な場合にのみサポートされます。 データベースがリカバリー不能である場合、データベースのリストア操作は、オフラインで実行する必要があります。 オンライン・バックアップを作成している間も、ロールフォワード・リカバリーは、そのバックアップがリストアされた後にすべての 表の変更が取り込まれ、再適用されることを保証します。

リカバリー可能データベースがある場合は、データベース全体の代わりに、 個々の表スペースをバックアップ、 リストア、およびロールフォワードすることができます。 表スペースをオンラインでバックアップするとき、 その表スペースは依然として使用可能であり、 同時に行われる更新がロギングされます。 表スペースに対してオンライン・リストアまたはロールフォワード操作を実行するときは、 表スペース自体は操作が完了するまで使用できませんが、 ユーザーが他の表スペースにアクセスできないということはありません。