DataGuardは、Oracle7 R7.3より実装されていたスタンバイデータベース機能を強化したもので、地震や火災などの災害からデータベースを保護する手段の1つとしてOracle9iから実装されている。遠隔地に本番系（プライマリ）データベースと同じデータを保持する待機系（スタンバイ）データベースを1つ以上設置し、プライマリデータベースへの変更をREDOデータ（またはアーカイブREDOログ）としてスタンバイデータベースへ転送、反映することにより、万が一障害が発生した場合にも迅速な対応を実現する。

●スタンバイデータベースの種類

スタンバイデータベースには「フィジカル・スタンバイデータベース」と「ロジカル・スタンバイデータベース」がある。フィジカル・スタンバイデータベースは、物理的にプライマリと同一になるようコピーしたものであり、プライマリデータベースから転送されたREDOデータを、リカバリ機能を用いて直接スタンバイデータベースに反映させる。プライマリデータベースのバックアップを兼ねることが可能で、データ規模が大きい場合にはバックアップ処理のオーバーヘッドを削減できる。

一方、ロジカル・スタンバイデータベースは、プライマリデータベースから転送されたREDOデータをSQLに変換してスタンバイデータベースに適用するもので、プライマリデータベースと物理的に同じ構成である必要はない。フィジカルと比べるとREDOを適用する仕組みがやや複雑にはなるが、REDOログを適用しながらスタンバイ側で検索処理を実行できるという利点がある。

図1　ARCHプロセスでの転送（フィジカル・スタンバイデータベース）

●スタンバイデータベースへのデータ転送方法

スタンバイデータベースへREDOデータを転送するには、ARCHプロセスによりアーカイブREDOログファイルを転送する方法（図1）と、LGWRプロセスによりREDOエントリを同期転送する方法（図2）がある。フィジカル・スタンバイデータベースでは、MRPプロセスがリカバリ機能を使用しながらREDOログをスタンバイデータベースに適用する。ロジカル・スタンバイデータベースの場合、LSPプロセスがコーディネーターとなり、それぞれの役割を果たす複数のサーバプロセスを制御しながらREDOログをSQLに変換してスタンバイデータベースへ適用する（図3）。

図2　LGWRプロセスでの転送（フィジカル・スタンバイデータベース）

図3　SQLの適用（ロジカル・スタンバイデータベース）

検証1：スタンバイデータベースを構成した場合のプライマリ側への影響度

スタンバイデータベースを構成した場合、プライマリデータベースのスループットにどう影響するのか。これについてアシストではフィジカル・スタンバイデータベースとロジカル・スタンバイデータベースをLGWRプロセスによる同期転送をおこなうことで比較した。その結果、フィジカル・スタンバイデータベースではシングルデータベース構成と遜色ないスループットを維持することが確認できた。ロジカル・スタンバイデータベース構成では、変更履歴をSQLに変更するための補足情報がREDOログに追加される。そのため、プライマリデータベースで生成されるREDOログが増加し、スループットへの影響を若干考慮しなければならないことがわかった。

検証2：リアルタイム適用のフェイルオーバー時間への影響

Oracle9iでは、LGWRプロセスによるREDOの同期転送機能が実装され、障害発生時のデータ損失を極力抑えられるようになったが、スタンバイデータベースへの適用までにタイムラグがあった。Oracle Database 10gからは、スタンバイデータベース側でREDOデータを受信した時点ですぐに変更を適用する「リアルタイム適用機能」が実装されている。DataGuardは災害対策用の構成であり、障害発生時にプライマリデータベースからスタンバイデータベースに切り替わるフェイルオーバー時間は重要な要件となる。このリアルタイム適用機能により、障害発生時のフェイルオーバー時間の大幅短縮が期待できる。

実際に障害発生時にフェイルオーバー時間は短縮されるか、またREDOログを適用する役割を担うプロセスをパラレル化（フィジカルの場合はMRPプロセス、ロジカルの場合はSQLに変換する部分のプロセス）することでフェイルオーバー時間の短縮が図れるかを検証した。

フィジカル・スタンバイ構成でもロジカル・スタンバイ構成でも、リアルタイム適用をおこなった場合は従来とくらべフェイルオーバー時間が短縮された。ただし、パラレル化の効果はフィジカル・スタンバイ構成とロジカル・スタンバイ構成で異なる結果となった。

フィジカル・スタンバイ構成では、リアルタイム適用をおこなわずに処理を最大8までパラレル化したところ、並列度が増すにしたがってフェイルオーバー時間が短縮されたが、リアルタイム適用の場合パラレル化による差異はみられなかった。リアルタイム適用によりフェイルオーバー時に適用しなければならない変更履歴が最小化されているため、パラレル化の効果が得られなかったと思われる。ロジカル・スタンバイ構成でリアルタイム適用をおこなわずパラレル化にすると、あまり効果はなかったが、リアルタイム適用をおこなった場合はパラレル化の効果は高かった。リアルタイム適用をおこなわない場合、アーカイブ済みREDOログから情報を読み込む役割のプロセスがパラレル化の対象とならないためだと思われる（表1）。

さらに、フィジカル・スタンバイ、ロジカル・スタンバイでリアルタイム適用を採用した場合の、プライマリ側のトランザクションスループットに与える影響について検証した。その結果、リアルタイム適用により若干のオーバーヘッドが確認できた。ただし、リアルタイム適用によりフェイルオーバー時間の短縮効果が大きいため、システム要件に見合った選択をお勧めする。

表1　リアルタイム適用のフェイルオーバー時間への影響

人為的エラーに対応するためにフラッシュバックデータベースを設定している場合、フラッシュバックデータベースログの生成負荷が問題になる場合がある。データベースを過去のある時点の状態に戻す必要がある場合、スタンバイデータベース側でフラッシュバックデータベースを実施することで、プライマリデータベースからフラッシュバックデータベースログ生成の負荷を排除して実装することができる。スタンバイ側にフラッシュバックデータベースを設定した場合、プライマリ側のスループットにほとんど影響を与えることなくフラッシュバック・データベースを実装できることが確認できた。

フィジカル・スタンバイデータベースは、プライマリデータベースのバックアップを使用して容易に構築できるほか、リアルタイム適用をおこなうことでフェイルオーバー時間の短縮、スタンバイ側のバックアップとしての利用、またフラッシュバックデータベースとの連携によりプライマリ側のスループットを損なわずに論理障害に対応できるという利点をもつ。データ量が多く日々のバックアップの取得が困難な場合や、災害対策用の遠隔サイトとしての利用が最適だ。また、ロジカル・スタンバイデータベースはフィジカルにくらべ構成は複雑だが、リアルタイム適用をおこなうことでフェイルオーバー時間の短縮や最新データをスタンバイ側で参照できるなどの利点を確認できた。トランザクション負荷が比較的軽いシステムで、災害対策と参照用データベースを同時に保持したい場合に検討できる構成だと思われる。