| Oracle® Database 2日でデータ・ウェアハウス・ガイド 11g リリース2(11.2) B56298-04 |
|
 前 |
 次 |
この章で説明する、データ・ウェアハウスのバックアップおよびリカバリに関する考慮事項には、次の内容が含まれます。
バックアップおよびリカバリは、管理者にとって最も重要なタスクであり、データ・ウェアハウスについても同様のことが言えます。ただし、データ・ウェアハウスはデータベースのサイズが大きいため、管理者にとってはバックアップおよびリカバリに関する新たな課題が浮上することになります。
データ・ウェアハウスは、無数のリソースからデータが取得されるという点において特徴的で、データベースに挿入される前に変換されますが、これは主にデータ・ウェアハウスが非常に大規模になるためです。大規模なデータ・ウェアハウスのリカバリ管理は大変なタスクで、従来のOLTPのバックアップ計画およびリカバリ計画では、データ・ウェアハウスの要件を満たさない場合があります。
データ・ウェアハウスとOLTPシステムの相違点は次のとおりです。
通常、データ・ウェアハウスのサイズははるかに大規模です。
データ・ウェアハウスは、運用システムとは異なる可用性の要件を備えています。ビジネスにおける決断でも、データ・ウェアハウスからの情報に依存し、たとえばサービス・デスクが操作できないような状況では、事態はさらに悪化します。また、データ・ウェアハウスのサイズのため、一定水準のデータ・ウェアハウスの可用性を保証するには非常に高いコストがかかります。
データ・ウェアハウスは、通常、抽出、変換およびロード(ETL)と呼ばれるより優れた制御のプロセスを介して移入されます。この結果、データ・ウェアハウス内の更新は正確に把握され、データ・ソースからの再生成が可能です。
データ・ウェアハウスには、一般的に、大抵の場合は変更されることがない履歴データが多く格納されます。変更されないデータは、1回のみバックアップする必要があります。
システム設計の一部としてバックアップ計画を計画し、バックアップする対象およびバックアップする頻度を考慮する必要があります。バックアップ設計で最も重要な変数は、バックアップまたはリカバリの実行に使用可能なリソースの量とリカバリ時間目標(システム全体またはシステムの一部の使用不可能な状態の許容時間)です。
バックアップおよびリカバリ計画を計画する場合は、NOLOGGING操作を考慮する必要があります。バックアップをリストアしてアーカイブ・ログから変更を適用する従来のリカバリは、NOLOGGING操作に適用されません。NOLOGGING操作により操作されたデータに依存する操作は失敗します。バックアップおよびリカバリ計画を設計する場合は、NOLOGGING操作を考慮する必要があります。
NOLOGGING操作が行われている場合は、バックアップを作成することはありません。
次の2つの計画のうち1つを計画するか、または2つの計画の組合せを計画します。
ETL計画
リカバリできないトランザクションを含まないバックアップをリカバリし、バックアップと失敗の間で行われたETLをリプレイします。
増分バックアップ計画
その他のリカバリできないトランザクションが行われた後、すぐにバックアップを実行します。変更済データ・ブロックに基づいた増分バックアップを有効にするトラッキング・ファイル機能が提供されます。RMANによりトラッキング・ファイル機能が利用されます。
バックアップおよびリカバリ計画を考案することは、大変なタスクです。数百GBの保護対象のデータを所有していて失敗した場合にリカバリが必要である場合は、計画は非常に複雑になります。
次のベスト・プラクティスにより、ウェアハウスのバックアップおよびリカバリ計画の実装をサポートします。
アーカイブREDOログは、データベースへの変更の記録であるため、データを失うことがまったく許されない場合のリカバリに非常に重要です。Oracle Databaseは、次の2つのモードのいずれかで実行できます。
ARCHIVELOG: Oracle Databaseでは、再利用される前に満杯になったオンラインのREDOログ・ファイルがアーカイブされます。
NOARCHIVELOG: Oracle Databaseでは、再利用される前に満杯になったオンラインのREDOログ・ファイルがアーカイブされません。
ARCHIVELOGモードでデータベースを実行すると、次の利点があります。
データベースはインスタンス障害およびメディア障害の両方から完全にリカバリされます。
データベースを開いて使用可能な状態で、ユーザーはバックアップを実行できます。
Oracle Databaseにより、多重化されたアーカイブ・ログによるそのアーカイブ・ログ上の単一点障害の回避がサポートされます。
ユーザーは、表領域のPoint-in-Timeリカバリ(TSPITR)の実行機能のようなより多くのリカバリ・オプションを使用できます。
アーカイブREDOログは、プライマリ・データベースのコピーであるフィジカル・スタンバイ・データベースに転送および適用できます。
データベースはインスタンス障害およびメディア障害の両方から完全にリカバリされます。
NOARCHIVELOGモードでデータベースを実行すると、次の結果が得られます。
停止後、データベースが完全に閉じられた状態で、ユーザーはデータベースのバックアップのみ実行できます。
最後のバックアップ後はすべてのトランザクションの損失の原因となるため、通常、メディア・リカバリ・オプションのみがデータベース全体をリストアします。
データベースが開いている間、または閉じている間でもOracle Databaseのバックアップは作成できます。データベースの計画停止時間は業務を混乱させ、特に複数のタイムゾーンにいるユーザーを最長24時間サポートする世界規模の企業では顕著です。このような場合は、データベースへの割込みを最小化するようにバックアップ計画を設計することが重要です。
業種によっては、停止時間に余裕がある企業もあります。ビジネス計画全体で、停止時間は最小限またはまったくない状態が必要とされる場合は、バックアップ計画にオンライン・バックアップを実装する必要があります。データベースは、バックアップのために停止する必要がありません。オンライン・バックアップでは、データベースをARCHIVELOGモードにする必要があります。
ARCHIVELOGモードを使用しない理由はありません。データ・ウェアハウス(および極めて重要なデータベース)では、ARCHIVELOGモードを使用してください。データ・ウェアハウスのサイズ(およびデータ・ウェアハウスのバックアップにかかる時間)を考慮すると、データ・ウェアハウスのオフライン・バックアップは現実的ではありません(NOARCHIVELOGモードを使用する場合は、そのオフライン・バックアップが必要になります)。
大規模なデータ・ウェアハウスでは、大量のデータ変更によって大量のログ・ファイルが生成される可能性があります。この数多くのアーカイブ・ログ・ファイルを管理できるようにするため、RMANには、アーカイブ時にログ・ファイルを圧縮するオプションがあります。アーカイブ処理により、より多くのアーカイブ・ログをディスク上に保存し、リカバリ時に高速にアクセスできるようになります。
要約すると、ベスト・プラクティスは、データベースをARCHIVELOGモードにしてオンライン・バックアップのオプションとPoint-in-Timeリカバリのオプションを使用可能にすることです。
Recovery Manager(RMAN)を採用する理由は多数あります。RMANをバックアップおよびリカバリ計画に統合する理由のいくつかは、次の項目が提供されるからです。
拡張性の高いレポート
増分バックアップ
停止時間のないバックアップ
バックアップおよびリストアの検証
バックアップおよびリストアの最適化
メディア・マネージャとの簡単な統合
ブロック・メディア・リカバリ
アーカイブ・ログの検証および管理
破損ブロックの検出
データ・ウェアハウスが直面する最大の問題の1つは、一般的なデータ・ウェアハウスの規模です。強力なバックアップのハードウェアを使用しても、バックアップに数時間かかります。したがって、バックアップするデータの量の最小化を考慮することは、バックアップのパフォーマンスの向上のために重要なことの1つです。読取り専用の表領域は、データ・ウェアハウス内にバックアップするデータの量を削減するための最も簡単なメカニズムです。
読取り専用の表領域の利点は、データのバックアップが1回である点です。データ・ウェアハウスに5年間の履歴データが含まれる場合は、データの最初の4年間は読取り専用にできます。理論上は、データベースの通常のバックアップでデータの20%のみがバックアップされます。これにより、データ・ウェアハウスのバックアップに必要な時間を大幅に短縮できます。
ほとんどのデータ・ウェアハウスでは、時間でレンジ・パーティション化された表にデータが格納されます。通常のデータ・ウェアハウスでは、30日間から1年間までの範囲の期間で、データがアクティブです。この期間中は、履歴データを更新でき、また変更できます(たとえば、小売業者が購入日後の30日間までは返品を受け入れる場合は、売上データの記録をこの期間中に変更できます)。ただし、データが特定の日に到達すると、そのデータは静的であるとみなされます。
パーティション化を利用すると、ユーザーは読取り専用のデータの静的な部分を作成できます。RMANにより、読取り専用のパーティションまたは表ではなく、読取り専用の表領域がサポートされます。読取り専用の表領域を利用してバックアップ・ウィンドウを削減するには、読取り専用の表領域の定数データ・パーティションの格納計画を考案する必要があります。ローリング・ウィンドウを実装する2つの計画は次のとおりです。
データが静的とみなされるようになった時点で、読取り/書込み表領域から読取り専用表領域にパーティションを移動するための、定期的に実行するプロセスを実装します。
この場合のベスト・プラクティスは、データベースをARCHIVELOGモードにしてオンライン・バックアップおよびPoint-in-Timeリカバリのオプションを使用可能にすることです。
各表領域に少数のパーティションを持つ一連の表領域を作成し、その表領域内のデータが年数を重ねるにつれて定期的に1つの表領域を読取り/書込み両用から読取り専用に変更します。
1つ考慮する必要があるのは、データのバックアップはリカバリ・プロセスの半分にすぎないということです。テープのシステムを構成する場合、4時間でデータ・ウェアハウスの読取り/書込み両用の部分をバックアップでき、データベースの80%が読取り専用であるときに完全なリカバリが必要な場合は、必然的にテープのシステムではデータベースをリカバリするために20時間かかります。
要約すると、ベスト・プラクティスは、静的表および静的パーティションを読取り専用の表領域に配置することです。読取り専用の表領域は1回バックアップされます。
一般的に、データ・ウェアハウスの最優先事項はパフォーマンスです。データ・ウェアハウスにより、オンラインのユーザーに快適な問合せのパフォーマンスが提供される必要があるだけでなく、大量のデータを最短時間内にロードするために、ETLプロセス中、データ・ウェアハウスは効率的である必要があります。
データ・ウェアハウスにより利用される共通の最適化の1つは、NOLOGGINGモードを使用して大量データ操作を実行することです。NOLOGGINGモードをサポートするデータベース操作は、直接パス・ロードおよび直接パス・インサート、索引の作成および表の作成です。1つの操作がNOLOGGINGモードで実行される場合は、データはREDOログに書き込まれません(より正確に言うと、サイズの小さいメタデータのセットのみREDOログに書き込まれます)。このモードは、データ・ウェアハウスの広範囲で使用され、大量データ操作のパフォーマンスを50%まで改善できます。
ただし、リカバリをサポートするために必要なデータがログ・ファイルに書き込まれることはないので、従来のバックアップ・メカニズムを使用してNOLOGGING操作をリカバリすることはできなくなります。さらに、NOLOGGING操作が発生したデータに対する後続の操作は、たとえその操作がNOLOGGINGモードを使用していなかったとしてもリカバリされません。NOLOGGING操作により提供されるパフォーマンスの向上のため、データ・ウェアハウスでは、一般的にETLプロセスでNOLOGGINGモードを使用することをお薦めします。
バックアップおよびリカバリ計画を考案する場合は、NOLOGGING操作の存在を考慮する必要があります。データベースがNOLOGGING操作に依存する場合、ログ・ファイルによりNOLOGGING操作はリカバリできないので、最新のテープ・バックアップからリカバリして、アーカイブ・ログ・ファイルを適用する従来のリカバリ計画は適用できなくなります。
NOLOGGING操作が行われているときは、バックアップを行わないでください。このルールは、今のところ強制的には適用されないため、NOLOGGING操作とバックアップ操作が重ならないように、バックアップ・ジョブとETLジョブをスケジュールする必要があります。
NOLOGGING操作が存在するバックアップおよびリカバリには、2つのアプローチがあります。ETLバックアップまたは増分バックアップです。データ・ウェアハウス内でNOLOGGING操作を使用していない場合は、次のオプションのいずれも選択する必要はありません。アーカイブ・ログを使用してデータ・ウェアハウスをリカバリできます。ただし次のオプションは、リカバリの場合のアーカイブ・ログベースのアプローチにおいていくつかのパフォーマンスの面で優れています。
ETLプロセスでは、データをデータ・ウェアハウスにロード(再ロード)するためにいくつかのOracle Databaseの機能またはツール、およびメソッドの組合せを使用します。これらの機能またはツールの構成要素は次のとおりです。
トランスポータブル表領域。Oracleトランスポータブル表領域機能により、ユーザーはOracleデータベース間で表領域を迅速に移動することができます。この方法は、データベース間で大量データを移動するのに最も効率的です。Oracle Databaseにより、プラットフォーム間で表領域を転送できる機能が提供されます。ソース・プラットフォームとターゲット・プラットフォームが異なるエンディアンネスである場合、RMANによりターゲット・フォーマットに転送されている表領域が変換されます。
SQL*Loader。SQL*Loaderにより、外部フラット・ファイルから1つのOracleデータベース上の複数の表にデータがロードされます。強力なデータ解析エンジンによって、あらゆるデータ形式のデータ・ファイルに対応できます。
データ・ポンプ(エクスポート/インポート)。Oracle Databaseにより、Oracle Data Pumpテクノロジが提供され、これにより1つのデータベースから他のデータベースにデータおよびメタデータを高速で移動することが可能です。このテクノロジは、データ移動ユーティリティであるデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポートの基本となります。
外部表。外部表機能は、既存のSQL*Loader機能を補足する機能です。この機能により、データベース内の表にあるデータと同様に、外部ソースのデータにアクセスできるようになります。
アプローチの1つは、定期的にデータベースのバックアップをして、その週全体のETLプロセスを再作成するために必要なデータファイルを保存することです。リカバリが必要な場合、データ・ウェアハウスは最新のバックアップからリカバリされます。次に、従来のリカバリのシナリオで行われていたようにアーカイブREDOログを適用してロールフォワードを行うかわりに、データ・ウェアハウスはETLプロセスをリプレイすることでロールフォワードを行います。このパラダイムを使用する場合は、ETLプロセスを簡単にリプレイできることが前提となり、通常は各ETLプロセスの抽出ファイルのセットの保存も含まれます(たとえば不正なデータ送信の修復の必要があるかどうかを識別できるように、データ・ウェアハウスの多くはすでにベスト・プラクティスとしてこれを行っています)。
このアプローチのサンプル実装は、毎週末データ・ウェアハウスのバックアップを作成し、毎晩のETLプロセスをサポートするために必要なファイルを保存することです。したがって、データベースをリカバリするためには最大7日間分のETLプロセスが再適用されることになります。データ・ウェアハウスのリカバリにかかる時間は、テープからのリカバリ・スピードおよび以前のETL実行からのパフォーマンス・データに基づいて予測できます。
基本的にデータ・ウェアハウス管理者は、NOLOGGING操作を介してETLプロセスでのより高いパフォーマンスを獲得しており、その際は多少複雑であまり自動化されていないリカバリ・プロセスを通過する必要があります。データ・ウェアハウス管理者の多くは、これを価値のある代償だと理解しています。
このアプローチの弱点は、データ・ウェアハウスで発生した関連する変更のすべてを追跡する負荷がデータ・ウェアハウス管理者にかかるということです。このアプローチでは、ETLプロセスの範囲に入らない変更は取得されません。たとえば、いくつかのデータ・ウェアハウスでは、エンドユーザーが所有する表およびデータ構造を作成します。それらの変更はリカバリ時に失われます。この制限はエンドユーザーに伝達される必要があります。かわりに、管理者がユーザーに対して、すべてのプライベート・データベース・オブジェクトを別の表領域に作成するように指示し、リカバリ時には、従来のリカバリでその表領域をリカバリし、残りのデータベースはETLプロセスをリプレイすることでリカバリすることもできます。
要約すると、ベスト・プラクティスは、リカバリできない(NOLOGGING)トランザクションを含まないバックアップをリストアすることです。次にETLプロセスをリプレイしてデータを再ロードします。
ブロック変更トラッキング・ファイルのサイズは次の項目に比例します。
データベース・サイズ(バイト)。ブロック変更トラッキング・ファイルには、データベース内のデータファイル・ブロックを表すデータが含まれます。データはおよそデータベースのサイズ全体の250000分の1です。
有効なスレッドの数。すべてのOracle Real Application Cluster(Oracle RAC)インスタンスは、同一のブロック変更トラッキング・ファイルにアクセスできます。ただし、インスタンスにより、ロックまたはノード間のブロック・スワッピングなしでトラッキング・ファイルの異なる領域が更新されます。個別のインスタンスに対してではなく、データベース全体に対してブロック変更トラッキング・ファイルを有効化できます。
変更済ブロックのメタデータ。ブロック変更トラッキング・ファイルは最後のバックアップ以来の変更に加えて、前のバックアップ間のすべての変更の記録を保持しています。トラッキング・ファイルは、最大で8個のバックアップの変更履歴を保持します。トラッキング・ファイルに8個のバックアップの変更履歴が含まれる場合は、Oracle Databaseにより最も古い変更履歴情報が上書きされます。
たとえばスレッドを1つのみ所有し、RMANリポジトリに8個のバックアップを保持する500GBのデータベースの場合は、20MBのブロック変更トラッキング・ファイルが必要です。
((Threads * 2) + number of old backups) * (database size in bytes) ------------------------------------------------------------------ = 20MB 250000
NOLOGGING操作が存在する、より自動化されたバックアップおよびリカバリ計画では、RMANの増分バックアップ機能を利用します。RMANが最初にリリースされて以来、増分バックアップはRMANの一部を構成しています。増分バックアップを使用すると、前回のバックアップ以降に変更されたブロックのみをバックアップすることができます。データファイルの増分バックアップでは、データファイルにあるすべての使用済ブロックのバックアップが要求されるのではなく、データの変更がブロックごとに取得されます。結果として取得されるバックアップのセットは、データファイル内のすべてのブロックが変更されないのであれば、通常すべてのデータファイルのバックアップより小さくて効率的です。
Oracle Databaseには、変更トラッキング・ファイル機能を実装して増分を高速化する機能があります。ブロック変更トラッキングを有効にする場合は、Oracle Databaseにより、すべてのデータベースの変更の物理的な場所が追跡されます。RMANにより自動的に変更トラッキング・ファイルが使用され、増分バックアップ中に読み込む必要のあるブロックが決定されて、バックアップするブロックに直接アクセスします。
このアプローチを使用する通常のバックアップおよびリカバリ計画は、毎週末データ・ウェアハウスをバックアップし、ETLプロセスが完了した後は毎晩データ・ウェアハウスの増分バックアップを取得します。増分バックアップは、従来のバックアップと同様に、NOLOGGING操作と同時に実行しないように注意してください。データ・ウェアハウスをリカバリするために、データベースのバックアップはリストアされ、毎晩の増分バックアップは再適用されます。NOLOGGING操作はアーカイブ・ログに取得されていませんが、NOLOGGING操作からのデータは増分バックアップ内にあります。さらに、前のアプローチとは異なり、このバックアップおよびリカバリ計画は、RMANを使用して完全に管理できます。
ETLをリプレイするアプローチおよび増分バックアップのアプローチの両方とも、多くのNOLOGGING操作で構成されているワークロードであるデータベースの効率的で安全なバックアップおよびリカバリのソリューションとしてお薦めします。バックアップおよびリカバリ計画においてNOLOGGING操作を考慮することが最も重要です。
要約すると、ベスト・プラクティスは、NOLOGGING操作のためオブジェクトをリカバリできない状態にしておくダイレクト・ロードの後、ブロック変更トラッキング機能を実装して増分バックアップを作成することです。
データベース内の各表領域を同様に処理することが最も単純なバックアップおよびリカバリのシナリオですが、Oracle Databaseでは、必要に応じて、バックアップおよびリカバリのシナリオを表領域ごとに考案できるような柔軟性を提供しています。
バックアップおよびリカバリという観点で見ると、データ・ウェアハウス内のすべての表領域が同等に重要だということはありません。この情報に基づいて、より効率的なバックアップおよびリカバリ計画を必要に応じて考案できます。バックアップおよびリカバリの基本粒度は表領域なので、異なる表領域には異なるバックアップおよびリカバリ計画が存在する可能性があります。最も基本的なレベルでは、一時表領域がバックアップされることはありません(RMANにより規定されるルール)。
さらに、いくつかのデータ・ウェアハウスでは、一時表領域ではないにもかかわらず、エンドユーザーが一時表領域と増分の結果を格納するスクラッチ領域専用の表領域であるために、一時表領域として機能している表領域があります。ビジネス要件によっては、これらの表領域をバックアップおよびリストアする必要はありません。かわりに、これらの表領域が失われた場合、ユーザーは所有するデータ・オブジェクトを再作成します。
データ・ウェアハウスの多くは、その他のデータより重要な一部データを持っています。たとえば、データ・ウェアハウス内の売上データは非常に重要で、リカバリの段階では、このデータはできるだけ早くオンラインにする必要があります。同一のデータ・ウェアハウス内では、企業のWebサイトからのクリック・ストリーム・データを格納している表の重要度がかなり低いことがあります。ビジネスを継続する上で、このデータが数日間オフラインになること、またはデータベース・ファイル損失時にクリック・ストリーム・データが数日間失われることは許容範囲内の場合があります。このシナリオでは、売上データを含む表領域は頻繁にバックアップする必要があり、一方でクリック・ストリーム・データを含む表領域は毎週1回または2回バックアップする必要があります。
