Oracle Data Guardについて

Oracle Data GuardはDBシステムで使用できます。Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。

Oracle Data Guardの詳細は、「Oracle Data Guardの概要」を参照してください

必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者からポリシーでセキュリティ・アクセス権が付与されている必要があります。コンソールまたは(SDK、CLIまたはその他のツールを使用した) REST APIのどれを使用しているかにかかわらず、このアクセス権が必要です。権限を持っていない、または認可されていないというメッセージが表示された場合は、持っているアクセス権のタイプと作業しているコンパートメントを管理者に確認してください。

ポリシーを初めて使用する場合は、ポリシーの開始および共通ポリシーを参照してください。

関連項目

一般情報

Oracle Data Guard構成には、2つのデータベース(プライマリ・ルールに1つとスタンバイ・ロールに1つ)が必要です。プライマリ・データベースとスタンバイ・データベースは、Data Guard構成を構成します。ほとんどのアプリケーションは、プライマリ・データベースにアクセスします。スタンバイ・データベースは、トランザクション上の一貫性を持つ、プライマリ・データベースのコピーです。

Data Guard Groupは、プライマリ・データベースにリンクされた複数のローカルおよびリモート・スタンバイ・データベースを作成および管理する機能を提供し、データ保護とディザスタ・リカバリの両方に柔軟性を提供します。Data Guardグループでは、プライマリ・データベースは最大6つのスタンバイ・データベースをサポートできます。

Oracle Data Guardは、プライマリ・データベースからREDOデータを転送および適用することによってスタンバイ・データベースをメンテナンスします。プライマリ・データベースが使用不可能になった場合は、Data Guardを使用して、スタンバイ・データベースをプライマリ・ロールにスイッチオーバまたはフェイルオーバーできます。これは、複数のスタンバイ・データベースがある場合でも当てはまります。

スイッチオーバー: スイッチオーバーは、プライマリ・データベース・ロールとスタンバイ・データベース・ロールを入れ替えることができます。
フェイルオーバー: フェイルオーバーは、既存のプライマリ・データベースで障害が発生したりアクセスが不可能になった後に、スタンバイ・データベースをプライマリ・ロールに移行する。
回復: Data Guard構成で、データベースをスタンバイ・ロールに修復します。

一般的なData Guard構成では、2つのスタンバイ・データベースが一般的に使用されます。

ローカル・スタンバイ: 本番データベースと同じリージョンのスタンバイ・データベースは、フェイルオーバー・シナリオに最適で、ローカル障害(データベース、クラスタ、可用性ドメインの障害など)のデータ損失はゼロになります。この場合、アプリケーションはリモート・リージョンとの通信のパフォーマンス・オーバーヘッドなしで動作し続けるため、アプリケーションのフェイルオーバーの影響は軽減されます。
リモート(リージョン間)スタンバイ: 別のリージョンにあるリモート・スタンバイ・データベースは、通常、障害時リカバリまたは読取り専用問合せ処理のオフロードに使用されます。リモート・スタンバイ・データベースの設定により、リージョンの障害に対するデータ保護が保証されます。

一部の企業顧客は、サイト切り替え後の対称性を目的としています。たとえば、リージョン1にプライマリ・スタンバイとローカル・スタンバイの両方を持ち、リージョン2に独自のローカル・スタンバイを持つリモート・スタンバイを使用する場合があります。この構成には、3つのスタンバイ・データベースがあります。サイト・スイッチの後も、新しいプライマリ・リージョンでプライマリ・データベースとローカル・スタンバイをすぐに利用できます。

また、スナップショット(読取り/書込み)スタンバイ機能を利用して、テスト目的で別のスタンバイ・データベースを追加することで、構成を拡張できます。

Data Guard構成には、2つ以上のDBシステム(プライマリ・データベースを含むシステムとスタンバイ・データベースを含む)が必要です。データベースに対してData Guardを有効にすると、スタンバイ・データベースを含む新しいDBシステムが作成され、プライマリ・データベースに関連付けられます。

その他の要件の詳細は次のとおりです。

データベースのバージョンとエディションは同一である必要があります。26aiデータベースの場合、プライマリ・データベースとスタンバイ・データベースは同じメジャー・リリース・バージョンである必要がありますが、スタンバイ・データベースはより上位のマイナー・バージョンにできます。
Data Guardでは、Oracle Database Standard Editionはサポートされていません。(Active Data Guardには、Enterprise Edition Extreme Performanceが必要です。)
Data Guard構成内の各データベースには、Data Guard構成を格納するDBシステムの他のデータベースで使用されていない一意の名前(DB_UNIQUE_NAME)の値が必要です。ただし、プライマリ・データベースとスタンバイ・データベースは、同じデータベース名DB_NAME値を使用できます。
データベース・エディションによって、Active Data Guard (ADG)を使用できるかどうかが決まります。ADGは、Enterprise Edition Extreme Performanceでのみ使用できます。BYOLライセンス・モデルを使用しており、ライセンスにADGが含まれていない場合は、Enterprise Edition Extreme Performance用にData Guardを構成する際に、ADGが有効になっていないことを確認する必要があります。あるいは、Enterprise EditionまたはEnterprise Edition High Performanceを使用することもできます。その場合、デフォルトでADGは有効になりません。データベースCLIでのOracle Data Guardの使用を参照してください。
プライマリ・データベースとスタンバイ・データベースが同じリージョンにある場合は、両方が同じ仮想クラウド・ネットワーク(VCN)を使用する必要があります。
プライマリ・データベースとスタンバイ・データベースが異なるリージョンにある場合は、データベースごとに仮想クラウド・ネットワーク(VCN)をピアリングする必要があります。RPCを使用したリモートVCNピアリングを参照してください。
プライマリ・データベースとスタンバイ・データベースは異なるリージョンに配置できますが、同じレルムに存在する必要があります。
プライマリ・データベースとスタンバイ・データベースのSYSパスワードおよびTDEウォレット・パスワードはすべて同じである必要があります。
データベースでTDEキーにOCI Vaultを使用している場合、クロスリージョンData Guardもサポートされます。
Data Guard構成にあるDBシステムのサブネットに対してセキュリティ・リストのイングレス・ルールおよびエグレス・ルールは、該当するポート間でTCPトラフィックが移動できるように構成します。作成するルールがステートフル(デフォルト)であることを確認します。

たとえば、プライマリDBシステムのサブネットでソースCIDR 10.0.0.0/24を使用し、スタンバイDBシステムのサブネットでソースCIDR 10.0.1.0/24を使用する場合は、次の例に示すようなルールを作成します。

ノート:
例のエグレス・ルールは、ポート1521に対してのみTCPトラフィックを有効にする方法を示します。これはData Guardが動作するための最小要件です。すべての送信ポート(0.0.0.0/0)でTCPトラフィックがすでに有効になっている場合は、これらの特定のエグレス・ルールを明示的に追加する必要はありません。
OCIのスタンバイ・データベースは、フィジカル・スタンバイです。
別のスタンバイ・データベースに関連付けられたスタンバイ・データベースの作成(カスケード・スタンバイ)はサポートされていません。
データベースがOCI Vaultを使用して暗号化されている場合は、Data Guard構成を作成できます。ただし、OCI Vaultでは現在、1つのリモート・リージョンへのキー・レプリケーションのみがサポートされています。その結果、OCI Vaultを使用するデータベースのクロスリージョンData Guard構成は、プライマリ・リージョンと1つのリモート・リージョンの2つのリージョンに制限されます。これらのリージョン内に複数のスタンバイ・データベースを作成できますが、3つ以上のリージョンにまたがる構成はサポートされていません。

既知の問題

リージョン間のData Guardでは、スイッチオーバーの実行後は、新しいプライマリ・データベースでデータベースKMSキーをローテーションできません。
リージョン間のData Guardでは、スイッチオーバーの実行後は、新しいプライマリ・データベースにPDBを作成できません。

プライマリDBシステムのサブネットのセキュリティ・リスト

Ingress Rules:
	Stateless: No
	Source: 10.0.1.0/24
	IP Protocol: TCPSource Port Range: All 
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.1.0/24 
	IP Protocol: TCP 
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

スタンバイDBシステムのサブネットのセキュリティ・リスト

Ingress Rules:	
	Stateless: No
	Source: 10.0.0.0/24 
	IP Protocol: TCP 
	Source Port Range: All 
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.0.0/24 
	IP Protocol: TCP 
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

ルールの作成および編集の詳細は、セキュリティ・リストを参照してください。

Oracle Data Guardの可用性ドメインおよびフォルト・ドメインに関する考慮事項

可用性とディザスタ・リカバリを向上させるために、スタンバイ・データベースが含まれるDBシステムは、プライマリ・データベースが含まれるDBシステムとは異なる可用性ドメインに配置することをお薦めします。あるデータベースでOracle Data Guardを有効にするが、(選択によって、または単一の可用性ドメイン・リージョンで作業しているために)スタンバイ・データベースがプライマリ・データベースと同じ可用性ドメインにある場合は、スタンバイ・データベースをプライマリ・データベースとは別のフォルト・ドメインに配置することをお薦めします。

ノート:

プライマリ・データベースとスタンバイ・データベースが2ノードのOracle RACデータベースであり、両方が同じ可用性ドメインにある場合、スタンバイ・データベースの2つのノードのいずれか1つのみを、プライマリ・データベースまたはスタンバイ・データベースからの他のノードを含まないフォルト・ドメインに配置できます。これは、各可用性ドメインには3つのフォルト・ドメインしかなく、プライマリ・データベースとスタンバイ・データベースには合計4つのノードがあるためです。可用性ドメインおよびフォルト・ドメインの詳細は、リージョンおよび可用性ドメインを参照してください。

タイトルおよび著作権情報

Oracle and/or its affiliates.