Oracle Autonomous Databaseを使用したDRソリューションの構成

災害発生時のビジネス継続性を確保するために、Oracle WebLogic Suiteアプリケーションのディザスタ・リカバリ(DR)戦略を実装します。このソリューションはデータ保護を提供し、Oracle Autonomous Databaseを使用して、最小限のデータ損失と生産性でスタンバイ・システムにすばやく切り替えることができます。

Oracle WebLogic Server for Oracle Cloud Infrastructure、Oracle SOA Suite on Marketplace、またはOracle Fusion Middlewareを使用するその他の中間層Oracle Cloud Infrastructure (OCI)サービスのデータベースとしてOracle Autonomous Databaseを使用する障害時リカバリ・システムを設定および管理できます。

Oracle Autonomous Database ServerlessおよびOracle Exadata Database Service on Dedicated Infrastructureは、スナップショット・スタンバイ機能を提供します。これにより、スタンバイ・データベースを読取り/書込み用に一時的にオープンできます。スタンバイ・データベースをスナップショット・スタンバイに変換すると、完全に更新可能です。リモート・ソース・データベースからのredoデータの受信は継続されますが(そのためDRで保護されます)、redoはフィジカル・スタンバイに変換されるまで適用されません。スナップショット・スタンバイ・データベースで実行されたすべての変更は、再度フィジカル・スタンバイに変換されると元に戻されます。この機能を使用して、スタンバイ・リージョンの中間層システムをプロビジョニングします。DRシステムのライフサイクル中にこの機能を使用して、完全なスイッチオーバーを実行せずにスタンバイ・システムを検証することもできます。

スナップショット・スタンバイ機能に加えて、Oracle Autonomous Database Serverlessにはリモート・リフレッシュ可能クローンが用意されています。これにより、従来のOracle Data Guardスナップショット・スタンバイ・データベース機能と同等の機能が提供されますが、追加のデータベースが使用されます。リモート・リフレッシュ可能クローンは、Oracle Autonomous Data Guardスタンバイとは別に個別に管理されます。Oracle Autonomous Database Serverlessを使用する場合、スナップショット・スタンバイ・データベースのかわりにリモート・リフレッシュ可能クローンを使用して、セカンダリ・リージョンに中間層システムをプロビジョニングしたり、テスト、検証のオープン、パッチ適用などのタスクをスタンバイで実行できます。ただし、スタンバイ・クローン・データベースとリフレッシュ可能クローン・データベースは異なる接続ウォレットを使用し、それらの接続文字列を適切に管理してこれらのタスクを実行する必要があります。

始める前に

Oracle WebLogic Server for Oracle Cloud InfrastructureおよびOracle SOA Suite on Marketplaceでこれらのミドルウェア・システムがOracle Base Database Serviceを使用する場合の障害時リカバリ(DR)システムの設定方法を説明する複数のOracle Maximum Availability Architecture (MAA)技術概要があります。

Oracle WebLogic Server for Oracle Cloud Infrastructure、Oracle SOA Suite on MarketplaceおよびOracle Fusion MiddlewareのDRトポロジでは、アクティブ- パッシブ・モデルが使用されます。プライマリ・システムはOracle Cloud Infrastructure (OCI)データ・センターであり、別のリモートOCIデータ・センター内のセカンダリ・システムです。

各ケースの詳細とトポロジについては、次を確認してください。

前述のドキュメントには、Oracle WebLogic Server for Oracle Cloud InfrastructureおよびOracle SOA Suite on Marketplaceの詳細、設定および管理ステップおよびその他の多くの考慮事項が記載されています。

技術概要に加えて、このプレイブックで説明されている分析およびステップに進む前に、ネットワーキング、コンピュート・インスタンス、ロード・バランシング、Oracle Autonomous Databaseなど、Oracle Cloud Infrastructure (OCI)の概念および管理について理解していることを確認してください。

このプレイブックのステップおよび例は、次のシナリオでOracle WebLogic Server for OCIおよびOracle SOA Suite on Marketplaceを使用して検証されます。

Oracle Exadata Database Service on Dedicated Infrastructure上のOracle Autonomous Data Guard。障害時リカバリ設定にスナップショット・スタンバイ機能を使用します。
Oracle Autonomous Database Serverless上のOracle Autonomous Data Guard。障害時リカバリ設定にスナップショット・スタンバイ機能を使用します。
Oracle Autonomous Database Serverless上のOracle Autonomous Data Guard。障害時リカバリの設定にリモート・リフレッシュ可能クローンを使用します。

ほとんどのステップは、3つのシナリオで共通です。一部のステップのみが異なり、各ケースに固有です。

Oracle Autonomous Databaseを使用するOracle WebLogic ServerまたはOracle Fusion Middlewareシステムにステップを調整することは困難ではありません。

アーキテクチャ

このアーキテクチャ図は、このプレイブックで使用されるアプローチに対するディザスタ・リカバリ(DR)システムのトポロジを示しています。プライマリ・データベースに存在するすべてのランタイム、構成およびメタデータ情報は、Oracle Autonomous Data Guardを使用してリージョン1からリージョン2にレプリケートされます。Oracle WebLogic Server for Oracle Cloud Infrastructure、Oracle SOA Suite on MarketplaceおよびOracle Fusion MiddlewareのDRトポロジでは、アクティブ- パッシブ・モデルが使用されます。プライマリ・システムはOracle Cloud Infrastructure (OCI)データ・センターであり、別のリモートOCIデータ・センター内のセカンダリ・システムです。

Oracle WebLogicドメイン構成は、プライマリ・リージョンのOracle Cloud Infrastructure File Storage (OCI File Storage)ステージ・ディレクトリを使用してレプリケートされ、セカンダリ・リージョンのOCI File Storageステージ・ディレクトリにレプリケートされます。次に、セカンダリ内の実際のドメインディレクトリに構成がコピーされます。ドメインの直接コピーは、ステージ・ディレクトリを使用して回避されるリスクを示します。ファイル・コピーは非トランザクション操作であるため、ステージ・ディレクトリへの最初のコピーが実行されます。ファイルはこの中間ディレクトリで最初に検証され、その後、実際の(最終的な)Oracle WebLogicドメインに転送されます。

図wls-dr-adb.pngの説明

wls-dr-adb-oracle.zip

トポロジは、OCIのOracle WebLogic Server、Oracle SOAまたはOracle Fusion Middlewareディザスタ・リカバリ環境で使用されるものの典型的なものです。スタンバイ中間層のプロビジョニングおよびセカンダリ・テストなどのライフサイクル操作では、スタンバイOracle Autonomous Databaseをスナップショット・スタンバイ・データベースに変換するか、リモート・リフレッシュ可能クローンを使用します。

リモート・リフレッシュ可能クローンを使用する場合、初期プロビジョニングおよびセカンダリでのテストおよび検証操作のための補助データベース(リモート・リージョンのリフレッシュ可能クローン)があります。この場合、セカンダリ中間層は、スイッチオーバーおよびフェイルオーバー・イベントのスタンバイ・アドレスに戻す必要があるデータソースを使用して構成されます。

このアーキテクチャでは、次のコンポーネントがサポートされます。

リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含むローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、広大な距離で(複数の国または複数の大陸にまたがる)リージョンを分離できます。
可用性ドメイン
可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、1つの可用性ドメインでの障害がリージョン内の他の可用性ドメインに影響を及ぼすことはありません。
フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインに3つのフォルト・ドメインがあり、それぞれ独立した電源とハードウェアがあります。複数のフォルト・ドメインにリソースを分散すると、アプリケーションは、フォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。
仮想クラウド・ネットワーク(VCN)およびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNによってネットワーク環境を完全に制御できます。VCNには、VCNの作成後に変更できる、重複しない複数のCIDRブロックを含めることができます。VCNをサブネットにセグメント化して、そのスコープをリージョンや可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。
ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
Oracle WebLogicドメイン
ドメインは、WebLogicサーバー・インスタンスの基本的な管理単位です。ドメインは、1つの管理サーバーで管理する1つ以上のWebLogicサーバー・インスタンス(およびそれに関連付けられたリソース)で構成されています。Oracle WebLogicドメインは、高可用性のためのOracle Maximum Availability Architecture(MAA)のベスト・プラクティスに従って構成されます。
動的ルーティング・ゲートウェイ(DRG)
DRGは、VCNとリージョン外部のネットワーク(別のOracle Cloud InfrastructureリージョンのVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダ内のネットワークなど)間の、同じリージョン内のVCN間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。
セキュリティ・リスト
サブネットごとに、サブネットの内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。
Oracle Cloud Infrastructure File Storage
Oracle Cloud Infrastructure File Storage Serviceでは、耐久性のあるスケーラブルなセキュアなエンタープライズ規模のネットワーク・ファイル・システムを提供します。File Storageサービスのファイル・システムには、Virtual Cloud Network (VCN)内の任意のベア・メタル、仮想マシンまたはコンテナ・インスタンスから接続できます。File StorageサービスはNetwork File Systemバージョン3.0 (NFSv3)プロトコルをサポートしています。このサービスでは、ファイルロック機能用に Network Lock Manager (NLM)プロトコルをサポートしています。

Oracle Cloud Infrastructure File Storageでは、異なるフォルト・ドメインにある5方向のレプリケートされたストレージを使用して、回復可能なデータ保護の冗長性を提供します。データは、消去エンコーディングで保護されます。このサービスは、幅広いユースケースでエンタープライズ・ファイル・システムを必要とするアプリケーションとユーザーのニーズを満たすように設計されています。
Autonomous Database
Oracle Autonomous Databaseは、トランザクション処理およびデータ・ウェアハウス・ワークロードに使用できるフルマネージドの事前構成済データベース環境です。ハードウェアの構成や管理、ソフトウェアのインストールを行う必要はありません。Oracle Cloud Infrastructureでは、データベースの作成、およびデータベースのバックアップ、パッチ適用、アップグレードおよびチューニングが処理されます。
専用Exadataインフラストラクチャ上のOracle Autonomous Database
Oracle Autonomous Database on Dedicated Exadata Infrastructureは、パブリック・クラウドにプライベート・データベース・クラウドがあるOracle Autonomous Databaseです。専用データベースを使用すると、専用のコンピュート、ストレージ、ネットワークおよびデータベース・サービスが提供され、最高レベルのセキュリティ、分離およびガバナンスを実現できます。
Oracle Autonomous Database Serverless

Oracle Autonomous Database ServerlessはOracle Autonomous Databaseです。データベースの配置からバックアップおよび更新まで、データベース・ライフサイクルのあらゆる側面をOracleが自律的に操作する、完全に柔軟なデータベースがあります。
Data Guard
Oracle Data Guardは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービス・セットを提供し、本番のOracleデータベースを中断することなく可用性を維持します。Oracle Data Guardは、本番データベースのコピーとしてスタンバイ・データベースを維持します。これにより、計画停止または未計画停止のために本番データベースを使用できなくなった場合に、Oracle Data Guardはスタンバイ・データベースを本番ロールに切り替えて、停止時間を最小限に抑えることができます。
Oracle Autonomous Data Guard
Oracle Autonomous Data Guardでは、スタンバイ(ピア)・データベースがAutonomous Databaseインスタンスのデータ保護および障害時リカバリを提供できます。1つ以上のスタンバイ・データベースを作成、維持、管理、監視して、本番のOracleデータベースを中断することなく使用できるようにするための包括的なサービス・セットが用意されています。Oracle Data Guardは、スタンバイ・データベースを本番データベースのコピーとしてメンテナンスします。これにより、計画停止または未計画停止のために本番データベースを使用できなくなった場合に、スタンバイ・データベースを本番ロールに切り替えて、停止時間を最小限に抑えることができます。
スナップショット・スタンバイ
スナップショット・スタンバイ・データベースは、物理スタンバイ・データベースからスナップショット・スタンバイ・データベースへの変換によって作成される、完全に更新可能なスタンバイ・データベースです。

スナップショット・スタンバイ・データベースは、プライマリ・データベースからredoデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したredoデータは、スナップショット・スタンバイ・データベースへのすべてのローカル更新を破棄した後、スナップショット・スタンバイ・データベースに戻されると適用されます。
更新可能クローン
Oracle Autonomous Databaseには、アクティブ・インスタンスのフル・クローンの作成、メタデータ・クローンの作成またはリフレッシュ可能クローンの作成を選択できるクローニングが用意されています。リフレッシュ可能クローンを使用すると、ソース・データベースからの変更で簡単に更新できるクローンが作成されます。

中間層の考慮事項

中間層のOracle WebLogic Server for Oracle Cloud Infrastructureのディザスタ・リカバリおよびOracle Cloud Infrastructure MarketplaceのSOA Suiteのディザスタ・リカバリにおけるすべての考慮事項は、このドキュメントで説明するOracle Autonomous Databaseシナリオに適用されます。

中間層について、次の点を考慮してください。

フロントエンド・アドレス
クライアントからOracle WebLogic Serverシステムへのアクセスは、プライマリ・サイトとして使用されているサイトに依存しません。これを実現するには、システムへのアクセスに使用されるフロントエンド・アドレス名は一意で、現時点では常にプライマリ・システムを指している必要があります。この名前は、通常、仮想フロントエンドまたはバニティURLと呼ばれます。

既存のシステムのフロントエンド・ホスト名アドレスを、障害保護用の仮想フロントエンドとして再利用できます。たとえば、元のシステムにプライマリ・システムのバニティURLとしてmywebapps.example.comがある場合、スイッチオーバーまたはフェイルオーバー後に、同じ仮想ホスト名を2番目のサイトのロード・バランサIPに再マップできます。

いずれかのサイトにマップするフロントエンド名に適切なドメイン・ネーム・システム(DNS)サービスを使用します。たとえば、(Oracle Cloud Infrastructure DNSサービス、その他の商用DNS、ローカルDNSまたはローカル・ホスト解決)。
インスタンス名の接頭辞
Oracle WebLogic Server for OCIまたはOracle SOA Suite on Marketplaceをプロビジョニングする場合は、Instance Name Prefixを指定します。このプロパティは、WebLogicサーバーのドメイン名、クラスタ名、WebLogicサーバー名、VMのホスト名など、すべてのリソースの名前を構成するために使用されます。

プライマリおよびセカンダリOracle WebLogic ServerシステムでInstance Name Prefixを同じ値に設定し、両方のシステムでOracle WebLogicリソースの名前が同じになるようにします。同じ名前を使用すると一貫性が保証され、JMSメッセージおよびTLogsのリカバリに必要です。また、両方のサイトでカスタマイズと操作が簡素化されます。

同じOracle Cloudテナンシの複数のインスタンスで同じInstance Name Prefixを使用できます(異なるリージョンまたはコンパートメントで作成している場合)。各インスタンスは、その特定のリージョンおよびコンパートメントにのみ表示されます。

Oracle SOA Suite on Marketplaceプロビジョニング・プロセスには、ドメイン、クラスタ、管理サーバー、管理対象サーバーの接頭辞などのカスタム名を構成できるオプション機能があります。この場合、名前はInstance Name Prefixから導出されません。かわりに、指定された値が使用されます。このドキュメントで説明されている障害回復(DR)トポロジでは、指定されたカスタム名がプライマリシステムとスタンバイシステムで同じであるかぎり、この機能を使用できます。
カスタム・ファイル
WebLogic Cloudで使用されるOCI用Oracle WebLogic Serverドメイン構成のほとんどは、最初にサイト間で同期されますが、次の考慮事項があります。

各WebLogicシステムでは、DRの設定が完了した後でも、ローカル・データベースへの接続に使用される元のJDBC URLが保持されます。スキーマ接頭辞のみが、両方の場所が同じスキーマ(プライマリ・スキーマ)を指すように変更されます。

WebLogicドメイン・インフラストラクチャ機能は、weblogic_domain_name/configディレクトリの構成を同じドメインの他のノードに自動的に分散します。

カスタム・アプリケーション・デプロイメント(ear/warファイル、デプロイメント・プランなど)、およびOracle WebLogic Administration Serverドメイン・ディレクトリの下にあるすべてのもの(一時データを除く)は、このドキュメントで説明する手順を使用して、最初にサイト間で同期されます。Oracle WebLogic Administration Serverで、他のノードまたはドメイン・ディレクトリの外部にあるデータを使用する場合は、データを手動でセカンダリ場所にコピーする必要があります。構成のレプリケートの詳細は、後述します。

Oracle Autonomous Database Serverlessでのスナップショット・スタンバイに関する考慮事項

このソリューションを実装する場合は、Oracle Autonomous Database Serverlessデータベースでスナップショット・スタンバイを有効にする際に次の点を考慮してください。

サーバーレス・インフラストラクチャのスナップショット・スタンバイの時間制限
Oracle Autonomous Database Serverlessのスナップショット・スタンバイが48時間以内に再接続されない場合、スナップショット・スタンバイはソース・データベースに自動的に再接続します。
ディザスタ・リカバリ・ピアへの変換
Oracleでは、スタンバイを読取り/書込み操作用にオープンする必要がある操作が完了したらすぐに、スナップショット・スタンバイをディザスタ・リカバリ・ピアに戻すことをお薦めします。ディザスタ・リカバリ・ピアに戻すと、ソース・データベースから累積された変更がピアに適用されます。この間にプライマリに進行中の変更があることを前提として、障害回復ピアをスナップショットスタンバイとして長期間開いたままにすると、障害回復ピアへの変換に時間がかかります。
Oracle Autonomous Database Serverlessでのスナップショット・スタンバイのコストへの影響
スナップショット・スタンバイCPU使用量は、ベースCPU数およびコンピュート自動スケーリングが有効な場合の追加CPU使用量に基づいて請求されます。ベースCPUの数は、Oracle Cloud Infrastructureコンソールの「ECPU数」または「OCPU数」フィールドに示されているように、データベースがOCPU (OCPU)の数によって指定されます。

スナップショット・スタンバイ・ストレージの使用量は、スナップショット・スタンバイのストレージと、ソース・プライマリ・データベースのストレージの1倍に基づいて請求されます。

詳細は、「ディザスタ・リカバリ・スナップショット・スタンバイ・データベースについて」を参照してください。

Oracle Autonomous Database on Dedicated Exadata Infrastructureでのスナップショット・スタンバイの考慮事項

このソリューションを実装する場合は、Oracle Autonomous Database on Dedicated Exadata Infrastructureでスナップショット・スタンバイを有効にする際に次の点を考慮してください。

専用インフラストラクチャのスナップショット・スタンバイの時間制限
Oracle Autonomous Database on Dedicated Exadata Infrastructureのスナップショット・スタンバイが7日以内にフィジカル・スタンバイに変換されない場合、スナップショット・スタンバイは自動的にフィジカル・スタンバイに変換されます。
物理スタンバイへの再変換
Oracleでは、スタンバイを読取り/書込み操作用にオープンする必要がある操作が完了したらすぐに、スナップショット・スタンバイをフィジカル・スタンバイに戻すことをお薦めします。フィジカル・スタンバイを変換すると、ソース・データベースからの累積された変更がスタンバイに適用されます。この間にプライマリに進行中の変更があると仮定して、スタンバイ・データベースをスナップショット・スタンバイとして長期間オープンしておくと、フィジカル・スタンバイへの再変換に時間がかかります。
スナップショット・スタンバイへの変換時のデータベース・サービス
Oracle Autonomous Database on Dedicated Exadata Infrastructureでは、「スナップショット・スタンバイに変換」ダイアログに2つのオプションが表示されます:
- 新規データベース・サービスの使用: このオプションは、スナップショット・スタンバイ・モードでのみアクティブな新規サービスを使用してスナップショット・スタンバイに接続する場合に選択します。
- プライマリ・データベース・サービスの使用: このオプションは、プライマリ・データベースと同じサービスを使用してスナップショット・スタンバイ・データベースに接続する場合に選択します。
ディザスタ・リカバリの設定では、スタンバイをフィジカル・スタンバイに変換するときに、「プライマリ・データベース・サービスの使用」オプションを使用します。このようにして、セカンダリ中間層でOracle WebLogic Serverによって構成された接続別名がプライマリと一致します。

詳細は、Autonomous Data Guardについてを参照してください。

Oracle Autonomous Database Serverlessでのリモート・リフレッシュ可能クローンの考慮事項

Oracle Autonomous Database Serverlessリフレッシュ可能クローンを使用して、セカンダリOracle WebLogic Server for Oracle Cloud Infrastructure、Oracle SOA Suite on MarketplaceまたはOracle Fusion Middlewareシステムをテストおよび検証する場合は、次の点を考慮してください。

リフレッシュ可能クローンのライフサイクル
従来のOracle Data Guardスタンバイとは異なり、リモート・リフレッシュ可能クローンは個別に有効化され、プライマリおよびスタンバイとは別に管理されます。これは、ソース・データベース(プライマリ)と同期するリフレッシュ操作以外に、独自のライフサイクルを持つ個別のエンティティです。
CPUリソース割当て
リモート・リフレッシュ可能クローンは、プライマリまたはスタンバイ・システムのCPUリソース割当てに基づいて作成されません。つまり、リフレッシュ可能クローンのOCPUオプションを個別に指定する必要があります。プライマリ・システムの容量と一致するように、リモートのリフレッシュ可能クローンでワークロード・テストを手動で構成する必要があります。理想的には、ワークロードのテストがセカンダリで現実的になるように、プライマリのデータベースと一致する構成を持つリモートのリフレッシュ可能クローンを作成する必要があります。ただし、リモートのリフレッシュ可能クローンは、プライマリで使用されるストレージ構成を「繰り越します」とします。
パッチ適用
パッチは、毎週のメンテナンス・ウィンドウごとにOracle Autonomous Database Serverlessに毎週自動的に適用されるため、プライマリ、スタンバイおよびリモートのリフレッシュ可能クローン間でパッチが継続的かつ強制的に同期されます。
サービス制限
リモート・リフレッシュ可能クローンはファースト・クラス・エンティティであり、正式なAutonomous Databaseのストレージ、CPUおよびライセンスへの影響ごとに追加コストが発生し、Oracle Autonomous Database Serverlessに対するリージョンのサービス制限にカウントされます。
スイッチオーバー時のリフレッシュ可能クローン
フェイルオーバーまたは「ただちに元に戻せないスイッチオーバー」が発生した場合は、システムをセカンダリ・システムのテストおよび保守操作に対応できるようにするために、適切なサービス制限、管理、およびその他の考慮事項を使用して、プライマリにリフレッシュ可能クローンを手動で作成する必要があります。リモート・リフレッシュ可能クローンにはロール・リバーサル制御がありません。

セカンダリへのスイッチオーバー後、作成されたリフレッシュ可能クローンはリフレッシュできなくなり(ソースがスタンバイになったため)、切断済としてマークされます。24時間後、リフレッシュできず、切断されたクローンになります。
リフレッシュ可能クローンのリフレッシュ・ウィンドウ
リモート・リフレッシュ可能クローンは、少なくとも週に1回リフレッシュする必要があります。その後、プライマリのデータと同期するには、新しいリモートリフレッシュ可能クローンを作成し、リフレッシュされていないクローンを破棄する必要があります。
リフレッシュ可能クローンの書込みモード
リモート・リフレッシュ可能クローンは、24時間以上書込みモード(プライマリから切断)のままにできません。その期間を過ぎると、リモートのリフレッシュ可能クローン・データベースをプライマリに再度接続することはできません。その後、プライマリのデータと同期するには、新しいリモート・リフレッシュ可能クローンを作成し、リフレッシュされていないクローンを破棄する必要があります。

`tns_admin`構成フォルダの場所に関する考慮事項

tns_admin構成フォルダについて、次の点を考慮します。

tns_adminフォルダの一貫した場所を使用
WebLogicドメインの中間層は、フォルダを使用してOracle Autonomous Databaseウォレットおよびtnsnames.oraファイルを格納します。プロパティoracle.net.tns_adminは、データソースおよびjps構成ファイル内のこのフォルダを指しています。このフォルダのパスは、プライマリおよびスタンバイ中間層で同じである必要があります。フォルダ・パスが異なる場合は、ディザスタ・リカバリ(DR)設定スクリプトを実行する前に、プライマリまたはスタンバイのフォルダを変更して、同じフォルダを使用するようにしてください。
ノート:
このフォルダの場所で、プライマリとスタンバイに違いが生じる場合があります。
- 2023年2月末(リリース23.1.1より前)より前にプロビジョニングされたOracle SOA Suite on Marketplaceインスタンスは、tns_adminフォルダに$DOMAIN_HOME/config/atpを使用します。リリース23.1.1以降、場所は$DOMAIN_HOME/config/tnsadminです。
ドメインconfigフォルダの下のtns_adminフォルダ
WebLogicデータソース構成内のOracle Autonomous Databaseウォレットの場所を確認します。ウォレットがDOMAIN_HOME/configディレクトリの下に配置されていない場合、ウォレット・ディレクトリの内容への変更は、Oracle WebLogic Serverインフラストラクチャによって他のノードに自動的にレプリケートされません。このような場合は、ウォレット・ディレクトリを変更(および必要なデータソース構成を更新)するか、更新時に他のノードに手動でコピーする必要があります。