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

この項の内容は次のとおりです。

抽出、変換およびロード

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にインポートすることもできます。

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

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

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

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

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

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

増分バックアップ

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

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

増分方法

このアプローチを使用する通常のバックアップおよびリカバリ計画は、毎週末データ・ウェアハウスをバックアップし、ETLプロセスが完了した後は毎晩データ・ウェアハウスの増分バックアップを取得します。増分バックアップは従来のバックアップと同様に、NOLOGGING操作と同時には実行できません。データ・ウェアハウスをリカバリするには、データベース・バックアップをリストアし、次に毎晩の増分バックアップを再適用します。

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

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

フラッシュバック・データベースは、広範に及ぶ論理エラーを修正するための高速で連続的なポイント・イン・タイム・リカバリ方法です。フラッシュバック・データベースは、フラッシュバック・ログと呼ばれる別のロギングを利用します。これは、高速リカバリ領域に作成され、リカバリ・ニーズに対応するようにユーザーが定義した期間にわたり保持されます。これらのログには、ブロックの更新時に元のブロック・イメージが記録されます。

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

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

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

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