RAC、Data Guard、およびStreamは、Oracleの高可用性システムにおける3つのツールです。それぞれのツールは単独でも、あるいは組み合わせても使用できます。これらは異なる重点を備えており、さまざまなシナリオに適用されます。
RACは、単一障害点の解消や負荷分散において優れています。そのため、RACは24時間365日稼働が求められる重要なシステムで一般的に採用されます。ただし、RACソリューションではデータが1つのコピーしか存在しません。ストレージの障害はRAIDなどの仕組みで回避できますが、データ自体に冗長性がなく、単一障害点の影響を受けやすくなっています。
Data Guardは冗長データを通じてデータ保護を提供します。ログ同期メカニズムを活用することで、Data Guardは冗長データとプライマリデータ間の同期を保証します。この同期は、リアルタイム、遅延、同期式、非同期式など、さまざまな形式で実現可能です。Data Guardは中小企業におけるリモートディザスタリカバリや高可用性ソリューションで一般的に使用されます。スタンバイマシン上で読み取り専用のクエリを実行することでプライマリデータベースのパフォーマンス負荷を軽減することは可能ですが、Data Guardは主にパフォーマンス向上を目的としたものではありません。
StreamsはOracle Advanced Queueを基盤として構築され、データ同期を実現し、複数のレベルで柔軟な設定を提供します。Oracleは豊富なAPIを含む充実した開発支援を提供しているため、Streamsはアプリケーションレベルでのデータ共有に最適です。
Data Guardとは何ですか？
Data Guard環境には少なくとも2つのデータベースが存在します。外部にサービスを提供するオープン状態のプライマリ・データベースと、回復状態にあるスタンバイ・データベースです。実行中はプライマリ・データベースがクライアントにサービスを提供し、ユーザー操作はオンラインおよびアーカイブ・ログに記録され、その後ネットワーク経由でスタンバイ・データベースに転送されます。これらのログはスタンバイ・データベース上で再適用され、2つのデータベース間のデータ同期を実現します。
Oracle Data Guardはこのプロセスをさらに最適化し、ログ伝送および回復タスクを自動化および効率化するとともに、データベース管理者（DBA）の作業を簡略化するためのさまざまなパラメータやコマンドを提供します。
ソフトウェアやハードウェアのアップグレードなど、プライマリデータベースのシャットダウンが必要な因子が予測される場合、スタンバイデータベースをプライマリデータベースに切り替えてクライアントへのサービスを継続できます。これにより、サービスの停止時間を最小限に抑え、データの完全性を保証します。予期せぬ問題によりプライマリデータベースが利用不能になった場合、スタンバイデータベースを強制的にプライマリデータベースに切り替えて、クライアントへのサービスを継続できます。このような場合のデータ損失の程度は、設定されたデータ保護レベルに依存します。したがって、プライマリデータベースとスタンバイデータベースは特定のデータベースに固定されたものではなく、概念的な役割です。
Data Guard アーキテクチャ
Data Guard アーキテクチャは次の3つの機能部分に分けることができます:
1) リドゥ送信:
プライマリデータベースの実行中、リドゥログは絶え間なく生成され、スタンバイデータベースへ送る必要があります。この送信処理は、プライマリデータベースのLGWRまたはARCHプロセスによって行われます。アーカイブ先によって異なる方法を使用することができますが、特定の送信先に対しては1つの方法しか選択できません。プロセスの選択は、データ保護機能とシステム可用性に大きな影響を与えます。
2) 受信の再実行：
スタンバイデータベースにおけるRFS（リモートファイルサーバー）プロセスは、ログを受信し、プライマリデータベースのログ伝送方法やスタンバイデータベースの位置に基づいて、スタンバイRedoログまたはアーカイブログファイルのいずれかに書き込みます。ログがスタンバイRedoログファイルに書き込まれる場合、プライマリデータベースでログスイッチが発生すると、スタンバイデータベースのスタンバイRedoログでもログスイッチが発生し、そのスタンバイRedoログがアーカイブされます。ログがアーカイブログに書き込まれる場合は、この動作自体がアーカイブ操作と見なされます。
3) リドゥ適用：
リドゥ適用サービスは、スタンバイデータベース上でプライマリデータベースのログを再実行する役割を担い、これにより2つのデータベース間のデータ同期を実現します。
スタンバイデータベースがログを再生する方法によって、物理スタンバイと論理スタンバイの2種類があります。
Redo Applyが発生するタイミングに基づいて、以下の2つのタイプもあります：
a) リアルタイム適用： この方法では、スタンバイリドログを使用する必要があります。スタンバイリドログにログが書き込まれるたびに、リカバリがトリガーされます。この方法の利点は、残りのログがリアルタイムで既にリカバリーされているため、データベースの切り替えに必要な時間を短縮できることです。
b) アーカイブ先に適用：この方法は、プライマリデータベースでログの切り替えが発生し、スタンバイデータベースでアーカイブがトリガーされるときにログを適用します。アーカイブ処理が完了した後にリカバリが開始されます。これはデフォルトのリカバリモードでもあります。
物理スタンバイと論理スタンバイ
スタンバイデータベースには2つの種類があります。物理スタンバイと論理スタンバイです。
1. 物理スタンバイ：
物理スタンバイデータベースはプライマリデータベースと同じです。Data GuardはREDO適用によって物理スタンバイデータベースを維持します。一般的に、物理スタンバイがREDO適用を行っていない場合、READ ONLYモードで開くことができます。もしデータベース内でフラッシュバック領域が指定されている場合、一時的にREAD WRITEモードに切り替えて操作を行うことも可能です。必要な操作が完了したら、フラッシュバックデータベース機能を使用して、READ WRITEモードになる前の状態にデータベースを復元することができます。これにより、プライマリデータベースからのREDOデータの適用を再度続けることが可能になります。
注記：Oracle 11gでは、物理スタンバイのアプリケーション機能が強化されています。このバージョンでは、物理スタンバイがOPEN READ ONLYモードの状態でもREDOデータの適用を続けることが可能となっています。これは物理スタンバイデータベースの使いやすさを大幅に向上させます。
物理スタンバイの特徴：
1) ディザスタリカバリおよび高可用性： 物理スタンバイは、ディザスタリカバリおよび高可用性のための強固かつ効率的なソリューションを提供します。スイッチオーバー／フェールオーバーの管理を簡素化し、計画的または予期せぬダウンタイムを短縮します。
2) データ保護：物理スタンバイ・データベースにより、Data Guardは予期せぬ災害が発生してもデータ損失を最小限に抑えることを保証します。
3) プライマリデータベースのワークロードを軽減： バックアップや読み取り専用のクエリなど特定のタスクを物理スタンバイデータベースにオフロードすることにより、プライマリデータベースのCPUおよびI/Oリソースを節約できます。
4) 性能の向上： Physical Standbyデータベースで使用されるREDO適用メカニズムは、SQLコードの実行をバイパスしてリカバリの最下位レベルで動作します。これにより、最大限の効率性とパフォーマンスが実現されます。
2. 論理スタンバイ：
論理スタンバイデータベースもプライマリデータベース（またはそのバックアップやレプリカ、例えば物理スタンバイ）に基づいて作成されます。したがって、初期状態では物理スタンバイデータベースと似ています。ただし、論理スタンバイはREDOデータをSQL実行を通じて適用するため、物理ファイル構造やデータの論理構造さえもプライマリデータベースと異なる場合があります。
物理スタンバイとは異なり、論理スタンバイは通常READ WRITEモードでオープンされ、ユーザーがいつでもアクセスできるようになります。つまり、論理スタンバイはOPEN状態のままSQLが実行されることを意味します。これには利点と欠点があります。SQL実行の性質上、論理スタンバイでは特定のデータ型や一部のDDL/DML文に対して運用制限があります。サポート対象外のデータ型はDBA_LOGSTDBY_UNSUPPORTEDビューで確認できます。このようなデータ型が使用されている場合、データベースの完全な一貫性を保証することはできません。
論理スタンバイのREAD WRITEモードを開くことで、報告システムとしての利用に適しており、システムの負荷を軽減します。
論理スタンバイの特徴：
災害復旧、高可用性、データ保護などの物理スタンバイに関する前述の特徴に加えて、ロジカルスタンバイには以下の特徴があります：
1) 待機サーバーにおけるハードウェアリソースの効率的な活用： 論理待機データベースを使用して、追加のインデックスやマテリアライズドビューを作成し、特定のビジネスニーズに対応させることができます。また、プライマリデータベースには存在しない新しいスキーマを作成し、プライマリデータベース上で適切でないDDLやDML操作を実行することも可能です。
2) プライマリデータベースのワークロードをオフロード： 論理スタンバイデータベースをプライマリデータベースと同期した状態でオープンしたままにすることで、データ保護およびレポート処理の両方に利用できます。これにより、プライマリデータベースからレポート作成やクエリ処理の負荷が軽減され、貴重なCPUおよびI/Oリソースを節約できます。
3) スムーズなアップグレード： Logical Standbyは、データベースのクロスバージョンアップグレードやパッチ適用などの運用に使用できます。
データ保護モード
Data Guardは、最大保護（Maximum Protection）、最大可用性（Maximum Availability）、最大性能（Maximum Performance）の3つのデータ保護モードを提供します。
1. 最大保護：
このモードは、データ損失がゼロになることを保証します。これを実現するため、すべてのトランザクションはコミット前にローカルのオンラインリドログに書き込まれるだけでなく、同時にスタンバイデータベース内のスタンバイリドログにも書き込まれる必要があります。プライマリデータベースでコミットが可能になるには、少なくとも1つのスタンバイデータベース（複数存在する場合）でリドデータが利用可能である必要があります。スタンバイデータベースが何らかの障害（例：ネットワーク切断）により利用不能になると、プライマリデータベースはシャットダウンされ、データ損失を防ぎます。
このモードを有効にするには、スタンバイデータベースをスタンバイREDOログと共に構成し、プライマリデータベースがスタンバイデータベースへのアーカイブのためにLGWR、SYNC、AFFIRMモードを使用する必要があります。
2. 最大可用性：
このモードはプライマリデータベースの可用性に影響を与えることなく、最高レベルのデータ保護戦略を提供します。最大保護と同様に、トランザクションはコミット前に少なくとも1つのスタンバイデータベースのスタンバイREDOログに記録される必要があります。ただし、スタンバイデータベースに障害が発生してアクセス不能になった場合、プライマリデータベースはシャットダウンする代わりに自動的に最大パフォーマンスモードに切り替わります。スタンバイデータベースが復旧すると、プライマリデータベースは自動的に最大可用性モードに戻ります。
このモードはデータ損失を最小限に抑えることを目的としていますが、絶対的なデータの整合性を保証するものではありません。最大保護と同様に、このモードではスタンバイ・データベースがスタンバイ・リドログを構成し、プライマリ・データベースがLGWR、SYNC、AFFIRMモードを使用してスタンバイ・データベースにアーカイブする必要があります。
3. 最大パフォーマンス:
このモードは、プライマリデータベースのパフォーマンスに影響を与えることなく、最高レベルのデータ保護戦略を提供します。トランザクションはいつでもコミット可能であり、現在のプライマリデータベースからのREDOデータは少なくとも1つのスタンバイデータベースに書き込まれる必要がありますが、これは非同期で実行することも可能です。理想的なネットワーク環境では、このモードはプライマリデータベースのパフォーマンスにごくわずかな影響を与えるだけで、最大可用性に近いデータ保護を提供できます。これはスタンバイデータベースを作成するときのデフォルト保護モードです。LGWR ASYNCまたはARCHプロセスのいずれかを使用して実現可能であり、スタンバイデータベースに対してスタンバイREDOログは必須ではありません。
データ保護モードを変更する手順：
1. データベースをシャットダウンし、マウント状態で再起動します。もしRAC構成の場合は、すべてのインスタンスをシャットダウンし、マウント状態で1つのインスタンスのみを起動します。
2. 次の構文を使用してモードを変更します：
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
例えば: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. データベースを開く：ALTER DATABASE OPEN;
4. 変更後のデータ保護モードを確認してください：
SQL>select protection_mode,protection_level from v$database;
ログ適用サービス
Data Guardは、REDOを適用することによりプライマリデータベースとスタンバイデータベース間の一貫性を保証します。このプロセスを裏で静かに支えているのが、有名なログ適用サービスです。ログ適用サービスには次の2種類があります:
1. REDO適用: 物理的なスタンバイデータベース専用で、メディアリカバリを通じてプライマリデータベースと同期を維持します。
2. SQL適用： 論理的なスタンバイデータベース専用の機能であり、コアとなる機能はLogMinerを通じてSQL文を分析し、それをスタンバイ側で実行することです。
したがって、REDOデータを適用する際、物理的なスタンバイデータベースはMOUNT状態である必要がありますが、論理的なスタンバイデータベースはREDOデータの適用のためにREAD WRITEモードでオープンされます。ただし、保守対象のオブジェクトはデフォルトで読み取り専用に設定されており、論理スタンバイ側で直接変更することはできません。
プロフェッショナルなソリューションでOracleデータベースを保護
Oracle Data Guardは、高可用性、データ保護、ディザスタリカバリに強固なソリューションを提供します。これは、長時間のダウンタイムやデータ損失を許容できないビジネスにとって不可欠なツールです。ただし、データベース環境をさらに保護するために、プロフェッショナルなバックアップおよびディザスタリカバリソリューションを使用してOracleデータベースのバックアップを行うことをお勧めします。
Vinchin Backup & Recovery は仮想マシンと物理サーバーの両方でデータベースを保護する強力な機能を提供し、非常に自動的で柔軟かつ効率的です。Oracle DB、MySQL、SQL Server、Postgres ProおよびMariaDBなど複数のデータベースを保護でき、データベース圧縮、集中ジョブ管理、スマートバックアップ戦略、データベース稼働中のバックアップおよび高度なSQL Server/Oracleサポートを実現しています。さらに、ランサムウェア保護 機能や10種類以上の仮想プラットフォーム間での V2V移行 もサポートしています。
Vinchin Backup & Recovery は数千社の企業に選ばれており、あなたも 60日間のフル機能トライアルからこの強力なシステムを使い始めることができます！また、お問い合わせ よりご要望をお知らせください。その後、貴社のIT環境に応じたソリューションをご提供いたします。
まとめ
Oracle Data Guardは、ディザスタリカバリ、高可用性、データ保護、ワークロードバランスを包括的に提供する、企業レベルのOracleデータベース展開において不可欠なコンポーネントです。柔軟なアーキテクチャとさまざまな運用モードにより、幅広い業務ニーズおよび運用要件に適応することが可能です。
Oracleデータベースのバックアップとリカバリを簡単に実行するために、Vinchin Backup & Recoveryを選択できます。無料トライアルをお見逃しなく！
