VLDBのバックアップおよびリカバリ

9 VLDBのバックアップおよびリカバリ

バックアップとリカバリは、DBAが業務データを保護するために行う重要で不可欠なジョブです。

データ記憶域が毎年増大するにつれ、DBAは、クリティカル・データをバックアップして、ビジネス・ニーズに合うように迅速かつ容易にリカバリできるように保証することを常に求められます。大規模データベースは、その大きさとデータが多くのリソースに由来するという点が独特です。OLTPとデータウェアハウスにはそれぞれの特性があります。通常、大規模OLTPシステムでの可用性の考慮事項は、小規模OLTPシステムの場合の考慮事項と変わりません。停止可能な時間が同じであれば、大規模OLTPシステムは小規模OLTPシステムよりも多くのハードウェア・リソースが必要になります。

この章では、大規模データベースのための効果的なバックアップとリカバリの戦略を提案します。この戦略は、OLTPシステムとは異なるデータ・ウェアハウスの特性を利用して、バックアップとリカバリをサポートするために必要なリソースを全面的に削減します。

この章の構成は、次のとおりです。

9.1 データ・ウェアハウス

データ・ウェアハウスは、分析や意思決定をサポートするために設計されたシステムです。

一般的な企業では、数百または数千名のユーザーが業務の理解に役立つ情報を得たり、適切な決定を行ったりするために、データ・ウェアハウスを利用しています。したがって、可用性はデータ・ウェアハウスの重要な要件です。この章では、データ・ウェアハウスの可用性の重要なポイントである、データ損失後のデータ・リカバリについて説明します。

バックアップとリカバリの技法を詳しく調べる前に、データ・ウェアハウスのバックアップとリカバリのための固有の技法について理解する必要があります。特に、データ・ウェアハウスのバックアップとリカバリの戦略は、その他のデータベース・システムと同じにするべきかという当然の疑問について説明します。

DBAは、データ・ウェアハウスのバックアップとリカバリの作業を始めるにあたり、OLTPシステムで使用されるのと同じ技法を適用します。つまり、重要性と変更の頻度に応じてデータの優先順位を付けて、保護すべき情報、およびメディア・リカバリが必要になったときに迅速にリカバリすべき情報を決定する必要があります。ただし、データ・ウェアハウスに関して通常生じる問題は、100GBのOLTPシステムでは効率がよくコスト効果が高い方法であっても、10TBのデータ・ウェアハウスには適さないということです。バックアップとリカバリの時間は100倍かかり、記憶域も100倍必要になります。

関連項目:

データ・ウェアハウスの詳細は、Oracle Databaseデータ・ウェアハウス・ガイドを参照してください。

9.1.1 データ・ウェアハウスの特性

データ・ウェアハウスとOLTPシステムにはいくつかの違いがあり、バックアップとリカバリに大きく影響します。

それらの違いは次のとおりです。

通常、データ・ウェアハウスはOLTPシステムよりもかなり大規模です。数十TBを超えるデータ・ウェアハウスもまれではなく、最大規模のデータ・ウェアハウスはさらに桁違いの大きさになります。このため、データ・ウェアハウスのバックアップとリカバリではスケーラビリティは特に重要な考慮事項です。
多くの場合、データ・ウェアハウスの可用性要件はOLTPシステムに比べて低くなります。データ・ウェアハウスがビジネスにとってクリティカルな場合、数TBのデータを数時間でリカバリできるようにするためには、一日かけてリカバリする場合よりもかなりのコストがかかります。データ・ウェアハウスの大部分のリカバリを必要とするような障害は発生する可能性が低いため、組織によっては、バックアップ用のハードウェアやストレージにかける多額の支出を節約できるのであれば、1日以上の停止も容認する場合があります。
通常、データ・ウェアハウスは、ユーザーが自らデータを変更するOLTPシステムとは異なり、ETL (抽出、変換、ロード)という制御プロセスによって更新されます。データ変更が制御プロセスによって行われるため、多くの場合、データ・ウェアハウスの更新はREDOログ以外のソースからも認識でき再現可能です。
データ・ウェアハウスには履歴情報が含まれます。また、多くの場合、データ・ウェアハウスの古いデータの大部分は静的です。たとえば、あるデータ・ウェアハウスでは売上の履歴データが5年分管理されます。最も新しい年のデータは(返品、決算修正などのために)変更される可能性がありますが、以前の4年分のデータは完全に静的です。静的データの利点は、頻繁にバックアップを行う必要がないことです。

これらの4つの特性は、データ・ウェアハウスに最適なバックアップおよびリカバリ戦略を検討する際の重要な考慮事項です。

9.2 Oracleのバックアップとリカバリ

一般的に、バックアップとリカバリは、データ損失に対するデータベースの保護や、なんらかのデータ損失の後でのデータベースの再構築に関連する様々な戦略や手順を意味します。

バックアップとはデータのかわりとなるコピーです。このコピーには、データベースの重要な部分(制御ファイル、アーカイブREDOログ、データファイルなど)を含めることができます。バックアップは、元のデータをリストアする手段を提供することにより、アプリケーション・エラーからデータを保護し、予期しないデータ損失に対する安全装置として機能します。

この項では、次の項目について説明します。

9.2.1 データのリカバリで使用される物理データベース構造

バックアップおよびリカバリ戦略を本格的に検討する前に、バックアップとリカバリの操作に関連する物理データ構造を確認します。

これらのコンポーネントが、Oracleデータ・ストアのデータを構成するファイルやその他の構造を含み、このデータ・ストアを潜在的な障害から保護します。Oracle Databaseのリカバリには次の3つの基本コンポーネントが必要です。

9.2.1.1 データファイル

Oracle Databaseは、表領域と呼ばれる1つ以上の論理記憶域単位で構成されます。Oracle Databaseの各表領域は、データファイルという1つ以上のファイルで構成されます。データファイルは、Oracle Databaseが稼働しているホスト・オペレーティング・システムに存在する、またはホスト・オペレーティング・システムに接続する物理ファイルです。

データベースのデータは、データファイルにまとめて格納されており、データファイルがデータベースの各表領域を構成します。最も単純なOracle Databaseは、1つの表領域があり、1つのデータファイルが格納されます。データベースのデータファイルのコピーは、すべてのバックアップ戦略に欠かせない部分です。データファイルのサイズが大きいことが、VLDBのバックアップとリカバリにおいて主要な課題になります。

9.2.1.2 REDOログ

REDOログには、データベースのデータファイルに対する変更がすべて記録されます。

REDOログの完全なセットとそれ以前のデータファイルのコピーがあれば、Oracleで、REDOログに記録された変更を再適用して、バックアップ時点から最後のREDOログの終了時点までの任意の時点のデータベースを再作成できます。Oracle Databaseでデータが変更されるたびに、その変更がオンラインREDOログにまず記録されてからデータファイルに適用されます。

Oracle Databaseでは、少なくとも2つのオンラインREDOログ・グループが必要です。各グループには、少なくとも1つのオンラインREDOログ・メンバーつまり1つのREDOログ・ファイルが含まれ、このファイルに変更内容が記録されます。時間隔で、Oracle DatabaseはオンラインREDOログ・グループを入れ替えます。現行オンラインREDOログに変更内容を格納する一方で、使用していないグループはアーカイブREDOログと呼ばれるアーカイブ場所にコピーできます。高可用性を実現するために、本番システムは、常に1グループ当たり複数のオンラインREDOメンバーを使用する必要があります。できればメンバーを異なる記憶域システムに配置することをお薦めします。アーカイブREDOログにはデータファイルのすべての更新記録が含まれるため、アーカイブREDOログの保存がバックアップ戦略の主要な部分です。多くのバックアップ戦略では、長期保管のためにアーカイブREDOログをディスクまたはテープにコピーします。

9.2.1.3 制御ファイル

制御ファイルには、データベースの物理構造とそのステータスの重要なレコードが含まれます。

制御ファイルに格納される次のタイプの情報は、バックアップとリカバリに関連します。

障害からリカバリするため、つまりメディア・リカバリを実行するために必要なデータベース情報
データベース構造情報(データファイルの詳細など)
REDOログの詳細
アーカイブ・ログ・レコード
過去のRMANバックアップのレコード

Oracle Databaseのデータファイル・リカバリ・プロセスのある部分は、制御ファイルのステータス情報(データベース・チェックポイント、現行オンラインREDOログ・ファイル、データファイル・ヘッダー・チェックポイントなど)によって決まります。制御ファイルが失われると、データ損失からのリカバリがさらに困難になります。最新のデータベース構造変更を保存し、リカバリを容易に行えるように、制御ファイルを定期的にバックアップする必要があります。

9.2.2 バックアップ・タイプ

バックアップには、物理バックアップと論理バックアップがあります。

物理バックアップは、データベースの格納とリカバリに使用される物理ファイル(データファイル、制御ファイル、アーカイブREDOログなど)のバックアップです。究極的には、すべての物理バックアップは、データベース情報を格納するファイルを別の場所(ディスク上またはテープなどのオフライン・ストレージ上)にコピーすることです。
論理バックアップには、Oracle Data Pump (エクスポートおよびインポート)ユーティリティでデータベースから抽出された論理データ(たとえば、表またはストアド・プロシージャ)が含まれます。データは、Oracle Databaseにインポートできるバイナリ・ファイルに格納されます。

物理バックアップは、すべてのバックアップおよびリカバリ戦略の基盤です。論理バックアップは、様々な状況で物理バックアップを補足するために役立ちますが、物理バックアップがなければデータ消失に十分に対処することはできません。

データベースのすべてまたは一部の内容をバックアップから再構築するには、通常は2つの段階があります。まずバックアップからデータファイルのコピーを取り出し、次にバックアップ以降の変更内容をアーカイブREDOログおよびオンラインREDOログからファイルに再適用して、データベースの状態をリカバリ希望の時点に戻します。データファイルまたは制御ファイルをバックアップからリストアするには、テープ、ディスクまたは他のメディアのバックアップ場所からファイルを取得して、Oracle Databaseで使用できるようにします。データファイルをリカバリするには、データファイルをリストアし、データベースのREDOログに記録された変更内容を適用します。データベース全体をリカバリするには、データベースのデータファイルそれぞれについてリカバリを実行します。

9.2.3 バックアップ・ツール

Oracle Databaseのバックアップとリカバリを管理するためにいくつかのツールが提供されます。

各ツールではバックアップを作成するためにいくつかの基本的な方法から選択できます。次の方法があります。

Oracle Recovery Manager(RMAN)

RMANでは、すべてのバックアップと必要なリカバリ関連ファイルに関するメタデータの大量の記録が管理されるため、バックアップ戦略に伴う管理作業が削減されます。リストアおよびリカバリ操作ではRMANがこの情報を使用するため、ユーザーが必要なファイルを特定する必要がなくなります。RMANは効率性が高く、ファイル多重化およびパラレル・ストリームの機能をサポートしています。また、バックアップおよびリストアの際には、物理的な破損および論理的な破損(オプション)についてブロックの検査を行います。

V$BACKUPビューを使用して、バックアップ・アクティビティ・レポートを生成できます。
Oracle Data Pump

Oracle Data Pumpでは、Oracle Databaseコンテンツのバルク・データおよびメタデータの高速かつパラレルの移動が可能です。このユーティリティは、Oracle Databaseのデータをオペレーティング・システム・ファイルに書き込むことで、論理バックアップを作成します。このデータは、後からOracle Databaseにインポートできます。
ユーザー管理バックアップ

オペレーティング・システム固有のコマンドを実行してデータベースを手動でバックアップします。

9.2.3.1 Oracle Recovery Manager(RMAN)

Oracle Recovery Manager (RMAN)はコマンドラインで、Oracle Databaseを効率よくバックアップおよびリカバリする際に使用することをお薦めします。

RMANは、サーバーと密接に作用するよう設計されており、バックアップおよびリカバリ中のブロックレベルの破損を検出します。RMANでは、ファイルの多重化とバックアップ・セットの圧縮により、バックアップ時のパフォーマンスと領域消費が最適化されます。また、含まれているメディア管理ライブラリ(MML) APIを使用することにより、主なテープおよびストレージ・メディア製品と統合されます。

RMANは、バックアップまたはリストアの前後で、基礎となるデータベース・プロシージャをすべて処理するため、オペレーティング・システムやSQL*Plusスクリプトの依存から解放されます。また、様々なホスト・オペレーティング・システムに対してバックアップ・タスクの共通インタフェースを提供し、ユーザー管理の方法では使用できない機能を提供します。これは、データファイルや表領域レベルのバックアップとリカバリ、バックアップおよびリカバリ・データ・ストリームのパラレル化、増分バックアップ、データベース構造変更に伴う制御ファイルの自動バックアップ、バックアップ保存ポリシー、すべてのバックアップの詳細履歴などです。

関連項目:

RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

9.2.3.2 Oracle Data Pump

物理バックアップを補助するために、Oracle Data Pump (エクスポートおよびインポート)ユーティリティを使用して、データの論理バックアップを作成できます。

論理バックアップには、データベースに対して作成されたスキーマ・オブジェクトの情報が格納されます。Oracle Data Pumpによって、データとメタデータが一連のオペレーティング・システム・ファイルにロードされます。これらのファイルは、同じシステムにインポートするか、別のシステムに移してそこでインポートすることができます。

ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータ、制御情報を含む1つ以上のディスク・ファイルで構成されています。これらのファイルはバイナリ形式です。データ・ポンプ・インポート・ユーティリティは、インポート操作中、これらのファイルを使用してダンプ・ファイル・セット内の各データベース・オブジェクトの位置を特定します。

9.2.3.3 ユーザー管理バックアップ

Recovery Managerを使用しない場合は、オペレーティング・システムのコマンドを使用できます。たとえば、UNIXのddまたはtarコマンドを使用してバックアップを作成します。

ユーザー管理のオンライン・バックアップを作成するには、データベースを手動でホット・バックアップ・モードに切り替える必要があります。ホット・バックアップ・モードでは、オンライン・ログ・ファイルに追加の書き込みが行われ、ファイルのサイズが増大します。

スクリプトを作成してバックアップ操作を自動化することもできます。データベース全体のバックアップを一度に作成するか、表領域、データファイル、制御ファイルまたはアーカイブ・ログを個別にバックアップできます。データベース全体のバックアップを補完するように、表領域、データファイル、制御ファイル、アーカイブ・ログの個別バックアップを使用できます。

オペレーティング・システムのコマンドまたはサードパーティのバックアップ・ソフトウェアで、データベースのバックアップを実行できます。また、データベースのバックアップをリストアするためにはサードパーティのソフトウェアを使用する必要があります。

9.3 データ・ウェアハウスのバックアップとリカバリ

データ・ウェアハウスのリカバリは、OLTPシステムのリカバリに似ています。

ただし、データ・ウェアハウスでは、すべてのデータをバックアップからリカバリしなくても、あるいは全面的な障害時にデータベース全体のリストアを行わなくても、ユーザー・アクセスを開始することが可能です。データ・ウェアハウスで効率的かつ高速のリカバリを行うには、まず適切なバックアップを計画します。

次の項では、バックアップすべきデータの識別について説明し、最短期間でクリティカル・データをリカバリできる方法とツールを示します。

この項では、次の項目について説明します。

9.3.1 リカバリ時間目標(RTO)

リカバリ時間目標 (RTO)は、データをリカバリする必要がある期限です。

バックアップおよびリカバリ計画は、企業がデータ・ウェアハウスについて設定したRTOを満たすように設計する必要があります。たとえば、データベースの全面的な損失に際して、データの5%を12時間以内に使用可能にし、50%を2日以内に使用可能にし、残りのデータを5日以内に使用可能にすると決定する場合があります。この場合、RTOは2つあります。合計のRTOは7.5日です。

RTOを決定するには、データが使用できないことによる影響をまず特定する必要があります。RTOを設定するには、次の4つのステップを実行します。

分析と特定: リカバリの準備状況、リスクがある分野、データが使用できないために発生するビジネス・コストを理解します。データ・ウェアハウスでは、停止後n日以内でリカバリする必要があるクリティカル・データを識別する必要があります。
設計: リカバリ要件に基づいてバックアップおよびリカバリの戦略を作成します。これを行うには、論理的な関係と重要性に基づいてデータを分類します。
構築と統合: データのバックアップとリカバリを行う環境にソリューションをデプロイして統合します。バックアップおよびリカバリ計画を文書化します。
管理と展開: リカバリ計画を定期的にテストします。データ、ITインフラストラクチャおよびビジネス・プロセスが変更するにつれて、ソリューションを調整および更新するように変更管理プロセスを実装します。

9.3.2 リカバリ・ポイント目標(RPO)

リカバリ・ポイント目標つまりRPOは、組織に有害な結果をもたらすことのないデータ損失の最大許容量です。

RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当します。このデータ損失は、通常、5時間または2日分のデータ損失というように、時間に換算して測定されます。RPOが0の場合、メディアの損害時にコミット済データの損失が許容されません。一方、RPOが24時間の場合は、1日分のデータ損失が許容されます。

この項では、次の項目について説明します。

9.3.2.1 データ量の増加とバックアップ時間の延長

データ・ウェアハウスの最大の特徴はデータベースのサイズです。

サイズは最大では数百TBを上回ります。このため、ハードウェアが、高速のバックアップとリカバリを制限する要因になります。ただし、現在のテープ・ストレージは、テープにオフロードする必要があるデータ容量を収容できるように進化し続けています(たとえば、標準的なテープ・アクセス・インタフェースを備え、内部でディスクを使用する仮想テープ・ライブラリが出現しています)。RMANは、使用可能なすべてのテープ・デバイスをパラレルで最大限に活用して、バックアップとリカバリで最高のパフォーマンスを実現します。

基本的には、大規模データベースのバックアップに必要な時間は、最小スループット(本番ディスク、ホスト・バス・アダプタ(HBA)およびネットワークからテープ・デバイスへの転送、テープ・ドライブのストリーム仕様のいずれか)とテープ・ドライブ数を掛けて算出できます。また、RMANのバックアップ暗号化または圧縮が使用される場合は、ホストCPUがバックアップ全体のパフォーマンスを制限する要因になることがあります。バックアップおよびリカバリの期間は、適切なハードウェア・リソースがあれば、すべてのビジネス要件に合うように調整できます。

9.3.2.2 分断攻略

データ・ウェアハウスでは、データベースが全面的に使用されない期間があります。

この期間が数時間ずつ細切れになっている場合は、データベース全体をバックアップするには十分ではありません。数日間かけてデータベースのバックアップを分割して行うことを検討してください。RMANでは、所定のバックアップ・ジョブの実行可能時間を指定できます。BACKUP DURATIONを使用すると、バックアップを完了するまでできるだけ迅速に実行するか、バックアップによってデータベースが受ける負荷を最小限に抑えるようにゆっくり実行するかを選択できます。

次の例では、RMANによって、過去7日間にバックアップされていないすべてのデータベース・ファイルが最初にバックアップされます。また、実行時間は4時間で、ブロックをできるだけ高速で読み取ります。

BACKUP DATABASE NOT BACKED UP SINCE 'sysdate - 7' 
  PARTIAL DURATION 4:00 MINIMIZE TIME;

このRMANコマンドが実行されるたびに、過去7日間にバックアップされていないデータファイルが最初にバックアップされます。毎晩バックアップされる表領域またはデータファイルを手動で指定する必要はありません。すべてのデータベース・ファイルが数日かけてバックアップされます。

これはデータベース・バックアップの単純な方法ですが、実装が容易であり、大容量データのバックアップに対しても柔軟性があります。リカバリ中には、RMANがリストア操作を実行するために複数の異なるストレージ・デバイスを指定することがあります。結果としてリカバリ時間が長くなることがあります。

9.4 データ・ウェアハウスのリカバリ方法

バックアップとリカバリの計画の考案は、複雑で困難な作業になる場合があります。

障害から保護し、リカバリする必要があるデータが何百TBもある場合、戦略は非常に複雑になります。ここでは、バックアップとリカバリの管理を容易にするために実装できるベスト・プラクティスをいくつか示します。

この項では、次の項目について説明します。

9.4.1 ベスト・プラクティス1: ARCHIVELOGモードの使用

アーカイブREDOログは、データベースの変更内容の記録であるため、データの損失が許容されない場合にリカバリに不可欠です。

Oracle Databaseは、次の2つのモードのいずれかで実行できます。

ARCHIVELOG

Oracle Databaseでは、再利用される前に満杯になったオンラインのREDOログ・ファイルがアーカイブされます。
NOARCHIVELOG

Oracle Databaseでは、再利用される前に満杯になったオンラインのREDOログ・ファイルがアーカイブされません。

データベースをARCHIVELOGモードで実行すると次の利点があります。

インスタンス障害とメディア障害のどちらでもデータベースをリカバリできます。
データベースがオープンして使用可能な状態でバックアップを実行できます。
Oracle Databaseは、アーカイブ・ログ上での単一点障害を回避するために、多重化アーカイブ・ログをサポートしています。
表領域のポイント・イン・タイム・リカバリ(TSPITR)の実行など、ほとんどのリカバリ・オプションが使用可能です。
アーカイブREDOログを、プライマリ・データベースの正確な複製である物理スタンバイ・データベースに送信して適用できます。

データベースをNOARCHIVELOGモードで実行すると次の影響があります。

データベースをバックアップできるのは、正しく停止してクローズしているときだけです。
通常、メディア・リカバリ・オプションのみでは、全体バックアップまたは増分バックアップが行われたポイント・イン・タイムにデータベース全体がリストアされます。このとき、最新のトランザクションが失われることがあります。

9.4.1.1 停止時間の許容

データベースの中断を最小限に抑えるようにバックアップ計画を設計することが重要です。

Oracle Databaseのバックアップは、データベースがオープンしているときにもクローズしているときにも行えます。データベースの計画的な停止は、特に常時複数のタイムゾーンのユーザーをサポートする国際的な企業では、運用に混乱を招くことがあります。

業務によって異なりますが、一部の企業では停止時間が許容されます。業務全体の戦略で停止時間がほとんどまたはまったく不要な場合、バックアップ戦略ではオンライン・バックアップを実装する必要があります。バックアップのためにデータベースを停止する必要はありません。オンライン・バックアップには、データベースがARCHIVELOGモードであることが必要です。

データ・ウェアハウスのサイズ(およびデータ・ウェアハウスをバックアップするための時間)のため、通常、データ・ウェアハウスのオフライン・バックアップの作成は実現可能ではありません。ただし、NOARCHIVELOGモードを使用している場合には、強いて実行することもできます。

9.4.2 ベスト・プラクティス2: RMANの使用

以前のリリースのOracle Databaseで開発された多くのデータ・ウェアハウスには、バックアップとリカバリのためのRMANが統合されていないことがあります。

ただし、ARCHIVELOGモードを利用する理由が多数あるように、RMANを採用する強力な理由も多数あります。次の点を考慮してください。

問題のないバックアップおよびリカバリ
破損ブロックの検出
アーカイブ・ログの検証と管理
ブロック・メディア・リカバリ(BMR)
メディア・マネージャとの容易な統合
バックアップとリストアの最適化
バックアップとリストアの検証
停止時間の不要なバックアップ
増分バックアップ
拡張性の高いレポート

9.4.3 ベスト・プラクティス3: ブロック・チェンジ・トラッキングの使用

ブロック・チェンジ・トラッキングを有効にすると、最後の全体バックアップまたは増分バックアップ以降に変更されたブロックのみを読み書きすることにより、増分バックアップを速く完了できるようになります。

データ・ウェアハウスでは、通常はデータベースの変更率が低いかもしくは中程度であるため、この機能はきわめて有効です。

関連項目:

ブロック・チェンジ・トラッキングの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

9.4.4 ベスト・プラクティス4: RMANマルチセクション・バックアップの使用

bigfile表領域が出現したため、データ・ウェアハウスでは、大多数のデータファイルを管理しやすい少数のデータファイルにまとめることができます。

非常に大きなデータファイルのバックアップでは、RMANにより、ファイル内でのバックアップ操作をパラレル化する方法としてマルチセクション・バックアップが提供されます。この方法では、ファイル単位でバックアップが行われるかわりに、ファイルのセクションがパラレルでバックアップされます。

たとえば、1TBのデータファイルを100GBのバックアップ・ピース10個のセクションに分け、1TBのファイル全体を1つのファイルとしてバックアップするかわりに各セクションをパラレルでバックアップします。大きなデータファイルの全体のバックアップ時間が大幅に短縮できます。

関連項目:

マルチセクション・バックアップの構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

9.4.5 ベスト・プラクティス5: 読取り専用表領域の活用

データ・ウェアハウスが直面する重要な問題は、典型的なデータ・ウェアハウスのサイズの大きさです。高性能のバックアップ・ハードウェアを使用しても、バックアップには数時間がかかることがあります。

バックアップのパフォーマンスを改善する重要な考慮事項は、バックアップするデータ容量を最小限に抑えることです。読取り専用表領域は、データ・ウェアハウスでバックアップを行うデータ容量を削減する最も単純なメカニズムです。増分バックアップの場合でさえ、表領域が読取り専用に設定されているとバックアップとリカバリの処理が速くなります。

読取り専用表領域の利点は、データを1回のみバックアップすればよいという点です。データ・ウェアハウスに5年分の履歴データが含まれており、最初の4年分のデータを読取り専用にできる場合、理論的には、データベースの定期バックアップではデータの20%のみがバックアップされることになります。このように、データ・ウェアハウスのバックアップに必要な時間が大幅に短縮されます。

ほとんどのデータ・ウェアハウスでは、データは、時間でレンジ・パーティション化された表に格納されます。一般的なデータ・ウェアハウスでは、通常、データがアクティブなのは30日から1年の間です。この期間中であれば、履歴データはまだ更新と変更の可能性があります(たとえば、ある小売業者は購入日から30日間は返品を受け付けるため、売上データのレコードはこの期間に変更できます)。ただし、一定の時間が経過すると、データは多くの場合は静的になります。

パーティション化を利用すると、ユーザーは読取り専用のデータの静的な部分を作成できます。現在、Oracleでは、読取り専用パーティションまたは読取り専用表ではなく読取り専用表領域がサポートされています。読取り専用表領域を利用して、バックアップにかかる時間を短縮するには、一定のデータ・パーティションを読取り専用表領域に格納する戦略を立てる必要があります。ローリング・ウィンドウを実装するための2つの戦略を次に示します。

パーティション内のデータが完全に静的になる時点に達すると、定期的にスケジュールしたプロセスを実装し、現在の読取り/書込み表領域からある表領域にパーティションを移動して、その表領域を読取り専用にできます。
それぞれが少数のパーティションを含む一連の表領域を作成し、1つの表領域のデータが古くなると、定期的にその表領域を読取り/書込みから読取り専用に変更します。

データのバックアップはリカバリ・プロセスの半分にすぎないことに注意してください。データ・ウェアハウスの読取り/書込み部分を4時間でバックアップできるようにテープ・システムを構成した場合、そのデータベースの80%が読取り専用のときに完全リカバリが必要になると、そのテープ・システムではデータベースのリカバリに20時間かかることになります。

9.4.6 ベスト・プラクティス6: バックアップまたはリカバリ戦略でのNOLOGGING操作の計画

一般的に、データ・ウェアハウスの最優先事項はパフォーマンスです。データ・ウェアハウスは、オンライン・ユーザーに優れた問合せパフォーマンスを提供する必要があるだけではなく、大容量のデータを最短の時間でロードできるように、抽出、変換およびロード(ETL)プロセスでも効率が高いことが必要です。データ・ウェアハウスでよく利用されている最適化の1つは、NOLOGGINGモードを使用したバルク・データ操作の実行です。

NOLOGGINGモードをサポートするデータベース操作は、ダイレクト・パスのロード操作と挿入操作、索引作成および表作成です。操作をNOLOGGINGモードで実行すると、データはREDOログに書き込まれません(厳密には小さなメタデータのセットのみがREDOログに書き込まれます)。このモードはデータ・ウェアハウスでよく使用され、バルク・データ操作のパフォーマンスが最大で50%改善されます。

ただし、リカバリをサポートするために必要なデータがログ・ファイルに書き込まれることはないので、従来のバックアップ・メカニズムを使用してNOLOGGING操作をリカバリすることはできなくなります。さらに、NOLOGGING操作が発生したデータに対する後続の操作は、たとえその操作がNOLOGGINGモードを使用していなかったとしてもリカバリされません。NOLOGGING操作により提供されるパフォーマンスの向上のため、データ・ウェアハウスでは、一般的にETLプロセスでNOLOGGINGモードを使用することをお薦めします。

バックアップおよびリカバリ計画を考案する場合は、NOLOGGING操作の存在を考慮する必要があります。データベースがNOLOGGING操作に依存している場合、従来のリカバリ戦略(最新のテープ・バックアップからリカバリしてアーカイブ・ログ・ファイルを適用する)は適用できません。ログ・ファイルでは、NOLOGGING操作をリカバリできないためです。

覚えておく必要のある第1の原則は、NOLOGGING操作が発生しているときにバックアップを作成しないことです。このルールは、今のところ強制的には適用されないため、NOLOGGING操作とバックアップ操作が重ならないように、DBAがバックアップ・ジョブとETLジョブをスケジュールする必要があります。

NOLOGGING操作が存在するバックアップおよびリカバリには、2つのアプローチがあります。ETLバックアップまたは増分バックアップです。データ・ウェアハウス内でNOLOGGING操作を使用していない場合は、次のオプションのいずれも選択する必要はありません。アーカイブ・ログを使用してデータ・ウェアハウスをリカバリできます。ただし、次のオプションを使用すると、アーカイブ・ログを使用する方法よりもリカバリのパフォーマンスがある程度向上することがあります。また、フラッシュバック・ログおよび保証付きリストア・ポイントを使用して、データベースを前のポイント・イン・タイムにフラッシュバックすることもできます。

この項では、次の項目について説明します。

9.4.6.1 抽出、変換およびロード

ETLプロセスでは、データをデータ・ウェアハウスにロード(再ロード)するために、Oracle機能といくつかの方法の組合せが使用されます。

次の機能が使用されます。

トランスポータブル表領域

トランスポータブル表領域を使用すると、ユーザーがOracle Database間で表領域を迅速に移動できます。この方法は、データベース間で大量データを移動するのに最も効率的です。Oracle Databaseにより、プラットフォーム間で表領域を転送できる機能が提供されます。ソース・プラットフォームとターゲット・プラットフォームが異なるエンディアンネスである場合、RMANによりターゲット・フォーマットに転送されている表領域が変換されます。
SQL*Loader

SQL*Loaderにより、外部フラット・ファイルからOracle Database上の複数の表にデータがロードされます。強力なデータ解析エンジンによって、あらゆるデータ形式のデータファイルに対応できます。
データ・ポンプ(エクスポートおよびインポート)

Oracle Data Pumpにより、データベース間でデータとメタデータを高速で移動できます。このテクノロジは、Oracleのデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポート・ユーティリティの基本です。
外部表

外部表機能は、既存のSQL*Loader機能を補足する機能です。この機能により、データベース内の表にあるデータと同様に、外部ソースのデータにアクセスできるようになります。外部表をデータ・ポンプ・ドライバと一緒に使用すると、CREATE TABLE AS SELECT * FROMを使用してデータベースのデータをエクスポートしてから、データをOracle Databaseにインポートすることもできます。

9.4.6.2 抽出、変換およびロード戦略

アプローチの1つは、定期的にデータベースのバックアップをして、その週全体のETLプロセスを再作成するために必要なデータファイルを保存することです。

リカバリが必要な場合、データ・ウェアハウスは最新のバックアップからリカバリされます。次に、従来のリカバリのシナリオで行われていたようにアーカイブREDOログを適用してロールフォワードを行うかわりに、データ・ウェアハウスはETLプロセスをリプレイすることでロールフォワードを行います。この方法では、ETLプロセスが容易に再生できることが前提です。通常、再生時にはETLプロセスごとに一連の抽出ファイルが格納されます。

この方法の実装例としては、データ・ウェアハウスのバックアップを毎週末に作成し、ETLプロセスのサポートに必要なファイルを毎晩格納します。データベースをリカバリするために最大で7日間のETL処理を再適用する必要があります。データ・ウェアハウス管理者は、テープからのリカバリ速度と以前のETL実行のパフォーマンス・データに基づいて、データ・ウェアハウスのリカバリにかかる時間を簡単に予測できます。

基本的に、データ・ウェアハウス管理者は、NOLOGGING操作によってETLプロセスのパフォーマンスを改善できますが、リカバリ・プロセスが少し複雑になり自動処理が減るという代償があります。多くのデータ・ウェアハウス管理者はこれを望ましいトレードオフととらえています。

この方法の1つの短所は、データ・ウェアハウスで行われた関連する変更をすべて管理する負担がデータ・ウェアハウス管理者にかかることです。この方法では、ETLプロセスに含まれない変更は取得されません。たとえば、データ・ウェアハウスによってはユーザーが独自の表やデータ構造を作成できます。このような変更はリカバリ中に失われてしまいます。

この制限はエンドユーザーに伝達される必要があります。かわりに、エンドユーザーに対して、すべてのプライベート・データベース・オブジェクトを別の表領域に作成するように指示し、リカバリ時には、DBAが従来のリカバリでその表領域をリカバリし、残りのデータベースはETLプロセスを再実行する方法でリカバリすることもできます。

9.4.6.3 増分バックアップ

NOLOGGING操作が存在する場合、バックアップおよびリカバリ戦略に自動化を取り入れるにはRMANの増分バックアップ機能を利用します。

増分バックアップは、直前のバックアップ以降に変更されたブロックのみをバックアップする機能です。データファイルの増分バックアップは、ブロック単位でデータの変更を取得します。データファイルのすべての使用済ブロックのバックアップは必要ありません。データファイルのすべてのブロックに変更がないかぎり、結果として生成されるバックアップ・セットは、通常は完全データファイル・バックアップよりも小さくて効率的です。

ブロック変更トラッキングを有効にする場合は、Oracle Databaseにより、すべてのデータベースの変更の物理的な場所が追跡されます。RMANはチェンジ・トラッキング・ファイルを自動的に使用して、増分バックアップで読み取る必要があるブロックを判別します。ブロック・チェンジ・トラッキング・ファイルのサイズは、データベースの合計サイズのおよそ30000分の1です。

関連項目:

ブロック・チェンジ・トラッキングの詳細と有効化の方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

9.4.6.4 増分アプローチ

このアプローチを使用する通常のバックアップおよびリカバリ計画は、毎週末データ・ウェアハウスをバックアップし、ETLプロセスが完了した後は毎晩データ・ウェアハウスの増分バックアップを取得します。

増分バックアップは従来のバックアップと同様に、NOLOGGING操作と同時には実行できません。データ・ウェアハウスをリカバリするには、データベース・バックアップをリストアし、次に毎晩の増分バックアップを再適用します。

NOLOGGING操作はアーカイブ・ログには取得されませんが、NOLOGGING操作によるデータは増分バックアップに含まれます。さらに、前のアプローチとは異なり、このバックアップおよびリカバリ計画は、RMANを使用して管理できます。

9.4.6.5 フラッシュバック・データベースと保証付きリストア・ポイント

フラッシュバック・データベースは、広範に及ぶ論理エラーを修正するための高速で連続的なポイント・イン・タイム・リカバリ方法です。

フラッシュバック・データベースは、フラッシュバック・ログと呼ばれる別のロギングを利用します。これは、高速リカバリ領域に作成され、リカバリ・ニーズに対応するようにユーザーが定義した期間にわたり保持されます。これらのログには、ブロックの更新時に元のブロック・イメージが記録されます。

フラッシュバック・データベース操作が実行されると、変更されたデータに対応するブロック・イメージのみがリストアおよびリカバリされます。これに対して、従来のデータファイル・リストアでは、バックアップ内のすべてのブロックをリストアしないとリカバリを開始できませんでした。フラッシュバック・ログはREDOログと比例するように作成されます。

非常に大規模で頻繁に使用されるデータベースでは、連続するポイント・イン・タイム・リカバリのために必要なすべてのフラッシュバック・ログを保存しておくことは実現不可能です。ただし、場合によっては、バッチ実行中の論理エラーの発生に備えて、特定のポイント・イン・タイム・スナップショットを作成する必要があります(たとえば、毎晩のバッチ・ジョブの直前など)。このシナリオでは、フラッシュバック・ロギングを有効化せずに保証付きリストア・ポイントを作成できます。

保証付きリストア・ポイントが作成されると、他のポイント・イン・タイムではなく保証付きリストア・ポイントに対するフラッシュバック・データベースのみに対応するように、フラッシュバック・ログが管理され、領域が節約されます。たとえば、保証付きリストア・ポイントは、ロギングなしのバッチ・ジョブの前に作成できます。保証付きリストア・ポイントを作成する前の1時間以内にロギングなしの操作が行われていないかぎり、保証付きリストア・ポイントへのフラッシュバック・データベースによりロギングなしのバッチ・ジョブが元に戻されます。ロギングなしのバッチ・ジョブが終了した後の時刻にフラッシュバックするには、バッチ・ジョブが終了して少なくとも1時間経過してから保証付きリストア・ポイントを作成します。

このシナリオにおいて、保証付きリストア・ポイントに対するフラッシュバック・ログ領域の見積りは、保証付きリストア・ポイントを保持する日数の間にデータベースのどれくらいの容量が変更されるかによって異なります。たとえば、保証付きリストア・ポイントを2日間保持し、データベースで100GB分の変更を予定する場合、フラッシュバック・ログとして100GBを用意します。100GBは、変更の回数ではなく、保証付きリストア・ポイントの作成後に変更されるデータベースのサブセットを表します。

9.4.7 ベスト・プラクティス7: すべての表領域は同等に処理されない

バックアップおよびリカバリという観点で見ると、データ・ウェアハウス内のすべての表領域が同等に重要だということはありません。

データベース管理者は、この情報に基づいて、より効率的なバックアップおよびリカバリ計画を必要に応じて考案できます。バックアップおよびリカバリの基本粒度は表領域なので、異なる表領域には異なるバックアップおよびリカバリ計画が存在する可能性があります。

最も基本的なレベルでは、一時表領域はバックアップする必要がありません(RMANにより規定されるルール)。さらに、一部のデータ・ウェアハウスでは専用のスクラッチ表領域があり、ユーザーが一時的な表や増分結果を格納できます。このような表領域は明示的な一時表領域ではありませんが、本質的には一時表領域として機能します。業務要件によっては、このような表領域をバックアップしてリストアする必要がないこともあります。かわりに、このような表領域に損害が発生した際には、ユーザーが自らのデータ・オブジェクトを再作成します。

データ・ウェアハウスの多くは、その他のデータより重要な一部データを持っています。たとえば、データ・ウェアハウス内の売上データは非常に重要で、リカバリの段階では、このデータはできるだけ早くオンラインにする必要があります。ただし、同じデータ・ウェアハウスにおいて、企業Webサイトのクリックストリーム・データを格納する表は業務にとってそれほど重要ではありません。業務の面では、このデータが数日間オフラインになっていても許容されます。つまり、データベース・ファイルが損失した場合に、クリックストリーム・データが数日間なくても問題ありません。このシナリオでは、売上データを含む表領域は頻繁にバックアップする必要があるが、クリックストリーム・データを含む表領域のバックアップは1週間もしくは2週間に1回ですみます。

最も単純なバックアップおよびリカバリ・シナリオでは、データベースのすべての表領域を同じように扱いますが、Oracle Databaseでは、DBAが必要に応じて表領域ごとにバックアップおよびリカバリ・シナリオを調整できるような柔軟性を備えています。