Oracle Database の災害対策について

*以下は、サポート契約締結中のお客様に毎月配信しているサポートレターより一部抜粋して掲載しています。

データベースの災害対策とは

RDBMS はデータの一貫性を保ったまま大量データを扱える特性を持っており、この特性を活かしてビジネス上の根幹となる重要なデータが格納されることが多々あります。商用のRDBMS 製品はシステムの停止やデータ損失を防ぐために様々な機能によって可用性を高める手段を提供していますが、大規模な災害によってデータベースを稼働させているハードウェアが被害を受けた場合には、データベースも停止が避けられません。

このため、ミッションクリティカルなシステムに代表される、長時間の停止が許容されないシステムにおいては、同一システムが稼働できるハードウェアを遠隔の複数個所に配置して、災害によるシステムの全停止を防止することが一般的です。多くの商用 RDBMS 製品ではこのような運用に対応するために、拠点間でレプリケーションを行って同一のデータを保持することが可能となっています。

Oracle Database のレプリケーション機能

Oracle Database では、複数の拠点でデータベースを運用するためのレプリケーション機能として、以下の機能が用意されています。

  1. Oracle Data Guard
  2. Oracle Goldengate
  3. アドバンスト・レプリケーション

ただし、3のアドバンスト・レプリケーション機能は12cでは非推奨のため、本項では1, 2 の概要および両者の優位性を比較していきます。

Oracle Data Guard

Oracle Data Guard はいずれかの拠点がプライマリのサイトとなり、他のサイトに変更の履歴 (REDO情報) を伝播して適用することでレプリケーションを実現する機能です。本機能は Oracle Database Enterprise Edition に含まれており、該当ライセンスをお持ちのお客さまは追加のオプション購入なしで使用が可能です。

Data Guard には大きく分けてフィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの2つの方式があり、それぞれ以下のような特長があります。

フィジカル・スタンバイ・データベース

プライマリサイトと物理的に同一構成を持つデータベースに対して同一の REDO 情報を適用することで、完全に同一の複製データベースを別サイトに用意できる機能です。

  • 表 / 索引のデータはもちろん、データファイルなどの物理的な構成も一致しており、データベース外部からは完全な同一データベースとして扱うことができる
  • スタンバイサイトは常時リカバリ処理を行っている状態となるため、読み書き不可(有償の Active Data Guard オプションにより読み取りを行うことは可能)

ロジカル・スタンバイ・データベース

プライマリサイトの REDO 情報を論理的に同一のSQLに変換し、順序を保って適用することで、論理的に同一のデータを持つデータベースを別サイトに用意できる機能です。

  • スタンバイサイトでも読み書きが可能(ただし、整合性担保のため、少なくとも複製のターゲットとなる表については更新を不可に設定することが必要)
  • マテリアライズド・ビューやいくつかの特殊なデータ型(ROWID等)に非対応
  • "SYSDATE" など、環境に依存するデータを書き込むSQLについては、プライマリサイトと異なるレコードがスタンバイサイトに生成される可能性があり、アプリケーション側での対策が必要
  • フィジカル・スタンバイ・データベースを起点として構築するが、その後の同期時には別のデータベースに論理的に同一の SQL を適用している扱いとなる(プライマリサイトの REDO ログをスタンバイサイトに適用するなどの操作は不可)

大雑把にいえば、フィジカル・スタンバイ方式は複製としての完全性が高い反面リソース活用率が低く、ロジカル・スタンバイ方式は完全な複製ではありませんがリソース活用率が高くなります。

なお、当社サポート窓口へのお問い合わせ実績では、フィジカル・スタンバイ方式に関するお問い合わせがロジカル・スタンバイ方式に関するお問い合わせよりも圧倒的に多く、採用実績の面ではフィジカル・スタンバイ方式が多くを占めているものと推測されます。

私見ではありますが、Data Guard 構成により災害対策を行う場合には、要件として運用系の素早い切り替えや切り戻しが可能であることを求められることが多いため、これらの点で優位性があるフィジカル・スタンバイ方式が採用されやすいのかもしれません。また、ロジカル・スタンバイ方式はデータベースレベルでデータの完全な一致が保証されないなど、運用面での制約も影響しているように思われます。

※ 日本国内にロジカル・スタンバイ方式の採用実績がないということはなく、大手企業での採用実績も存在します。

Oracle GoldenGate

Oracle GoldenGate (GG) は Oracle Database から独立したGG独自の専用プロセスを介して、任意のマスターサイトのREDO情報をSQLに変換し、スレーブサイトに伝播して逐次適用します。GG は Oracle Database とは別製品となっており、使用にはライセンスの購入が必要です。

同期の方式上、Data Guard のロジカル・スタンバイ方式と同様に論理的なレベルでのレプリケーションとなりますが、その他にも以下のような特長があります。

  • サイト間で正 / 副の概念はなく、マルチマスター(双方向)のレプリケーションを行うことが可能
  • バージョンの異なるデータベース間や Standard Edition でも複製が可能
  • スレーブサイトでも読み書きが可能
  • 表単位など細かい粒度でのレプリケーションが可能
  • 事前にフィルタを設定しておき、特定の行を同期の対象外にするといった詳細な同期設定が可能
  • マスター / スレーブ間のデータ整合性を担保する仕組みは持たないため、特に双方向レプリケーションを行う場合には競合を発生させない設計が必要
  • 一部の SQL には非対応

GG では双方向レプリケーションが可能なため、複数の拠点に配置したデータベースを相互に対等な Active-Active 構成で運用でき、災害などでいずれかの拠点のシステムが全停止した場合でも、復旧まで同期が停止するだけで、そのまま運用を継続できます。サイト間の整合性を保つために運用は複雑になりがちですが、バージョンの異なる新旧環境間で同期が取れるなど運用に融通が効きやすいこともあり、当社のお客さまでも高い可用性とリソース活用率の両立を評価しての採用実績が複数あります。

Oracle Data Guard と Oracle GoldenGate の比較

Oracle Data Guard と Oracle GoldenGateは上記のような特性を持っています。それぞれに適した要件があるため、一概にどちらが優れているということはありませんが、相違点や優位性については以下のように纏めることができます。

1) サイト間の関係
Data Guard : 正 / 副があり、制限なく使用できるのはプライマリサイトのみ
GoldenGate : 正 / 副がなく、マルチマスター構成も可能
2) スイッチオーバー (運用系の切り替え)
Data Guard : 切り替え機能を持つ
GoldenGate : 製品内部レベルでの切り替えは不要(アプリケーションの接続先など運用設計での対処は別途必要)
3) スタンバイ / スレーブサイトの活用
Data Guard : 一般的なフィジカル・スタンバイ方式では読み取りも不可
GoldenGate : 読み書き可能(不整合を避けるための制限は運用設計にて考慮が必要)
4) 同期の保証
Data Guard : トランザクションレベルで完全に同期を取ることも可能(通常は性能を重視して REDO 情報の適用は非同期で行う)
GoldenGate : 同期は順序が保証されるだけで完全ではなく、遅延の考慮が必要
5) レプリケーション対象
Data Guard : 同一バージョン、パッチレベルであることが必須(OS については 11gより相互に異なっていても可)
GoldenGate : 異なるバージョン、エディション間のレプリケーションに対応
6) レプリケーションの粒度
Data Guard : データベースに行われたすべての変更を伝播
GoldenGate : 伝播の対象を細かく設定・フィルタリングすることが可能
7) レプリケーションの制約
Data Guard : フィジカル・スタンバイ方式では全ての処理に対応
GoldenGate : 一部の処理はレプリケーションが不可能
8) ライセンス
Data Guard : Oracle Database Enterprise Edition に含まれる
GoldenGate : 別途 GoldenGate のライセンスが必要

まとめ

Oracle Data Guard と Oracle GoldenGate はいずれも複数拠点でのデータベース運用を可能とし、自然災害などによる長期間のシステム停止を回避する手段を提供します。
高い可用性を求められるシステムの構築・更改などにあたっては、それぞれの特性を踏まえての災害対策の実装をご検討ください。

※ 本記事は 2017 年 5 月 26 日時点での情報となります。ご紹介した内容について、今後変更される可能性がございます。あらかじめご了承ください。

(オラクル事業部 サポート・サービス担当 平林)

Oracle Database の災害対策について