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