バックアップの頻度の決定

データベースのバックアップには時間もシステム・リソースも必要となるため、 リカバリー計画では、定期的なバックアップ操作も含める必要があります。 全データベースのフル・バックアップと増分バックアップ操作を組み合わせて計画に含めることができます。 また、バックアップを実行する頻度およびタイプもデータベースのリカバリー時間に影響します。

ロールフォワード・リカバリーを可能にするためにログをアーカイブしている場合でも、 データベースのフル・バックアップを定期的にとるようにしてください。 データベースをリカバリーするには、すべての表スペース・バックアップ・イメージを含む完全なデータベース・バックアップ・イメージを使用するか、または選択した表スペース・イメージを使用してデータベースを再構築できます。 表スペースのバックアップ・イメージは、単独のディスク障害やアプリケーション・エラーからリカバリーする場合にも有効です。 パーティション・データベース環境では、失敗したデータベース・パーティション上にある表スペースのみをリストアすれば十分です。 すべての表スペースまたはすべてのデータベース・パーティションをリストアする必要はありません。

表スペース・イメージからデータベースを再構築できるようになったので、データベース・リカバリーの際に完全なデータベース・バックアップは必要なくなりましたが、依然として時折データベースのフルバックアップを取ることは良い習慣です。

また、バックアップ・イメージおよびログを上書きせずに、安全を考慮してデータベースのフル・バックアップ・イメージおよび関連ログを 2 世代以上保管することも考慮してください。

更新頻度の高いデータベースのリカバリーとロールフォワードにおいて、アーカイブ・ログを適用するために要する時間が主要な関心事である場合は、頻繁にデータベースのバックアップをとることによるコストを検討してください。 バックアップの頻度を上げると、 ロールフォワード時に適用する必要のあるアーカイブ・ログの数を減らすことができます。

オンライン・バックアップおよびオフライン・バックアップの考慮事項

バックアップ操作は、データベースがオンラインでも オフラインでも開始できます。 オンラインの場合、他のアプリケーションまたはプロセスは、 バックアップ操作の実行中もデータベースに接続したり、 データの読み取りや修正を行うことができます。 バックアップ操作がオフラインで実行される場合、 他のアプリケーションはデータベースに接続できません。

データベースが使用できなくなる時間を短くするには、 オンライン・バックアップ操作の使用が考えられます。 ロールフォワード・リカバリーが可能である場合にのみ、オンライン・バックアップ操作がサポートされます。 ロールフォワード・リカバリーを使用でき、リカバリー・ログの完全セットがある場合は、必要が生じたときにデータベースをリストアできます。 バックアップ操作が実行されていた時間に関係しているログがある場合のみ、 オンライン・バックアップ・イメージをリカバリーに使用できます。

オフライン・バックアップ操作は、データ・ファイルの競合がないため、オンライン・バックアップ操作より高速です。

選択的表スペース・バックアップの考慮事項

バックアップ・ユーティリティーを使用して、選択した表スペースのみをバックアップできます。 DMS 表スペースを使用すると、その表スペースに異なったタイプのデータを格納でき、 バックアップ操作に必要な時間を短縮できます。 表データをある表スペースに保持し、ロング・フィールドおよび LOB データを別の表スペースに保持し、索引をさらに別の表スペースに保持することができます。 データを複数の表スペースに分けておくと、ディスクに障害が発生した場合でも、その障害の影響は 1 つの表スペースのみに限定される可能性が高まります。 これらの表スペースの 1 つをリストアまたはロールフォワードするために要する時間は、 すべてのデータを含む単一の表スペースをリストアする時間よりも短くてすみます。

さらに、異なる表スペースへの変更が同じものでないなら、 それらの表スペースを別の機会にバックアップすることにより時間を節約することもできます。 それで、ロング・フィールドまたは LOB データが他のデータほど頻繁に変更されない場合には、 それらの表スペースのバックアップ頻度を少なくすることができます。 ロング・フィールドおよび LOB データがリカバリーに必要ではない場合、 そのデータを含む表スペースをバックアップしないことも考慮できます。 LOB データが別のソースから再作成可能である場合は、 LOB 列を含む表の作成または変更時には、NOT LOGGED オプションを選択してください。

長形式フィールド・データ、LOB データ、および索引を別々の表スペースに保持し、かつこれらのバックアップを同時に取らない場合には、以下の点を考慮してください。表データ全体が含まれていない表スペースをバックアップする場合、その表スペースに対してポイント・イン・タイム指定ロールフォワード・リカバリーは実行できません。 表に関する任意のデータ・タイプが含まれているすべての表スペースは、 同じ時点まで同時にロールフォワードする必要があります。

表の再編成の考慮事項

表を再編成する場合、 操作完了後に関連した表スペースのバックアップを作成する必要があります。 これにより、表スペースをリストアしなければならない場合でも、データ再編成中のロールフォワードを実行しなくても済みます。

表スペースの変更状況の考慮事項

表スペースをバックアップするかどうかについて、表スペースの変更状況を確認することにより、具体的な情報に基づいて判断を下すこともできます。 db2pd -tablespaces trackmodstate コマンドおよび tbsp_trackmode_state モニター・エレメントは、最後または次のバックアップに関する表スペースの状況を表示します。 この情報を利用して、表スペースが変更されたかどうかや、表スペースをバックアップする必要があるかどうかを判断できます。

データベース・リカバリー時間の考慮事項

データベースのリカバリーに必要な時間は、次の 2 つの部分で構成されます。
  • バックアップのリストアを完了するために必要な時間。
  • データベースのフォワード・リカバリーが使用可能な場合に、ロールフォワード操作時にログを適用するために必要な時間。
リカバリー計画を立てるときは、これらのリカバリーに必要な時間や作業と、それらが業務操作に与える影響を考慮してください。 全般的なリカバリー計画をテストすることで、データベースをリカバリーするために必要な時間が、 業務上の要件を考慮して正当かどうかを判別することができます。 各テストを実施した後、バックアップを作成する頻度を増やすこともできます。 リカバリー計画の一部としてロールフォワード・リカバリーを実行する場合は、 このバックアップ頻度の増加により、バックアップ間にアーカイブされるログの数が減少し、 その結果、リストア操作後にデータベースをロールフォワードするための時間が短縮されます。