バックアップとリカバリは、DBAが業務データを保護するために行う最も重要で不可欠なジョブの1つです。データ・ストアが毎年増大するにつれ、DBAは、クリティカル・データをバックアップして、ビジネス・ニーズに合うように迅速かつ容易にリカバリできるように保証することを常に求められます。大規模データベースは、その大きさとデータが非常に多くのリソースに由来するという点が独特です。OLTPとデータウェアハウスにはそれぞれの特性があります。通常、大規模OLTPシステムでの可用性の考慮事項は、小規模OLTPシステムの場合の考慮事項と変わりません。停止可能な時間が同じであれば、大規模OLTPシステムは小規模OLTPシステムよりも多くのハードウェア・リソースが必要になります。
この章では、VLDB(大規模データベース)のための効果的なバックアップとリカバリの戦略を提案します。この戦略は、OLTPシステムとは異なるデータ・ウェアハウスの特性を利用して、バックアップとリカバリをサポートするために必要なリソースを全面的に削減します。この章の内容は次のとおりです。
データ・ウェアハウスは、分析や意思決定をサポートするために設計されたシステムです。一般的な企業では、数百または数千名のユーザーが業務の理解に役立つ情報を得たり、適切な決定を行ったりするために、データ・ウェアハウスを利用しています。したがって、可用性はデータ・ウェアハウスの重要な要件です。この章では、データ・ウェアハウスの可用性の重要なポイントである、データ損失後のデータ・リカバリについて説明します。
バックアップとリカバリの技法を詳しく調べる前に、データ・ウェアハウスのバックアップとリカバリのための固有の技法について理解する必要があります。特に、データ・ウェアハウスのバックアップとリカバリの戦略は、その他のデータベース・システムと同じではならないのかという当然の疑問について説明します。
DBAは、データ・ウェアハウスのバックアップとリカバリの作業を始めるにあたり、OLTPシステムで使用されるのと同じ技法を適用します。つまり、重要性と変更の頻度に応じてデータの優先順位を付けて、保護すべき情報、およびメディア・リカバリが必要になったときに迅速にリカバリすべき情報を決定する必要があります。ただし、データ・ウェアハウスに関して通常生じる問題は、100GBのOLTPシステムでは効率がよくコスト効果が高い方法であっても、10TBのデータ・ウェアハウスには適さないということです。バックアップとリカバリの時間は100倍かかり、記憶域も100倍必要になります。
データ・ウェアハウスとOLTPシステムには次のような4つの違いがあり、バックアップとリカバリに大きく影響します。
通常、データ・ウェアハウスはOLTPシステムよりもかなり大規模です。数十TBを超えるデータ・ウェアハウスもまれではなく、最大規模のデータ・ウェアハウスはさらに桁違いの大きさになります。このため、データ・ウェアハウスのバックアップとリカバリではスケーラビリティは特に重要な考慮事項です。
多くの場合、データ・ウェアハウスの可用性要件はOLTPシステムに比べて低くなります。データ・ウェアハウスがミッション・クリティカルな場合、数TBのデータを数時間でリカバリできるようにするためには、一日かけてリカバリする場合よりもかなりのコストがかかります。データ・ウェアハウスの大部分のリカバリを必要とするような障害は発生する可能性が低いため、組織によっては、バックアップ用のハードウェアやストレージにかける多額の支出を節約できるのであれば、1日以上の停止も容認する場合があります。
通常、データ・ウェアハウスは、エンド・ユーザーが自らデータを変更するOLTPシステムとは異なり、ETL(抽出、変換、ロード)という制御プロセスによって更新されます。データ変更が制御プロセスによって行われるため、多くの場合、データ・ウェアハウスの更新はREDOログ以外のソースからも認識でき再現可能です。
データ・ウェアハウスには履歴情報が含まれます。また、データ・ウェアハウスの古いデータの大部分は静的です。たとえば、あるデータ・ウェアハウスでは売上の履歴データが5年分管理されます。最も新しい年のデータは(返品、決算修正などのために)変更される可能性がありますが、以前の4年分のデータは完全に静的です。静的データの利点は、頻繁にバックアップを行う必要がないことです。
これらの4つの特性は、データ・ウェアハウスに最適なバックアップおよびリカバリ戦略を検討する際の重要な考慮事項です。
一般的に、バックアップとリカバリは、データ損失に対するデータベースの保護や、なんらかのデータ損失の後でのデータベースの再構築に関連する様々な戦略や手順を意味します。バックアップとはデータのかわりとなるコピーです。このコピーには、データベースの重要な部分(制御ファイル、アーカイブREDOログ、データファイルなど)を含めることができます。バックアップは、元のデータをリストアする手段を提供することにより、アプリケーション・エラーからデータを保護し、予期しないデータ損失に対する安全装置として機能します。
バックアップおよびリカバリ戦略を本格的に検討する前に、バックアップとリカバリの操作に関連する物理データ構造を確認します。Oracleデータベースを構成するファイルやその他の構造は、データを格納し、データを潜在的な障害から保護します。Oracleデータベースのリカバリには次の3つの基本コンポーネントが必要です。
データファイル
REDOログ
制御ファイル
Oracleデータベースは、表領域と呼ばれる1つ以上の論理記憶域単位で構成されます。Oracleデータベースの各表領域は、データファイルという1つ以上のファイルで構成されます。データファイルは、Oracleが稼働しているホスト・オペレーティング・システム上、またはホスト・オペレーティング・システムに接続する物理ファイルです。
データベースのデータは、データファイルにまとめて格納されており、データファイルがデータベースの各表領域を構成します。最も単純なOracleデータベースは、1つの表領域があり、1つのデータファイルが格納されます。データベースのデータファイルのコピーは、すべてのバックアップ戦略に欠かせない部分です。データファイルのサイズが大きいことが、VLDBのバックアップとリカバリにおいて主要な課題になります。
REDOログは、データベースのデータファイルに行われたすべての変更を記録します。REDOログの完全なセットとそれ以前のデータファイルのコピーがあれば、Oracleで、REDOログに記録された変更を再適用して、バックアップ時点から最後のREDOログの終了時点までの任意の時点のデータベースを再作成できます。Oracleデータベースでデータが変更されるたびに、その変更がオンラインREDOログにまず記録されてからデータファイルに適用されます。
Oracleデータベースでは、少なくとも2つのオンラインREDOログ・グループが必要です。各グループには、少なくとも1つのオンラインREDOログ・メンバーつまり1つのREDOログ・ファイルが含まれ、このファイルに変更内容が記録されます。時間隔で、OracleはオンラインREDOログ・グループを入れ替えます。現行オンラインREDOログに変更内容を格納する一方で、使用していないグループはアーカイブREDOログと呼ばれるアーカイブ場所にコピーできます。高可用性を実現するために、本番システムは、常に1グループ当たり複数のオンラインREDOメンバーを使用する必要があります。できればメンバーを異なる記憶域システムに配置することをお薦めします。アーカイブREDOログにはデータファイルのすべての更新記録が含まれるため、アーカイブREDOログの保存がバックアップ戦略の主要な部分です。多くのバックアップ戦略では、長期保管のためにアーカイブREDOログをディスクまたはテープにコピーします。
制御ファイルには、データベースの物理構造とそのステータスの重要なレコードが含まれます。制御ファイルに格納される次のタイプの情報は、バックアップとリカバリに関連します。
クラッシュからリカバリするため、つまりメディア・リカバリを実行するために必要なデータベース情報
データベース構造情報(データファイルの詳細など)
REDOログの詳細
アーカイブREDOレコード
過去のRMANバックアップのレコード
Oracleのデータファイル・リカバリ・プロセスのある部分は、制御ファイルのステータス情報(データベース・チェックポイント、現行オンラインREDOログ・ファイル、データファイルのデータファイル・ヘッダー・チェックポイントなど)によって決まります。制御ファイルが失われると、データ損失からのリカバリがさらに困難になります。最新のデータベース構造変更を保存し、リカバリを容易に行えるように、制御ファイルを定期的にバックアップする必要があります。
バックアップには、物理バックアップと論理バックアップがあります。
物理バックアップは、データベースの格納とリカバリに使用される物理ファイル(データファイル、制御ファイル、アーカイブREDOログなど)のバックアップです。究極的には、すべての物理バックアップは、データベース情報を格納するファイルを別の場所(ディスク上またはテープなどのオフライン・ストレージ上)にコピーすることです。
論理バックアップには、Oracle Data Pump(エクスポートおよびインポート)ユーティリティでデータベースから抽出された論理データ(たとえば、表またはストアド・プロシージャ)が含まれます。データは、Oracleデータベースにインポートできるバイナリ・ファイルに格納されます。
物理バックアップは、すべてのバックアップおよびリカバリ戦略の基盤です。論理バックアップは、多くの状況で物理バックアップの有益な補足情報として使用されますが、物理バックアップがない場合にはデータ損失に対する十分な保護手段にはなりません。
データベースのすべてまたは一部の内容をバックアップから再構築するには、通常は2つの段階があります。まずバックアップからデータファイルのコピーを取り出し、次にバックアップ以降の変更内容をアーカイブREDOログおよびオンラインREDOログからファイルに再適用して、データベースの状態をリカバリ希望の時点に戻します。データファイルまたは制御ファイルをバックアップからリストアするには、テープ、ディスクまたは他のメディアのバックアップ場所からファイルを取得して、Oracle Databaseで使用できるようにします。データファイルをリカバリするには、データファイルをリストアし、データベースのREDOログに記録された変更内容を適用します。データベース全体をリカバリするには、データベースのデータファイルそれぞれについてリカバリを実行します。
Oracleデータベースのバックアップとリカバリを管理するために次のツールが提供されます。各ツールではバックアップを作成するためにいくつかの基本的な方法から選択できます。次の方法があります。
Recovery Manager(RMAN)
RMANを使用すると、すべてのバックアップの多数のメタデータ・レコードと必要なリカバリ関連ファイルがメンテナンスされるため、バックアップ戦略に伴う管理作業が削減されます。リストアおよびリカバリ操作ではRMANがこの情報を使用するため、ユーザーが必要なファイルを特定する必要がなくなります。RMANは、パフォーマンスに優れており、高性能で有益なファイル多重化およびパラレル・ストリームの機能をサポートしています。また、バックアップおよびリストアの際には、物理的な破損および論理的な破損(オプション)についてブロックの検査を行います。
V$BACKUP
ビューを使用するか、Enterprise Managerを介して、バックアップ・アクティビティ・レポートを生成できます。
Oracle Enterprise Manager
Enterprise Managerは、バックアップおよびリカバリ機能としてRecovery Managerを利用するOracleの管理コンソールです。バックアップやリストアのジョブは、直観的に設定および実行できます。問題があればユーザーに通知されます。
Oracle Data Pump
データ・ポンプでは、Oracleデータベース・コンテンツのバルク・データおよびメタデータの高速かつパラレルの移動が可能です。このユーティリティは、Oracleデータベースのデータをオペレーティング・システム・ファイルに書き込むことで、論理バックアップを作成します。このデータは、後からOracleデータベースにインポートできます。
ユーザー管理バックアップ
オペレーティング・システム固有のコマンドを実行してデータベースを手動でバックアップします。
Oracle Recovery Manager(RMAN)は、コマンドラインおよびEnterprise Managerで使用できるツールで、Oracleデータベースの効率的なバックアップとリカバリに推奨される方法です。RMANは、サーバーと緊密に連携して作動するように設計されており、バックアップとリストア時にブロックレベルで破損を検出できます。RMANでは、ファイルの多重化とバックアップ・セットの圧縮により、バックアップ時のパフォーマンスと領域消費が最適化されます。また、含まれているメディア管理ライブラリ(MML)APIを使用することにより、主なテープおよびストレージ・メディア製品と統合されます。
RMANは、バックアップまたはリストアの前後で、基礎となるデータベース・プロシージャをすべて処理するため、オペレーティング・システムやSQL*Plusスクリプトの依存から解放されます。また、様々なホスト・オペレーティング・システムに対してバックアップ・タスクの共通インタフェースを提供し、ユーザー管理の方法では使用できない機能を提供します。これは、データファイルや表領域レベルのバックアップとリカバリ、バックアップおよびリカバリ・データ・ストリームのパラレル化、増分バックアップ、データベース構造変更に伴う制御ファイルの自動バックアップ、バックアップ保存ポリシー、すべてのバックアップの詳細履歴などです。
関連項目: RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Recovery Managerは一般にコマンドライン・ユーティリティとして使用されますが、Oracle Enterprise ManagerではGUIを使用してバックアップとリカバリを実行できます。Oracle Enterprise Manager(EM)では、よく使用される次のバックアップおよびリカバリ機能がサポートされます。
バックアップ構成: 繰り返して使用される一般的な構成をカスタマイズして保存します。
バックアップおよびリカバリのウィザード: バックアップ・スクリプトの作成およびスケジュール済ジョブとしての発行の手順を示します。
バックアップ・ジョブ・ライブラリ: よく使用されるバックアップ・ジョブを保存します(バックアップ・ジョブは取り出して複数のターゲットに適用できます)。
バックアップ・ジョブ・タスク: ユーザー定義のRMANスクリプトを使用してRMANジョブを発行します。
物理バックアップを補助するために、データ・ポンプ(エクスポートおよびインポート)ユーティリティを使用して、データの論理バックアップを作成できます。論理バックアップには、データベースに対して作成されたスキーマ・オブジェクトの情報が格納されます。データ・ポンプによって、データとメタデータが一連のオペレーティング・システム・ファイルにロードされます。これらのファイルは、同じシステムにインポートするか、別のシステムに移してそこでインポートすることができます。
ダンプ・ファイル・セットは、表データ、データベース・オブジェクト・メタデータおよび制御情報を含む1つ以上のディスク・ファイルで構成されます。これらのファイルはバイナリ形式です。インポート操作時には、データ・ポンプ・インポート・ユーティリティがこれらのファイルを使用し、ダンプ・ファイル・セット内の各データベース・オブジェクトの場所を探します。
Recovery Managerを使用しない場合は、オペレーティング・システムのコマンドを使用できます。たとえば、UNIXのdd
コマンドまたはtar
コマンドを使用してバックアップを作成します。ユーザー管理のオンライン・バックアップを作成するには、データベースを手動でホット・バックアップ・モードに切り替える必要があります。ホット・バックアップ・モードでは、オンライン・ログ・ファイルに追加の書き込みが行われ、ファイルのサイズが増大します。
スクリプトを作成してバックアップ操作を自動化することもできます。データベース全体のバックアップを一度に作成するか、表領域、データファイル、制御ファイルまたはアーカイブ・ログを個別にバックアップできます。データベース全体のバックアップを補完するように、表領域、データファイル、制御ファイル、アーカイブ・ログの個別バックアップを使用できます。
オペレーティング・システムのコマンドまたはサード・パーティのバックアップ・ソフトウェアを使用して、データベースのバックアップを実行できます。また、データベースのバックアップをリストアするためにはサード・パーティのソフトウェアを使用する必要があります。
データ・ウェアハウスのリカバリは、OLTPシステムのリカバリと変わりません。ただし、データ・ウェアハウスでは、すべてのデータをバックアップからリカバリしなくても、あるいは全面的な障害時にデータベース全体のリストアを行わなくても、ユーザー・アクセスを開始することが可能です。データ・ウェアハウスで効率的かつ高速のリカバリを行うには、まず適切なバックアップを計画します。
次の項では、バックアップすべきデータの識別について説明し、最短期間でクリティカル・データをリカバリできる方法とツールを示します。
リカバリ時間目標つまりRTOは、データをリカバリする必要がある期限です。バックアップおよびリカバリ計画は、企業がデータ・ウェアハウスについて設定したRTOを満たすように設計する必要があります。たとえば、Oracle Databaseの全面的な損失に際して、データの5%を12時間以内に使用可能にし、50%を2日以内に使用可能にし、残りのデータを5日以内に使用可能にすると決定する場合があります。この場合、RTOは3つあります。合計のRTOは7.5日です。
RTOを決定するには、データが使用できないことによる影響をまず特定する必要があります。RTOを設定するには、次の4つの手順を実行します。
分析と特定: リカバリの準備状況、リスクがある分野、データが使用できないために発生するビジネス・コストを理解します。データ・ウェアハウスでは、停止後n日以内でリカバリする必要があるクリティカル・データを識別する必要があります。
設計: リカバリ要件に基づいてバックアップおよびリカバリの戦略を作成します。これを行うには、論理的な関係と重要性に基づいてデータを分類します。
構築と統合: データのバックアップとリカバリを行う環境にソリューションをデプロイして統合します。バックアップおよびリカバリ計画を文書化します。
管理と展開: リカバリ計画を定期的にテストします。データ、ITインフラストラクチャおよびビジネス・プロセスが変更するにつれて、ソリューションを調整および更新するように変更管理プロセスを実装します。
リカバリ・ポイント目標つまりRPOは、組織に有害な結果をもたらすことのないデータ損失の最大許容量です。RPOは、ビジネス・プロセスまたは組織全般におけるデータ損失の許容範囲を示します。多くの場合、このデータ損失は、たとえば5時間分または2日分のデータ損失というように期間で表します。RPOが0の場合、メディアの損害時にコミット済データの損失が許容されません。一方、RPOが24時間の場合は、1日分のデータ損失が許容されます。
データ・ウェアハウスの最大の特徴はデータベースのサイズです。サイズは最大では数百TBを上回ります。このため、ハードウェアが、高速のバックアップとリカバリを制限する要因になります。ただし、現在のテープ・ストレージは、テープにオフロードする必要があるデータ容量を収容できるように進化し続けています(たとえば、標準的なテープ・アクセス・インタフェースを備え、内部でディスクを利用する仮想テープ・ライブラリが出現しています)。RMANは、使用可能なすべてのテープ・デバイスをパラレルで最大限に活用して、バックアップとリカバリで最高のパフォーマンスを実現します。
基本的には、大規模データベースのバックアップに必要な時間は、最小スループット(本番ディスク、HBA/ネットワークからテープ・デバイスへの転送、テープ・ドライブのストリーム仕様のいずれか)とテープ・ドライブ数を掛けて算出できます。また、RMANのバックアップ暗号化または圧縮が使用される場合は、ホストCPUがバックアップ全体のパフォーマンスを制限する要因になることがあります。バックアップおよびリカバリの期間は、適切なハードウェア・リソースがあれば、すべてのビジネス要件に合うように調整できます。
データ・ウェアハウスでは、データベースが全面的に利用されない期間があります。この期間が数時間ずつ細切れになっている場合は、データベース全体をバックアップするには十分ではありません。したがって、数日間かけてデータベースのバックアップを分割して行うことを検討してください。RMANでは、所定のバックアップ・ジョブの実行可能時間を指定できます。BACKUP ... DURATION
を使用すると、バックアップを完了するまでできるだけ迅速に実行するか、バックアップによってデータベースが受ける負荷を最小限に抑えるようにゆっくり実行するかを選択できます。
次の例では、RMANによって、過去7日間にバックアップされていないすべてのデータベース・ファイルが最初にバックアップされます。また、実行時間は4時間で、ブロックをできるだけ高速で読み取ります。
BACKUP DATABASE NOT BACKED UP SINCE 'sysdate - 7' PARTIAL DURATION 4:00 MINIMIZE TIME;
このRMANコマンドが実行されるたびに、過去7日間にバックアップされていないデータファイルが最初にバックアップされます。毎晩バックアップされる表領域またはデータファイルを手動で指定する必要はありません。すべてのデータベース・ファイルが数日かけてバックアップされます。
これはデータベース・バックアップの単純な方法ですが、実装が容易であり、大容量データのバックアップに対しても柔軟性があります。リカバリの際には、RMANがリストアを実行するために複数の異なるストレージ・デバイスを指定することがあるので注意してください。結果としてリカバリ時間が長くなることがあります。
バックアップおよびリカバリ戦略を考えるのは困難な作業です。数百TBのデータを保護して、障害時にリカバリする必要がある場合、戦略は非常に複雑になります。この後の項では、バックアップとリカバリの管理を容易にするために実装できるベスト・プラクティスをいくつか示します。
アーカイブREDOログは、データベースの変更内容の記録であるため、データの損失が許容されない場合にリカバリに不可欠です。Oracleは次のいずれかのモードで実行できます。
ARCHIVELOG
一杯になったオンラインREDOログ・ファイルは、アーカイブされてから、順番に再利用されます。
NOARCHIVELOG
一杯になったオンラインREDOログ・ファイルは、アーカイブされずに、順番に再利用されます。
データベースをARCHIVELOG
モードで実行すると次の利点があります。
インスタンス障害とメディア障害のどちらでもデータベースを完全にリカバリできます。
データベースがオープンして使用可能な状態でバックアップを実行できます。
アーカイブ・ログでのシングル・ポイント障害の可能性を回避するために、多重化アーカイブ・ログがサポートされます。
表領域のポイント・イン・タイム・リカバリ(TSPITR)の実行など、ほとんどのリカバリ・オプションが使用可能です。
アーカイブREDOログを、プライマリ・データベースの正確な複製である物理スタンバイ・データベースに送信して適用できます。
データベースをNOARCHIVELOG
モードで実行すると次の影響があります。
データベースをバックアップできるのは、正しく停止して完全にクローズしているときだけです。
通常、メディア・リカバリ・オプションのみでは、全体バックアップまたは増分バックアップが行われたポイント・イン・タイムにデータベース全体がリストアされます。このとき、最新のトランザクションが失われることがあります。
Oracle Databaseのバックアップは、データベースがオープンしているときにもクローズしているときにも行えます。データベースの計画的な停止は、特に常時複数のタイムゾーンのユーザーをサポートする国際的な企業では、運用に混乱を招くことがあります。このような場合は、データベースの中断を最小限に抑えるようにバックアップ計画を設計することが重要です。
業務によって異なりますが、一部の企業では停止時間が許容されます。業務全体の戦略で停止時間がほとんどまたはまったく不要な場合、バックアップ戦略ではオンライン・バックアップを実装する必要があります。バックアップのためにデータベースを停止する必要はありません。オンライン・バックアップには、データベースがARCHIVELOG
モードであることが必要です。
データ・ウェアハウスのサイズ(およびデータ・ウェアハウスをバックアップするための時間)のため、通常、データ・ウェアハウスのオフライン・バックアップの作成は実現可能ではありません。ただし、NOARCHIVELOG
モードを使用している場合には、強いて実行することもできます。
以前のリリースのOracle Databaseで開発された多くのデータ・ウェアハウスには、バックアップとリカバリのためのRMANが統合されていないことがあります。ただし、ARCHIVELOGモードを利用する理由が豊富にあるように、RMANの採用する強力な理由も多数あります。次の項目を考慮してください。
問題のないバックアップおよびリカバリ
破損ブロックの検出
アーカイブ・ログの検証と管理
ブロック・メディア・リカバリ(BMR)
メディア・マネージャとの容易な統合
バックアップとリストアの最適化
バックアップとリストアの検証
停止時間の不要なバックアップ
増分バックアップ
豊富なレポート
ブロック・チェンジ・トラッキングを有効にすると、最後の全体バックアップまたは増分バックアップ以降に変更されたブロックのみを読み書きすることにより、増分バックアップを速く完了できるようになります。データ・ウェアハウスでは、通常はデータベースの変更率が低いかもしくは中程度であるため、この機能はきわめて有効です。
関連項目: ブロック・チェンジ・トラッキングの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
ビッグファイル表領域が出現したため、データ・ウェアハウスでは、大多数のデータファイルを適切に管理される少数のデータファイルにまとめることができます。非常に大きなデータファイルのバックアップでは、RMANにより、ファイル内でのバックアップ操作をパラレル化する方法としてマルチセクション・バックアップが提供されます。この方法では、ファイル単位でバックアップが行われるかわりに、ファイルのセクションがパラレルでバックアップされます。
たとえば、1TBのデータファイルを100GBのバックアップ・ピース10個のセクションに分け、1TBのファイル全体を一度にバックアップするかわりに各セクションをパラレルでバックアップします。このようにすると、大きなデータファイルの全体のバックアップ時間が大幅に短縮できます。
関連項目: マルチセクション・バックアップの構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
データ・ウェアハウスが直面する主要な問題の1つは、典型的なデータ・ウェアハウスのサイズの大きさです。高性能のバックアップ・ハードウェアを使用しても、バックアップには数時間がかかることがあります。このため、バックアップのパフォーマンスを改善する重要な考慮事項は、バックアップするデータ容量を最小限に抑えることです。読取り専用表領域は、データ・ウェアハウスでバックアップを行うデータ容量を削減する最も単純なメカニズムです。増分バックアップの場合でさえ、表領域が読取り専用に設定されているとバックアップとリカバリの処理が速くなります。
読取り専用表領域の利点は、データを1回しかバックアップする必要がないということです。データ・ウェアハウスに5年分の履歴データが含まれており、最初の4年分のデータを読取り専用にできる場合、理論的には、データベースの定期バックアップではデータの20%のみがバックアップされることになります。このように、データ・ウェアハウスのバックアップに必要な時間が大幅に短縮されます。
ほとんどのデータ・ウェアハウスでは、データは、時間でレンジ・パーティション化された表に格納されます。一般的なデータ・ウェアハウスでは、通常、データがアクティブなのは30日〜1年の間です。この期間中であれば、履歴データはまだ更新と変更の可能性があります(たとえば、ある小売業者は購入日から30日間は返品を受け付けるため、売上データのレコードはこの期間に変更できます)。ただし、一定の時間が経過すると、データは多くの場合は静的になります。
パーティション化を活用して、ユーザーはデータの静的な部分を読取り専用にすることができます。現在、Oracleでは、読取り専用パーティションまたは読取り専用表ではなく読取り専用表領域がサポートされています。読取り専用表領域を利用して、バックアップにかかる時間を短縮するには、一定のデータ・パーティションを読取り専用表領域に格納する戦略を立てる必要があります。ローリング・ウィンドウを実装するための2つの戦略を次に示します。
データが完全に静的になる時点に達すると、読取り/書込み表領域から読取り専用表領域にパーティションを移動する、定期的にスケジュールしたプロセスを実装します。
それぞれが少数のパーティションを含む一連の表領域を作成し、1つの表領域のデータが古くなると、定期的にその表領域を読取り/書込みから読取り専用に変更します。
データのバックアップはリカバリ・プロセスの半分にすぎないことに注意してください。データ・ウェアハウスの読取り/書込み部分を4時間でバックアップできるようにテープ・システムを構成した場合、そのデータベースの80%が読取り専用のときに完全リカバリが必要になると、そのテープ・システムではデータベースのリカバリに20時間かかることになります。
一般的にデータ・ウェアハウスの最優先事項の1つはパフォーマンスです。データ・ウェアハウスは、オンライン・ユーザーに優れた問合せパフォーマンスを提供する必要があるだけではなく、大容量のデータを最短の時間でロードできるようにETLプロセスでも効率が高いことが必要です。
データ・ウェアハウスでよく利用されている最適化の1つは、NOLOGGING
モードを使用したバルク・データ操作の実行です。NOLOGGING
モードをサポートするデータベース操作は、ダイレクト・パスのロードと挿入、索引作成および表作成です。操作をNOLOGGING
モードで実行すると、データはREDOログに書き込まれません(厳密には小さなメタデータのセットのみがREDOログに書き込まれます)。このモードはデータ・ウェアハウスでよく使用され、バルク・データ操作のパフォーマンスが最大で50%改善されます。
ただし、NOLOGGING
操作は従来のリカバリ・メカニズムではリカバリできないという短所があります。リカバリのために必要なデータがログ・ファイルに書き込まれないためです。さらに、NOLOGGING
操作が行われたデータに対するその後の操作は、それらの操作でNOLOGGING
モードが使用されなかった場合でもリカバリできません。NOLOGGING
操作ではパフォーマンスが向上するため、一般的にはデータ・ウェアハウスのETLプロセスではNOLOGGING
モードの使用が推奨されます。
バックアップおよびリカバリ戦略を検討するときには、NOLOGGING
操作の存在を考慮に入れる必要があります。データベースがNOLOGGING
操作に依存している場合、従来のリカバリ戦略(最新のテープ・バックアップからリカバリしてアーカイブ・ログ・ファイルを適用する)は適用できません。ログ・ファイルでは、NOLOGGING
操作をリカバリできないためです。
第1の原則として、NOLOGGING
操作が行われるときはバックアップを作成してはならないことに注意してください。Oracleでは現在はこのルールは強制されていません。このため、NOLOGGING
操作とバックアップ操作が重ならないように、DBAがバックアップ・ジョブやETLジョブをスケジュールする必要があります。
NOLOGGING
操作が行われるとき、バックアップとリカバリの方法にはETLまたは増分バックアップの2つがあります。データ・ウェアハウスでNOLOGGING
操作を使用していない場合は、この後で説明するいずれかのオプションを選択する必要はありません。アーカイブ・ログを使用してデータ・ウェアハウスをリカバリできます。ただし、次のオプションを使用すると、アーカイブ・ログを使用する方法よりもリカバリ時のパフォーマンスがある程度向上することがあります。また、フラッシュバック・ログおよび保証付きリストア・ポイントを使用して、データベースを前のポイント・イン・タイムにフラッシュバックすることもできます。
ETLプロセスでは、データをデータ・ウェアハウスにロード(再ロード)するために、Oracle機能といくつかの方法の組合せが使用されます。次の機能が使用されます。
トランスポータブル表領域
トランスポータブル表領域を使用すると、ユーザーがOracleデータベース間で表領域を迅速に移動できます。これは、バルク・データをデータベース間で移動する最も効率のよい方法です。Oracle Databaseには、表領域をプラットフォーム間でトランスポートする機能があります。トランスポート元のプラットフォームとトランスポート先のプラットフォームのエンディアンが異なる場合、RMANによって、トランスポートされる表領域が宛先のフォーマットに変換されます。
SQL*Loader
SQL*Loaderによって、データが外部のフラット・ファイルからOracle Databaseの表にロードされます。SQL*Loaderには高性能のデータ解析エンジンが含まれており、データファイルのデータのフォーマットにはほとんど制限がありません。
データ・ポンプ(エクスポートおよびインポート)
Oracle Data Pumpを使用すると、Oracleデータベース間でのデータとメタデータの高速移動が可能になります。このテクノロジは、Oracleのデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティの基本です。
外部表
外部表によって、既存のSQL*Loader機能が補完されます。この機能を使用すると、外部ソースのデータにデータベースの表のようにアクセスできます。外部表をデータ・ポンプ・ドライバと一緒に使用すると、CREATE TABLE ... AS SELECT * FROM
を使用してOracleデータベースのデータをエクスポートしてから、データをOracleデータベースにインポートすることもできます。
1つの方法では、データベースの定期的なバックアップを行い、同時に、1週間分のETLプロセスを再作成するために必要なデータファイルを格納します。リカバリが必要な場合、データ・ウェアハウスは最新のバックアップからリカバリできます。その後、アーカイブREDOログを適用してロールフォワード(従来のリカバリ・シナリオ)するかわりに、ETLプロセスを再実行してデータ・ウェアハウスをロールフォワードできます。この方法では、ETLプロセスが容易に再生できることが前提です。通常、再生時にはETLプロセスごとに一連の抽出ファイルが格納されます。
この方法の実装例としては、データ・ウェアハウスのバックアップを毎週末に作成し、ETLプロセスのサポートに必要なファイルを毎晩格納します。この例では、データベースをリカバリするために最大で7日間のETL処理を再適用する必要があります。データ・ウェアハウス管理者は、テープからのリカバリ速度と以前のETL実行のパフォーマンス・データに基づいて、データ・ウェアハウスのリカバリにかかる時間を簡単に予測できます。
基本的に、データ・ウェアハウス管理者は、NOLOGGING
操作によってETLプロセスのパフォーマンスを改善できますが、リカバリ・プロセスが少し複雑になり自動処理が減るという代償があります。多くのデータ・ウェアハウス管理者はこれを望ましいトレードオフととらえています。
この方法の1つの短所は、データ・ウェアハウスで行われた関連する変更をすべて管理する負担がデータ・ウェアハウス管理者にかかることです。この方法では、ETLプロセスに含まれない変更は取得されません。たとえば、データ・ウェアハウスによってはエンド・ユーザーが独自の表やデータ構造を作成できます。このような変更はリカバリ時にわからなくなります。
この制約はエンド・ユーザーに伝える必要があります。または、エンド・ユーザーが個人用のデータベース・オブジェクトをすべて別の表領域に作成するように義務付けることができます。リカバリ時には、DBAがこの表領域を従来のリカバリ方法でリカバリし、データベースのその他の部分は、ETLプロセスの再生を使用してリカバリします。
NOLOGGING
操作が存在する場合、バックアップおよびリカバリ戦略に自動化を取り入れるにはRMANの増分バックアップ機能を利用します。増分バックアップは、直前のバックアップ以降に変更されたブロックのみをバックアップする機能です。データファイルの増分バックアップは、ブロック単位でデータの変更を取得します。データファイルのすべての使用済ブロックのバックアップは必要ありません。データファイルのすべてのブロックに変更がないかぎり、結果として生成されるバックアップ・セットは、通常は完全データファイル・バックアップよりも小さくて効率的です。
ブロック・チェンジ・トラッキングを使用可能にすると、すべてのデータベース変更の物理位置が記録されます。RMANはチェンジ・トラッキング・ファイルを自動的に使用して、増分バックアップで読み取る必要があるブロックを判別します。ブロック・チェンジ・トラッキング・ファイルのサイズは、データベースの合計サイズのおよそ30000分の1です。
関連項目: ブロック・チェンジ・トラッキングの詳細と有効化の方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
この方法を使用する典型的なバックアップおよびリカバリ戦略では、データ・ウェアハウスを毎週末にバックアップし、その後は、毎晩ETLプロセスが終了してからデータ・ウェアハウスの増分バックアップを行います。増分バックアップは従来のバックアップと同様に、NOLOGGING
操作と同時には実行できないことに注意してください。データ・ウェアハウスをリカバリするには、データベース・バックアップをリストアし、次に毎晩の増分バックアップを再適用します。
NOLOGGING
操作はアーカイブ・ログには取得されませんが、NOLOGGING
操作によるデータは増分バックアップに含まれます。さらに、前の方法とは異なり、このバックアップおよびリカバリ戦略は全面的にRMANを使用して管理できます。
フラッシュバック・データベースは、広範に及ぶ論理エラーを修正するための高速で連続的なポイント・イン・タイム・リカバリ方法です。フラッシュバック・データベースは、フラッシュバック・ログと呼ばれる特別なロギングを利用します。これは、フラッシュ・リカバリ領域に作成され、リカバリ・ニーズに対応するようにユーザーが定義した期間にわたり保持されます。これらのログには、ブロックの更新時に元のブロック・イメージが記録されます。
フラッシュバック・データベース操作が実行されると、変更されたデータに対応するブロック・イメージのみがリストアおよびリカバリされます。これに対して、従来のデータファイル・リストアでは、バックアップ内のすべてのブロックをリストアしないとリカバリを開始できませんでした。フラッシュバック・ログはREDOログと比例するように作成されます。
非常に大規模で頻繁に使用されるデータベースでは、連続するポイント・イン・タイム・リカバリのために必要なすべてのフラッシュバック・ログを保存しておくことは実現不可能です。ただし、場合によっては、バッチ実行中の論理エラーの発生に備えて、特定のポイント・イン・タイム・スナップショットを作成する必要があります(たとえば、毎晩のバッチ・ジョブの直前など)。このシナリオでは、フラッシュバック・ロギングを有効化せずに保証付きリストア・ポイント(GRP)を作成できます。
GRPが作成されると、他のポイント・イン・タイムではなくGRPに対するフラッシュバック・データベースのみに対応するように、フラッシュバック・ログが管理され、領域が節約されます。たとえば、GRPは、ロギングなしのバッチ・ジョブの前に作成できます。GRPを作成する前の1時間以内にロギングなしの操作が行われていないかぎり、GRPへのフラッシュバック・データベースによりロギングなしのバッチ・ジョブが元に戻されます。ロギングなしのバッチ・ジョブが終了した後の時刻にフラッシュバックするには、バッチ・ジョブが終了して少なくとも1時間経過してからGRPを作成します。
このシナリオにおいて、GRPに対するフラッシュバック・ログ領域の見積もりは、GRPを保持する日数の間にデータベースのどれくらいの容量が変更されるかによって異なります。たとえば、GRPを2日間保持し、データベースで100GB分の変更を予定する場合、フラッシュバック・ログとして100GBを用意します。100GBは、変更の回数ではなく、GRPの作成後に変更されるデータベースのサブセットを表すことに注意してください。
バックアップとリカバリの観点では、データ・ウェアハウスのすべての表領域の重要性が等しいということはありません。DBAは、必要に応じてこの情報を利用して、より効率のよいバックアップおよびリカバリ戦略を立てることができます。バックアップとリカバリの基本の最小単位は表領域です。このため、表領域ごとに異なるバックアップおよびリカバリ戦略を使用することも可能です。
最も基本的なレベルでは、一時表領域はバックアップする必要がありません(RMANによって施行されるルール)。さらに、一部のデータ・ウェアハウスでは専用のスクラッチ表領域があり、エンド・ユーザーが一時的な表や増分結果を格納できます。このような表領域は明示的な一時表領域ではありませんが、本質的には一時表領域として機能します。業務要件によっては、このような表領域をバックアップしてリストアする必要がないこともあります。かわりに、このような表領域に損害が発生した際には、エンド・ユーザーが自らのデータ・オブジェクトを再作成します。
多くのデータ・ウェアハウスでは、データによって重要性が異なります。たとえば、あるデータ・ウェアハウスでは売上データが重要であり、リカバリ時にはこのデータをできるだけ早くオンラインに戻す必要があります。ただし、同じデータ・ウェアハウスにおいて、企業Webサイトのクリックストリーム・データを格納する表はそれほど重要ではありません。業務の面では、このデータが数日間オフラインになっていても許容されます。つまり、データベース・ファイルが損失した場合に、クリックストリーム・データが数日間なくても問題ありません。このシナリオでは、売上データを含む表領域は頻繁にバックアップする必要があるが、クリックストリーム・データを含む表領域のバックアップは1週間もしくは2週間に1回ですみます。
最も単純なバックアップおよびリカバリ・シナリオでは、データベースのすべての表領域を同じように扱いますが、Oracleでは、DBAが必要に応じて表領域ごとにバックアップおよびリカバリ・シナリオを調整できるような柔軟性を備えています。