1. 高可用性概要およびベスト・プラクティス
  2. 『Oracle Database高可用性ベスト・プラクティス』
  3. Oracle Global Data Servicesのベストプラクティス

11 Oracle Global Data Servicesのベスト・プラクティス

Oracle Database Global Data Services (GDS)は、Oracle Databaseの包括的な自動ワークロード管理機能です。

GDSでは、グローバルに分散されているか同じデータ・センター内に配置されているレプリケートされた一連のデータベースに、ワークロード・ルーティング、ロード・バランシング、データベース間サービス・フェイルオーバー、レプリケーション・ラグベースのルーティング、ロールベースのグローバル・サービス、およびワークロード集中管理が提供されます。

GDSを使用すると、マルチポイント・ソリューションや自社開発製品と統合する必要なく、これらのメリットを得ることができます。GDSにより、ハードウェア使用率とソフトウェア使用率が最適化されます。また、レプリケートされたデータベースで実行されているアプリケーション・ワークロードのパフォーマンス、スケーラビリティおよび可用性が向上します。

Global Data Servicesの概要

多くの組織では、ローカルまたは地理的な様々な場所に、本番データベースまたはスタンバイ・データベースの複数のコピーがあります。この冗長性により、様々なビジネス・ニーズが満たされます(中断のない可用性の確保、障害時リカバリの準備、コンテンツのローカライズとキャッシュ、操作のスケーリング、ローカル・ユーザーのパフォーマンスの最適化、地域の規制への準拠など)。これらのコピーを同期化するOracle Active Data GuardおよびOracle GoldenGateは、最も低いリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を提供する、Oracleの戦略的な障害時リカバリおよびレプリケーション・テクノロジです。

ワークロードを複数のデータベース・レプリカに分散して高パフォーマンスと高可用性を実現することは、レプリケーション・テクノロジの機能の域を超えた課題です。リソースを効率的に使用し、最高のパフォーマンスを実現するには、ワークロードのロード・バランシングが必要です。レプリカがオフラインになった場合にアプリケーションが使用可能状態のままであり可能なかぎり高いサービス品質を実現するように、停止にインテリジェントに対応する必要があります。理想の世界では、レプリケートされたデータベースのプールを使用したロード・バランシングと高可用性が、Oracle Databaseから入手可能なリアルタイム情報を使用してシームレスかつ最適に実現されます。この理想は、Oracle Global Data Services (GDS)を使用して実現できます。

GDSでは、データベース・サービス(Oracle Real Application Clusters (RAC)でのワークロード管理に使用されるメカニズム)の概念が拡張されて、Oracle RAC、単一インスタンス・データベース、Oracle Active Data GuardおよびOracle GoldenGateの任意の組合せを含むグローバルにレプリケートされた構成になります。GDSにより、ロード・バランシング、高可用性、データベース・アフィニティなどをサポートして、このグローバルにレプリケートされた構成内のどこにでもサービスをデプロイできるようになります。GDSは、実績のある技術的構成要素(サービス(動的ワークロード管理)、Oracle Active Data GuardおよびGoldenGateレプリケーション、Oracle Net Listenerなど)に基づいて構築されています。

この機能はグローバル・データ・サービスと呼ばれていますが、GDS構成の要素となるデータベースは、グローバルに分散することも同じデータ・センター内に配置することもできます。クライアントは、サービスを提供する物理データ・センター・アセットがどこに配置されているかを把握する必要なく、サービス名を指定することで安全に接続できるため、エンタープライズ・データ・クラウドに対して、柔軟性の高いデプロイメントが可能になります。GDSでは、レプリケートされたデータベースは、アプリケーションから単一のデータ・ソースに見えます。

GDS構成には、リージョンごとに複数のグローバル・サービス・マネージャが含まれます。グローバル・サービス・マネージャは"グローバル・リスナー"であり、レプリケートされたデータベースに関するリアルタイムのロード特性とユーザー定義のサービス配置ポリシーを理解しています。これらのグローバル・サービス・マネージャは、GDSのデータベース間サービス・フェイルオーバーおよびロード・バランシングの実行に関与します。GDSは、レプリケートされたデータベースの複数のセットを制御できる共有インフラストラクチャです。このドキュメントでは、GDSの構成および操作方法について説明します。これは、エンタープライズ・アーキテクト、データベース・アーキテクト、データベース管理者、テクノロジ・マネージャ、ソリューション・アーキテクト、アプリケーション・アーキテクト、およびデータベース・アーキテクチャ設計全体に影響を及ぼすユーザーを対象としています。

グローバル・データ・サービスの概念

データベース・サービスは、Oracleデータベースでのワークロードを管理するための論理的な抽象概念です。各サービスは、一般的な属性、サービス・レベルしきい値および優先度でワークロードを表します。グループ化は、作業特性(アプリケーション機能など)に基づいて実行できます。たとえば、Oracle E-Business Suiteでは、アプリケーション・モジュールごと(総勘定元帳、売掛金勘定、受注など)にサービスを定義します。サービスはOracle Databaseに組み込まれており、複数のワークロードに対して単一のシステム・イメージを提供します。サービスを使用すると、管理者が、ワークロードの構成、管理、有効化および無効化を実行でき、そのワークロードを単一エンティティとして測定できます。クライアントは、データベース・サービス名を使用して接続します。

Oracle RACでは、1つのサービスが1つ以上のインスタンスにまたがることができ、リアルタイムのトランザクション・パフォーマンスに基づいたワークロード・バランシングを促進できます。これにより、高可用性、ワークロードごとのローリング変更、および完全な位置の透過性が提供されます。レプリケートされた環境の場合は、GDSにより、"グローバル・サービス"の概念が導入されます。グローバル・サービスは、GDSプールと呼ばれる、特定の管理ドメインに属する、レプリケート・データを含む一連のデータベースにわたり提供されます。GDSプールの例としては、SALESプールやHRプールがあります。GDS構成内の一連のデータベース、およびデータベース・クライアントは、それらがネットワーク近接性を共有する場合には、同じGDSリージョンにあると考えられます。GDSリージョンの例としては、アジア地域、ヨーロッパ地域などがあります。

グローバル・サービスでは、従来のデータベース・サービスのすべての特性がサポートされています。グローバル・サービスでは、従来のデータベース・サービスが追加属性(グローバル・サービス配置、レプリケーション・ラグ(Oracle Active Data GuardおよびOracle GoldenGateは19c以降)、リージョン・アフィニティなど)で拡張されています。

グローバル・サービス配置:グローバル・サービスが作成されると、GDSにより、そのサービスの優先データベースおよび使用可能データベースを指定できるようになります。使用可能データベースでは、優先データベースに障害が発生した場合にグローバル・サービスがサポートされます。また、GDSでは、指定したGDSプールのすべてのレプリカで実行するようにサービスを構成できます。

レプリケーション・ラグ: クライアントを、グローバル・サービスのラグ属性で確立されている許容範囲制限に従って遅延していないOracle Active Data Guardスタンバイにルーティングできます。

リージョン・アフィニティ: グローバル・サービスでは、プリファレンスを、指定したアプリケーションが接続する必要があるリージョン(アジアやヨーロッパなど)に設定できます。

図11-1 グローバル・データ・サービスによるワークロード・バランシング


図11-1の説明が続きます
「図11-1 グローバル・データ・サービスによるワークロード・バランシング」の説明

グローバル・データ・サービスの主な機能

グローバル・データ・サービス(GDS)テクノロジでは、次の主要機能が提供されます:

  • リージョンベースのワークロード・ルーティング: GDSでは、クライアント接続を、ローカル・リージョン内のレプリケートされた一連のデータベースの間でルーティングされるように構成することもできます。この機能により、リモート領域内のデータベースへのアクセスによるネットワーク待機時間のオーバーヘッドが回避されて、アプリケーションのパフォーマンスを最大限に高めることができます。

  • 接続時ロード・バランシング: グローバル・サービス・マネージャでは、GDSプール内のすべてのデータベースからのロード統計、リージョン間ネットワーク待機時間および構成された接続時ロード・バランシング目標を使用して、GDSプール内の最適なデータベースに着信接続がルーティングされます。

  • 実行時ロード・バランシング: GDSでは、接続プールベースのクライアント(OCI、JDBC、ODP.NET、WebLogicなど)についてリアルタイム・ロード・バランシング・アドバイザを公開することで、レプリケートされた複数のデータベースにわたる実行時ロード・バランシングが可能になります。接続プールベースのクライアントでは、このロードバランシング・アドバイザがサブスクライブされており、すでに確立されている接続間でデータベース・リクエストがリアルタイムでルーティングされます。

    GDSの実行時接続ロード・バランシング機能を使用すると、アプリケーション・クライアントの作業リクエストが、最良のパフォーマンスを提供するデータベースに動的にルーティングされます。また、GDSでは、データベースのパフォーマンスが変化したときに接続を動的に再分散する機能もサポートされています。

  • データベース間サービス・フェイルオーバー: データベース・グローバル・サービスのクラッシュが発生した場合、GDSでは、サービス配置属性を考慮して、プール内の別の使用可能データベースへのデータベース間サービス・フェイルオーバーが自動的に実行されます。GDSにより、グローバル・サービスが起動された新しいデータベースにクライアント接続プールが再接続できるように、高速アプリケーション通知(FAN)イベントが送信されます。

  • レプリケーション・ラグベースのワークロード・ルーティング: Oracle Active Data Guardでは、スタンバイがプライマリ・データベースより遅れる場合があります。グローバル・サービスでは、指定したアプリケーションについてラグ許容範囲を選択できます。GDSにより、リクエストが、ラグが制限を下回っているスタンバイ・データベースにルーティングされます。ラグがラグ制限を上回ると、そのサービスが、ラグがしきい値を下回っている使用可能な別のスタンバイ・データベースに再配置されます。新しいリクエストは、ラグ制限を満たしているスタンバイ・データベースにルーティングされます。使用可能なデータベースがない場合、グローバル・サービスは停止されます。ラグが解決されるか制限の範囲内になると、GDSにより、自動的にそのサービスが起動されます。

    Oracle GoldenGateレプリケーションでは、サービスに対して定義されているラグしきい値(SELECT MAX(INCOMING_LAG FROM GGADMIN.GG_LAG)で定義されているラグ)をラグが上回ると、そのデータベース上のそのサービスが停止されます。サービスではその影響が定義されています。その構成に基づいて、すべてのセッションが終了される場合もされない場合もあります。ラグがしきい値内に戻ると、サービスが再起動されます。サービスが停止されると、グローバル・サービス・マネージャにより、自動的にフェイルオーバー処理が実行されます。このサービスへの新しい接続は、遅延しているデータベース以外に送られます。そのため、プール内に2つのデータベースがあり、サービスが最初はpreferred_allでlag=10である場合、サービスは両方のデータベースで実行され、接続はロード・バランシングされます。2番目のデータベースがラグしきい値を上回ると、サービスがそこで停止され、新しい接続は1番目のデータベースにのみ送られます。ラグがしきい値内に戻ると、サービスが再起動され、ロード・バランシングが続行され、新しい接続で2番目のデータベースを使用できるようになります。

  • ロールベースのグローバル・サービス: Oracle Data Guard Brokerでデータベース・ロール・トランジションが実行されたときに、サービスに割り当てられているロールがデータベースのロールと一致する場合は、GDSにより、グローバル・サービスを、新しいプライマリ・データベースおよび新しいスタンバイに自動的に再配置できます。

  • レプリカのワークロード集中管理: GDSでは、単一の統合フレームワークで、レプリケートされたデータベースのリソースを、その配置場所を問わず、より簡単に構成および管理できます。

グローバル・データ・サービスのメリット

グローバル・データ・サービス(GDS)を使用すると、フォルトトレラントなデータベース・サービスをデプロイでき、レプリケートされた一連のデータベースを集中管理できます。GDSフレームワークでは、これらのデータベース間でのワークロード・バランシングが提供されます。具体的に述べると、GDSは、次のメリットをもたらすOracle統合ソリューションです:

  • より高い可用性とグローバルなスケーラビリティにより、どのデータ・センターでも、レプリケートされたデータベース間でのシームレスなデータベース間サービス・フェイルオーバーがサポートされ、アプリケーションの可用性が向上します。

  • GDSでは、データベースを動的に追加できることにより、オンデマンドでアプリケーションのスケーラビリティが提供されます。それにより、レプリケートされたデータベースをGDSインフラストラクチャに動的かつ透過的に追加して、アプリケーション・ワークロードをスケーリングするためのリソース機能をさらに取得できます。GDSでは、アプリケーション構成やクライアント接続を変更せずにこれができます。

パフォーマンスと拡張度の向上

GDSでは、複数のデータベースにわたる統合されたロード・バランシングにより、リージョン間のリソース断片化に対処しています。あるリージョン内の十分に利用されていないリソースで別のリージョンの過剰利用されているリソースのワークロードを処理できるため、最適なリソース使用率が実現されます。GDSにより、様々なプロセッサ世代および様々なリソース(CPU、メモリー、I/O)のデータベース・サーバーで実行されているレプリケートされたデータベースを含むGDSプール内の、より性能の低いデータベースに作業リクエストが送信されます。その目標は、より性能の高いデータベースが過負荷の場合に、レスポンス時間を均等にすることです。

管理性の向上

GDSCTLコマンドライン・インタフェースまたはOracle Enterprise Manager Cloud Controlのグラフィカル・ユーザー・インタフェースでは、GDS構成を管理できます。グローバルなリソースを集中管理することで、地理的に分散したレプリケートされたデータベースを、地域やグローバルかどうかに関係なく、GDSの統合フレームワーク内で効率的に活用できます。

レプリケートされたデータベースのワークロード集中管理、データベース間サービス・フェイルオーバーおよび実行時ロード・バランシングは、GDS固有の機能です。GDSにより、真に柔軟で俊敏な企業が実現され、プライベート・データ・クラウドのメリットが拡張されます。

グローバル・データ・サービスのアプリケーション・ワークロード適合性

グローバル・データ・サービス(GDS)は、レプリケーション対応のアプリケーション・ワークロードに最適です。これは、レプリケートされた環境で動作するように設計されています。GDS導入に適したアプリケーションには、次のいずれかの特徴があります:

  • アプリケーションで、Oracle Active Data GuardまたはOracle GoldenGateレプリカを使用するために作業を読取り専用、読取り多用および読取り/書込みサービスに分けることができる。GDSでは、読取り専用、読取り/書込みおよび読取り多用のトランザクションは区別されません。読取り/書込みサービスと読取り専用または読取り多用サービスを区別するようにアプリケーションの接続を更新する必要があります。また、GDS管理者が、適切なデータベースでグローバルサービスを構成できます。たとえば、レポート作成アプリケーションは、Oracle Active Data Guardスタンバイ・データベースで読取り専用サービスとともに直接機能できます。

  • 管理者が、Oracle GoldenGateレプリカを利用するために、マルチマスター更新の競合を認識して回避または解決する必要がある。たとえば、競合解決が組み込まれたインターネット・ディレクトリ・アプリケーションでは、読取り/書込みワークロードを複数のデータベースに分散できます。各データベースは読取り/書込みでオープンされ、Oracle GoldenGateマルチマスター・レプリケーションを使用して同期されます。

  • 理想的には、アプリケーションでレプリケーション・ラグを許容できる。たとえば、顧客が読取り専用レプリカを使用して各自の出荷のステータスを追跡できる、Webベースの荷物追跡アプリケーションです(レプリカがソース・トランザクション・システムより10秒以上遅れない)。

Oracle Maximum Availability Architectureでのグローバル・データ・サービス

Oracle Maximum Availability Architecture(MAA)は、Oracleの高度な高可用性(HA)テクノロジの統合スイート向けのベスト・プラクティス・ブループリントです。ITインフラストラクチャでMAAを活用している企業は、高可用性についてのビジネス要件を満たすアプリケーションを迅速かつ効率的にデプロイできます。

Oracle Global Data Servicesを使用しない場合、管理者は、サード・パーティのロード・バランサをデプロイするか、カスタム作成の接続マネージャを選択する必要がありました。サード・パーティのソリューションにはかなりの統合コストが伴い、DIYの自社開発ソリューションには高い初期コスト、および価値実現までの長い時間がかかり、メンテナンスとサポートの負担もかかります。

グローバル・データ・サービスを使用すると、レプリケートされたデータベースのリソースを単一のフレームワーク内で統合できるため、ロード・バランシングのために自社開発またはサード・パーティの統合を作成する必要がなくなります。高可用性および障害時リカバリ・スタックでの、ベンダー統合のタッチ・ポイントを最小限に抑えることができます。

図11-2 最大可用性アーキテクチャでのOracle Global Data Services


図11-2の説明が続きます
「図11-2 最大可用性アーキテクチャでのOracle Global Data Services」の説明

グローバル・データ・サービスは、Oracle Database内で使用可能な戦略的なMAAコンポーネントです。GDSはOracleエコシステムと適切に統合されており、データ・センター内にある、および複数のデータ・センターにわたるレプリケートされたデータベース間でのワークロード・ルーティング、ロード・バランシングおよびサービス・フェイルオーバーを提供します。簡単に言えば、GDSは、レプリケートされたデータベースのためのデータベース・ロード・バランサであり、データベース間サービス・フェイルオーバー機能によって高可用性を提供します。

グローバル・データ・サービスにより、管理者が、共通サービスを提供するレプリケートされた複数のデータベースにわたりクライアント・ワークロードを自動的かつ透過的に管理できます。データベース・サービスは、1つ以上のデータベース・インスタンスをある単位にまとめて表現したものです。サービスにより、データベースのワークロードをグループ化し、特定の作業リクエストを適切なインスタンスにルーティングできます。グローバル・サービスは、データ・レプリケーションにより同期された複数のデータベースによって提供されます。

グローバル・データ・サービスでは、共通サービスを提供するレプリケートされたデータベースに、動的なロード・バランシング、フェイルオーバーおよびサービス集中管理が提供されます。データベースのセットには、Oracle RAC、およびOracle Data Guardを介して相互に関連する非クラスタOracleデータベース、Oracle Multitenantの元で統合されたデータベース、Oracle GoldenGateまたはその他のレプリケーション・テクノロジを含めることができます。

GDSの詳細は、グローバル・データ・サービスの技術概要(http://oracle.com/goto/gds)を参照してください。

グローバル・データ・サービスでの部分サイト停止または完全サイト停止

サイト全体で障害が発生すると、アプリケーション層とデータベース層の両方が使用不可になります。可用性を維持するため、冗長なアプリケーション層、および本番データベースの同期されたコピーをホストするセカンダリ・サイトに、ユーザーをリダイレクトする必要があります。MAAのベスト・プラクティスは、スタンバイ・サイトで実行状態のアプリケーション層を維持して起動時間の発生を回避し、Oracle Data Guardを使用して本番データベースの同期されたコピーを管理することです。サイト障害が発生すると、WANトラフィック・マネージャでDNSフェイルオーバーが実行されて(手動または自動)、すべてのユーザーが、スタンバイ・サイトにあるアプリケーション層にリダイレクトされます。一方、フェイルオーバーにより、スタンバイ・データベースがプライマリ本番ロールに遷移します。

部分サイト障害とは、アプリケーションまたはデータベース・スタックで停止が発生した場合です。クライアントを障害時リカバリ・サイトのアプリケーション・スタックに接続すると、アプリケーション・スタックの障害を軽減できます。ただし、プライマリ・データベースが使用不可になったときは、プライマリ・データベースに接続されているアプリケーション層はそのまま維持されます。可用性の維持に必要なのは、Data Guardフェイルオーバーの完了後に、アプリケーション層を新しいプライマリ・データベースにリダイレクトすることのみです。このユースケースでは、スタンバイ・データベースは、データベース・フェイルオーバーの発生後にリモート接続を使用して許容可能なパフォーマンスを実現できるように、存続しているアプリケーション層から離れた場所にあります。

グローバル・データ・サービス(GDS)では、リージョン内のレプリケートされたデータベース間でのサービス管理およびロード・バランシングが可能になります。ただし、アプリケーション層は、GDSグローバル・サービス・マネージャがロード・バランシング・ポリシーとサービス可用性に基づいて最適な使用可能レプリカに接続をルーティングできるときでも機能します。これに対して、リージョン外フェイルオーバーでは、ユーザーが、新しい本番データベース(リージョン内グローバル・サービス・マネージャの異なるセットによって提供される)に対してローカルなリモート・アプリケーション層に転送される必要があります。このドキュメントでは、リージョン内フェイルオーバーのGDS構成について説明します。

グローバル・データ・サービス構成

デプロイメント手順の概要

次に、グローバル・データ・サービスを実装するための基本的な手順を示します。

  1. グローバル・サービス・マネージャ・サーバーにグローバル・データ・サービス(GDS)のグローバル・サービス・マネージャ・ソフトウェアをインストールします。
    • リージョンごとに少なくとも1つのグローバル・サービス・マネージャ
    • リージョンごとに3つのグローバル・サービス・マネージャを推奨
  2. GDSカタログ・データベースを事前に作成します。
  3. GDS管理者アカウントおよび権限を設定します。
  4. GDSを構成します。
    • GDSカタログおよびスタンバイ・データベースを作成します。
    • グローバル・サービス・マネージャ、リージョン、プール、データベースおよびグローバル・サービスを追加します。
  5. クライアント接続を設定します。

構成の例

次の手順では、グローバル・データ・サービスを実装する方法を説明します。

グローバル・データ・サービス(GDS)のこの構成例では、管理者管理Oracle RACデータベースを使用します。管理者管理デプロイメントとは、優先および使用可能の指定を使用して、特定のデータベースに属する特定のインスタンスで実行されるようにデータベース・サービスを構成することを意味します。

ポリシー管理デプロイメントはサーバー・プールに基づいています。この場合、データベース・サービスは、サーバー・プール内でシングルトンまたは均一として、サーバー・プール内のすべてのサーバーにわたり実行されます。データベースは1つ以上のサーバー・プールにデプロイされます。サーバー・プールのサイズによって、デプロイメント内のデータベース・インスタンスの数が決まります。GDSの詳細は、グローバル・データ・サービス概要および管理ガイドを参照してください。

  1. GDSカタログ・データベースを作成し準備します。

    GDSでは、カタログ・データベースを使用して、GDS構成のレイアウトおよびステータスに関連するメタデータが格納されます。可用性を最大限に高めるために、GDSカタログ・データベースを個別にデプロイし、Oracleの高可用性機能(Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardなど)を使用して、カタログ・データベースを停止から保護することをお薦めします。

  2. GSM_ADMINユーザーを作成し、そのユーザーにGSMADMIN_ROLEを割り当てます。

    デフォルトではGSM_ADMIN、GSMUSERおよびGSMCATUSERのすべてのパスワードは180日後に期限切れになることに注意してください。 

    SQL> create user gsm_admin identified by password;

User created.

SQL> grant gsmadmin_role to gsm_admin;

Grant succeeded.

SQL> exit
  3. カタログ・データベースへのアクセスに使用できるOracle Net別名をコピーし、それをグローバル・サービス・マネージャ・ホームにあるtnsnames.oraファイル内に配置します。
    GDSCAT =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <hostmane>)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = gdscat)
))
  4. グローバル・サービス・マネージャ・ホーム用に構成された環境で、GDSCTLを使用して接続し、自動VNCRを無効にしてGDSカタログを作成します(自動VNCRによってOracle RACデプロイメントで問題が発生する可能性がある)。
    GDSCTL>create catalog -database gdscat -user gsm_admin -autovncr OFF

"gsm_admin" password:

Catalog is created
  5. カタログ・データベースに接続し、GSMCATUSERユーザーのロックを解除し、パスワードを設定します。
    SQL> alter user gsmcatuser account unlock;

User altered.

SQL> alter user gsmcatuser identified by password;

User altered.
  6. グローバル・サービス・マネージャ・ホーム用に構成された環境で、GDSCTLを使用して接続し、グローバル・サービス・マネージャ・リスナーを作成し起動します。

    ベスト・プラクティスとして、グローバル・サービス・マネージャ・リスナーは、GDS構成において、Oracle Databasesをホストしているのとは別のハードウェアに存在する必要があります。グローバル・サービス・マネージャ・リスナーの実行に必要なハードウェアのリソース要件は軽量であり、仮想マシンを使用して簡単に対応できます。

    GDSCTL>add gsm -gsm gsm1 -listener 1522 -catalog gdscat

"gsmcatuser" password:

Create credential oracle.security.client.connect_string1

GSM successfully added

GDSCTL>start gsm -gsm gsm1

GSM is started successfully

GDSCTL>status

Alias GSM1
Version 19.17.0.3.0
Start Date 13-APR-2023 09:40:59
Trace Level off
Listener Log File
 /u01/app/oracle/diag/gsm/hostname/gsm1/alert/log.xml
Listener Trace File
 /u01/app/oracle/diag/gsm/hostname/gsm1/trace/ora_64863_139739749930432.trc
Endpoint summary
(ADDRESS=(HOST=hostname.example.com)(PORT=1522)(PROTOCOL=tcp))
GSMOCI Version 0.6.11
Mastership Y
Connected to GDS catalog Y
Process Id 64883
Number of reconnections 0
Pending tasks. Total 0
Tasks in process. Total 0
Regional Mastership TRUE
Total messages published 0
Time Zone -04:00
Orphaned Buddy Regions: None
GDS region regionora
  7. グローバル・サービス・マネージャ・ホーム用に構成された環境で、GDSCTLを使用してデフォルトのGDSプールおよびデフォルト・リージョンを作成します。
    GDSCTL>add gdspool -gdspool sales

GDSCTL>add region -region slc

GDSCTL>add region -region sca
  8. 問題を回避するためにGDSカタログの作成中に自動VNCRを無効にした状態で、GDSCTLにより、ホスト名またはIPアドレスを適切に指定してadd invitednodeコマンドを実行しホストを追加します。
    GDSCTL>add invitednode 192.0.2.1

GDSCTL>add invitednode host1.example.com
  9. GSMUSERアカウントのロックを解除します。

    データベースをプールに追加する前に、次の例で示すように、データベース管理者がGSMUSERアカウントのロックを解除し、GDSプール管理者にパスワードを与える必要があります。 

    SQL> alter user gsmuser account unlock;

User altered.

SQL> alter user gsmuser identified by password;

User altered.
  10. GDSプールにデータベースを追加します。

    GDSプールに含めるには、データベースでサーバー・パラメータ・ファイル(SPFILE)が使用されている必要があります。Oracle RACデータベースにはSCAN設定も必要です。

    データベースを追加するには、GDSプールまたはGDS管理者資格証明を使用してGDSカタログに接続します。たとえば、Data Guardがない場合は、次のadd databaseコマンドを使用できます。

    GDSCTL>add database -connect mts -region sca -gdspool sales

Catalog connection is established

"gsmuser" password:

DB Unique Name: mts

    ノート:

    Oracle Active Data GuardをGDSとともに使用する場合は、add databaseのかわりにadd brokerconfigを使用してから、modify databaseを使用してスタンバイ・データベースを構成します(add brokerconfigを参照)。これらのコマンドの構文は、次のようになります。
    GDSCTL>add brokerconfig -connect <primary_db> -gdspool <dbpool> -region <dc> -pwd <gsmuser_pwd>

GDSCTL>modify database -database <standby_db> -connect <dc> -gdspool <dbpool> -region <dc> -pwd <gsmuser_pwd>

    データベース・インスタンスのグローバル・サービス・マネージャでの登録は、リクエストが有効なノードからの場合にのみ成功します。データベースが存在するホストに複数のネットワーク・インタフェースが含まれている場合は、自動構成によって正しくない一連のIPアドレスが登録されて、データベース登録が拒否される可能性があります。

  11. 拒否された登録を修正し、すべてのデータベース・インスタンスを適切に検出します。

    グローバル・サービス・マネージャ間にファイアウォールが存在し、データベースとポートがオープンされていない場合、登録は失敗します。グローバル・サービス・マネージャのアラート・ログで、次のようなエントリが表示されます。

    Listener(VNCR option 1) rejected Registration request from destination

192.0.2.2

Listener(VNCR option 1) rejected Registration request from destination

192.0.2.3

    データベース・オブジェクトがGDSカタログに存在するが特定のホストに関連付けられているインスタンスの一部またはすべてが欠落していることがわかります。 

    GDSCTL>databases

Database: "mts" Registered: Y State: Ok ONS: Y. Role: PRIMARY

Instances: 1 Region: slc

Registered instances:

sales%1

    拒否された登録を修正し、すべてのデータベース・インスタンスを正しく検出するには、グローバル・サービス・マネージャのアラート・ログにリストされている拒否されたIPアドレスを使用してadd invitednodeを実行します。

  12. グローバル・サービス・マネージャとデータベースの間にファイアウォールがある場合は、それらのポートを開きtnspingを使用して検証した後、次に示すようにadd invitenodeコマンドを発行します。
    GDSCTL>add invitednode 192.0.2.3

GDSCTL>databases

Database: "mts" Registered: Y State: Ok ONS: Y. Role: PRIMARY

Instances: 2 Region: slc

Registered instances:

sales%1

sales%2
  13. GDSプールのデータベースにサービスを作成します。

    GDSCTLのadd serviceコマンドでは、GDSプールのデータベースにサービスが作成されます。 

    GDSCTL>add service -service sales_sb -preferred_all -gdspool sales -notification TRUE

    これが、複数のインスタンスとともに追加されるOracle RACデータベースである場合は、サービスを変更してそれらのデータベース・インスタンスを追加する必要があります。

    GDSCTL>modify service -gdspool sales -service sales_sb -database mts -add_instances -preferred mts1,mts2

GDSCTL>modify service -gdspool sales -service sales_sb -database stm -add_instances -preferred stm1,stm2

GDSCTL>start service -service sales_sb -gdspool sales
  14. グローバル・サービスが実行されていることを確認します。
    GDSCTL>services

Service "sales_sb.sales.oradbcloud" has 2 instance(s). Affinity: ANYWHERE

Instance "sales%1", name: "mts1", db: "mts", region: "slc", status: ready.

Instance "sales%2", name: "mts2", db: "mts", region: "slc", status: ready.

構成のベスト・プラクティス

Oracle MAAでは、グローバル・データ・サービスを実装するための次のベスト・プラクティスをお薦めしています。

  • 各クライアントは、UCP、OCI、ODP.NETなどのOracle統合接続プールを使用して通信します。接続プールは、高速アプリケーション通知イベントを使用してサービス・フェイルオーバーおよびロード・バランシング・アドバイザ通知について知らされます。

  • 各リージョンで3つのグローバル・サービス・マネージャを実行します。各リージョンに3つのグローバル・サービス・マネージャを作成して、1つのグローバル・サービス・マネージャが停止した場合に、冗長性を確保するために2つのグローバル・サービス・マネージャが残るようにします。各グローバル・サービス・マネージャは別々のハードウェアに配置する必要があります。グローバル・サービス・マネージャにより、レプリケートされたデータベース間の接続ルーティングが可能になります。グローバル・サービス・マネージャは、GDSカタログからメタデータを再移入できる、ステートレスで軽量かつインテリジェントなリスナーです。

  • Oracle Data GuardでGDSカタログ・データベースを保護します。GDSカタログは、GDS構成、リージョン、グローバル・サービス・マネージャ、グローバル・サービス、データベースなどのメタデータをホストする小規模(100 GB未満)なリポジトリです。MAAでは、最大可用性データベース保護モード、Data Guardファスト・スタート・フェイルオーバーおよびリモート・フィジカル・スタンバイ・データベースで構成されたローカルData Guardスタンバイ・データベースを設定することをお薦めしています。GDSカタログのすべてのスタンバイ・データベースは、最適なデータ保護のためにOracle Active Data Guardが使用され、別々ハードウェアおよびストレージに配置される必要があります。

グローバル・データ・サービスでのFAN ONSの使用

高速アプリケーション通知(FAN)では、すべてのOracle Databaseクライアント(JDBC、Tuxedo、リスナー・クライアントなど)へのイベント伝播にOracle Notification Service (ONS)が使用されます。

ONSは、Oracle Global Data Servicesの一部として、クラスタ上のOracle Grid Infrastructure、Oracle Data Guardインストール内、およびOracle WebLogicのインストール時にインストールされます。

ONSにより、FANイベントが、それが登録されている他のすべてのONSデーモンに伝播されます。データベース・サーバー側でFANを構成または有効化する手順は必要ありません。ただし、OCI FANおよびODP FANでは、GDSCTLによってそのサービスについて通知をTRUEに設定する必要があります。クライアントでのFAN自動構成では、ONSのjarファイルが、クライアントに応じてCLASSPATHまたはORACLE_HOMEに存在する必要があります。

FCFクライアントの構成のための一般的なベスト・プラクティス

ドライバ固有の手順に進む前に、これらのベストプラクティスに従います。

  • 動的データベース・サービスを使用します。FANを使用するには、アプリケーションで動的グローバル・データベース・サービスを使用してデータベースに接続している必要があります。これは、GDSCTLを使用して作成されたサービスです。

  • データベース・サービスやPDBサービスを使用して接続しないでください。これらのサービスは管理専用であり、FANではサポートされていません。TNSnamesエントリまたはURLでは、サービス名構文を使用し、動的データベース・サービス名の指定によってベスト・プラクティスに従う必要があります。このドキュメントの後半の例を参照してください。

  • JDBC Thin、Oracle Database OCIまたはODP.NetクライアントとともにFANを使用するときは、Oracle Notification Serviceを使用します。FANは、ONSを介して受信されます。そのため、Oracle Databaseでは、FCFクライアントでサーバー側のONSネットワークを検出し自己構成できるように、ONS FAN自動構成が導入されています。ONSライブラリまたはjarが存在する場合、FANは自動的に有効になります。

  • ほとんどのFCFクライアントでのFANの有効化が、Oracle Databaseではまだ必要です。FAN自動構成により、FCFクライアントで必要となるグローバル・サービス・マネージャを、リストする必要がなくなります。

  • サーバー・ホストをリストすると、位置の透過性と矛盾する方法であるため、サーバー構成が変更されたときにクライアントの更新の問題が生じます。クライアントでは、すでにTNSアドレス文字列またはURLを使用してグローバル・サービス・マネージャ・リスナーが特定されています。

  • FAN自動構成では、TNSアドレスを使用してグローバル・サービス・マネージャ・リスナーが特定されてから、各サーバー・データベースに対してONSサーバー側アドレスが要求されます。複数のグローバル・サービス・マネージャFAN自動構成が存在する場合は、それぞれに接続して、それぞれについてONS構成が取得されます。

  • ONSネットワークは、Oracle Databaseの使用時にURLから検出されます。すべてのアドレス・リストにわたりLOAD_BALANCEがオフになっている場合、ONSノード・グループは、アドレス・リストごとに自動的に取得されます。

  • デフォルトでは、FCFクライアントで、ONS構成内の各ノード・グループに、冗長性のために3つのホストが保持されています。

  • 各ノード・グループは、各GDSデータ・センターに対応しています。たとえば、1つのプライマリ・データベースと複数のOracle Data Guardスタンバイがある場合は、デフォルトで、各ノード・グループに3つのONS接続があります。FAN自動構成を使用している場合は、それらのノード・グループが検出されます。

    node_groupsがFAN自動構成によって定義されており、load_balance=false (デフォルト)の場合は、それ以上ONSエンドポイントは必要ありません。エンドポイントの数を増やす必要がある場合は、最大接続数を増やすことでこれを実行できます。これは、各ノード・グループに適用されます。この例では4つに増やしているため、各ノードで4つのONS接続が保持されます。この値を増やすと、さらに多くのソケットが消費されます。

    oracle.ons.maxconnections=4 ONS

  • クライアントで複数のクラスタに接続し、それらからFANイベントを受信する場合は(たとえば、Oracle RACで、Data Guardイベント)、複数のONSノード・グループが必要です。FAN自動構成では、URLまたはTNS名を使用してこれらのノード・グループが作成されます。ONSの自動構成(Auto-ONS)を使用しない場合は、Oracle Grid Infrastructureまたはoraaccess.xml構成ファイル内でそれらのノード・グループを指定します。

クライアント側の構成

ベスト・プラクティスとしては、複数のグローバル・サービス・マネージャを高可用性にする必要があります。クライアントを、ローカル、リモートまたは単一クライアント・アクセス名(SCAN)リスナーではなく、グローバル・サービス・マネージャである複数の接続エンドポイントに対して構成する必要があります。OCI/ODP.Netクライアントの場合は、次のTNS名構造を使用します。

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3)
  (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS=(PROTOCOL=TCP)(HOST=GSM1)(PORT=1522))
   (ADDRESS=(PROTOCOL=TCP)(HOST=GSM2)(PORT=1522))
   (ADDRESS=(PROTOCOL=TCP)(HOST=GSM3)(PORT=1522)))
  (ADDRESS_LIST=
   (LOAD_BALANCE=on)
   (ADDRESS=(PROTOCOL=TCP)(HOST=GSM2)(PORT=1522)))
 (CONNECT_DATA=(SERVICE_NAME=sales)))

必ずGDSCTLによって作成された動的グローバル・データベース・サービスを使用して、データベースに接続します。データベース・サービスまたはPDBサービスは使用しないでください。それらはアプリケーションで使用するためではなく管理専用であり、マウント時のみ使用可能であるためFANやその他の機能を提供しません。

JDBCの場合は最新またはそれ以前のRDBMSに合った最新のクライアント・ドライバを使用します。TNS名エントリまたはURLで1つのDESCRIPTIONを使用します。それ以上使用すると、RETRY_COUNTおよびRETRY_DELAYの使用時に接続に長い遅延が発生します。OCIおよびODPクライアントの場合はログオン・ストームを回避するためにCONNECT_TIMEOUT=90以上に設定します。

アプリケーションレベルの構成

ユニバーサル接続プールを使用したJavaクライアント用のFANの構成

Oracle DatabaseのJDBC ThinドライバとともにFCFを利用するための最良の方法は、ユニバーサル接続プール(UCP)またはWebLogic Server Active GridLinkの使用です。

ユニバーサル接続プールでプール・プロパティFastConnectionFailoverEnabledを設定すると、高速接続フェイルオーバー(FCF)が有効になります。Active GridLinkでは、デフォルトで、FCFが常に有効になっています。IBM WebSphereやApache Tomcatなどのサードパーティ・アプリケーション・サーバーでは、接続プールの代替としてUCPがサポートされています。

他のWebサーバーへのUCPの埋込みの詳細は、次の技術概要を参照してください。

高速接続フェイルオーバーを有効にするには、次の構成手順に従います。

  1. 接続URLでは、サービス名構文を使用し、動的データベース・サービス名およびJDBC URL構造の指定によってベスト・プラクティスに従う必要があります(前述および後述)。

    他のすべてのURL形式は高可用性ではありません。このURLでは、JDBC ThinまたはJDBC OCIを使用できます。

  2. ウォレット認証が確立されていない場合は、リモートONS構成が必要です。

    次の例で示すように、プロパティ・ファイル内でプール・プロパティsetONSConfigurationを設定します。指定されたプロパティ・ファイルには、ons.nodesプロパティ、およびオプションでoracle.ons.walletfileおよびoracle.ons.walletpasswordのプロパティが含まれている必要があります。ons.propertiesファイルの例を次に示します。 

    PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionPoolName("FCFSamplePool"); pds.setFastConnectionFailoverEnabled(true);
 pds.setONSConfiguration("propertiesfile=/usr/ons/ons.properties");
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
pds.setURL("jdbc:oracle:thin@((CONNECT_TIMEOUT=4)(RETRY_COUNT=30)(RETRY_DELAY=3) "+ "
 (ADDRESS_LIST = "+ " (LOAD_BALANCE=on) "+ " ( ADDRESS =
 (PROTOCOL = TCP)(HOST=GSM1)(PORT=1522))) "+ " (ADDRESS_LIST = "+ " (LOAD_BALANCE=on)
 "+ "( ADDRESS = (PROTOCOL = TCP)(HOST=GSM2)(PORT=1522)))"+
 "(CONNECT_DATA=(SERVICE_NAME=service_name)))");

  3. プール・プロパティsetFastConnectionFailoverEnabled=trueが設定されていることを確認します。

  4. CLASSPATHには、ons.jar、ucp.jarおよびJDBCドライバjarファイルが含まれている必要があります。

    たとえば、ojdbc8.jarです。

  5. Oracle DatabaseとともにJDBC Thinを使用している場合は、アプリケーション・コンティニュイティを、FANの受信後に接続をフェイルオーバーするように構成できます。

  6. 自動構成されたのとは異なるONSエンドポイントがデータベースで必要な場合は、そのONSエンドポイントを有効にできます。

    auto-onsが有効になっている状態で複数のクラスタが存在する状況では、auto-onsにより、次のガイドラインに従ってノード・リストが生成されます:

    アクティブなノードリストすべてについて、oracle.ons.maxconnectionsは、デフォルトで3に設定されます。そのため、これを明示的に設定する必要はありません。この例では、ONSクライアントで、合計6つの接続の保持が試みられます。

OCIクライアント用のFANの構成

OCIクライアントでは、FAN転送にONSが使用されます。

プール・ソリューションに関係なくすべてのクライアントでFANを使用できるように、OCIクライアントによりドライバ・レベルでFANが埋め込まれます。サーバーとクライアントの両方でリリース19c以降が使用されていることが理想的です。

SQL*PlusおよびPHPの場合の構成

  1. サービスについて通知を設定します。

  2. PHPクライアントの場合のみ、oci8.events=Onをphp.iniに追加します。

    重要: xmlにevents=-falseが指定されている場合、またはイベントが指定されていない場合は、これにより、FANの使用が無効化されます。oraccess.xmlの使用中にSQL*PlusおよびPHPでFANを保持するには、events=-trueを設定します。

  3. クライアント側で、クライアントおよびOracle Databaseを使用して、xmlにおいてFANを有効にします。

OCIクライアントの場合の構成

  1. 開始しているONSリスナーを検索する場所をOCIに指示します。

    クライアント・インストールには、クライアント・ライブラリにリンクされてONSが付属しています。auto-configを使用すると、ONSエンドポイントがそのTNSアドレスから検出されます。この自動による方法をお薦めします。ODP.Netと同様に、手動によるONS構成もoraaccess.xmlを使用してサポートされています。

  2. OCI接続に対してFAN高可用性イベントを有効にします。

    FANを有効にするには、OCIファイルのxmlを編集してグローバル・パラメータ・イベントを指定します。このファイルは$ORACLE_HOME/network/adminにあります。詳細は、「ステップ3: FANが使用されていることの確認」を参照してください。

  3. ONSリスナーを検索する場所をOCIに指示します。

    クライアント・インストールには、クライアント・ライブラリにリンクされてONSが付属しています。auto-configを使用すると、ONSエンドポイントがそのTNSアドレスから検出されます。この自動による方法をお薦めします。ODP.Netと同様に、手動によるONS構成もoraaccess.xmlを使用してサポートされています。

  4. すべてのOCIクライアントに対して、そのサーバー上でFANを有効にします。

    すべてのOCIクライアント(SQL*Plusを含む)に対して、データベース・サーバーでFANを有効にする必要があります。

ログオン・ストームの制御

小さい接続プールをお薦めしますが、接続数が多い場合はチューニングによりログオン・ストームを制御できます。

Oracle MAAでは、グローバル・サービス・マネージャをホストするサーバーで次のようにチューニングすることをお薦めしています。

  1. OSレベルでリスニング・バックログを増やします。

    サーバーを再起動せずに新しい値を有効にするには、rootとして次のことを実行します。

    echo 8000 > /proc/sys/net/core/somaxconn

  2. 再起動後も値が保持されるようにするには、この設定を/etc/sysctl.confに追加します。

    net.core.somaxconn=6000

  3. グローバル・サービス・マネージャ・リスナーに対してqueuesizeを増やします。

    Oracleホームで、リスナーが実行されているoraを更新して、queuesizeパラメータを増やします。 

    TCP.QUEUESIZE=6000

正常なアプリケーション・スイッチオーバー

データベース・サービスは、計画済停止の間にワークロードを適切に管理するために使用されます。サービスを適切に作成する必要があり、アプリケーションでサービスから接続を取得する必要があります。

これらの推奨事項では、Oracle Universal Connection Pool (UCP)などのFAN対応接続プールを使用して、停止したサービスからアプリケーションの中断なく接続を正常に排出することを想定しています。アプリケーションでは、FAN対応接続プールをサポートしていない、長時間実行されているトランザクションがない他の接続タイプを使用できます。このようなアプリケーションは、メンテナンス・ウィンドウの前に接続を切断することをお薦めします。

次の推奨事項では、適切な時間にトランザクションが終了したときや最終的にインスタンスがメンテナンスのために停止されたときに一部のセッションを切断する方法について説明します。

アプリケーションの接続構成を理解し最適化するためのお薦めの検証された方法については、次の項で説明します。一部のアプリケーションには、従う必要がある特定のガイドラインがある場合があります。

アプリケーションによる接続の使用についての理解

どのようにアプリケーションで接続が取得され解放されるかを理解することは、それでクラスタ内の他のインスタンスに正常に切り替えることができるかどうかを判断するために重要です。

アプリケーションについて次の情報を特定します:

  • 計画済停止の間にどのようなワークロードがあったか(OLTP/短期またはバッチ/長期トランザクション)?

    • UCPやODP.NETなどの接続プールを使用する短期トランザクションは、迅速に静止できます。

    • 長期トランザクションでは、静止のためにさらに時間が必要であるか、または適切なタイミングで事前にバッチ・ジョブを停止またはキューに入れる必要があります。

  • どのタイプの接続を取得したか(Java、OCI、C#を使用したODP、またはOCIを使用したODP)?

    • UCP、ICC、ODP.NETおよびOCIセッション・プールでは、高速アプリケーション通知(FAN)を使用してプールが迅速に排出されます。他の接続では、接続がクローズ(または、アプリケーションで許可されている場合は終了)されるまで待つ必要があります。

  • 接続プールでサービスが静止されるまでの待機時間はどれくらいか?

    • 接続の切断が実行されるまでに適切な時間が与えられていることを把握するのに役立ちます

  • トランザクションの完了(バッチ・ワークロードへの適用)後にアプリケーションで接続の切断に対応できるか?

    • アプリケーションで正常に接続の切断に対応できない場合は、計画メンテナンスの前にそれを停止する必要があります。つまり、アプリケーション・コンティニュイティが中断を回避するためのオプションになります。

サービスおよびアプリケーション構成のベスト・プラクティス

正常なスイッチオーバーを実行するには、サービスおよびアプリケーションの属性を適切に構成しておく必要があります。検証済のドライバおよびアプリケーション・クライアントのマトリックスについては、My Oracle SupportのドキュメントID 1617163.1を参照してください。

ノート:

本番環境で構成を使用する前に、その構成をテストして、それが設定されておりスイッチオーバーが正しく実行されることを確認する必要があります。

グローバル・データ・サービスでのOracle Active Data Guardの使用

Oracle Active Data Guardリーダー・ファームについて、ローリング方式で移動するようにセッションを構成します。

前提条件

この手順が正しく機能するには、次のものが必要です。

  • Oracle Databaseを使用したOracle Active Data Guard構成(リリース19c以降を推奨)。

  • グローバル・サービス・マネージャを使用したグローバル・データ・サービス(GDS)構成(リリース19c以降を推奨)。

  • 構成内のすべてのActive Data Guardデータベースで実行されるように、GDSサービスが作成されています。

    たとえば:

    GDSCTL>add service -service sales_sb -preferred_all -gdspool sales
 –role physical_standby -notification TRUE
GDSCTL>modify service -gdspool sales -service sales_sb -database mts -add_instances
 -preferred mts1,mts2
GDSCTL>modify service -gdspool sales -service sales_sb -database stm -add_instances
 -preferred stm1,stm2
GDSCTL>start service -service sales_sb -gdspool sales
  1. サービスおよび関連するインスタンスの現在ステータスをチェックし、サービスが正常に移動できることを確認します。

    この時点ではソース・スタンバイ・データベースでのみサービスを使用できる必要があることに注意してください。

    GDSCTL>services
Service "sales_sb.sales.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
   Instance "sales%1", name: "mts1", db: "mts", region: "slc", status: ready.
   Instance "sales%2", name: "mts2", db: "mts", region: "slc", status: ready.
  2. 接続を削除するソース・データベースで通常どおりサービスを停止します(FORCEオプションは使用しない)。
    • この手順では、FANを使用するFAN対応接続プールが静止されます。
    • 新しい接続は、そのサービスを提供する他のインスタンスに送られ、アイドル・セッションはそのサービスを使用してプールから切断されます。
    • 既存の接続は、それらの作業が完了して接続プールに戻されるまで続行できます。
    GDSCTL>stop service -service sales_sb -database mts -gdspool sales

    セッションが切断および再配置されるまでの同意した時間を許可してから、次の手順に進みます。

    ノート:

    Active Data Guardリーダー・ファームのローリング・アップグレードを実行していて、サービスが他のActive Data Guardリーダー・ノードで実行されていない場合は、この手順で説明するGDSCTLのstop serviceを実行する前に、このデータベースでサービス停止を完了できます。
  3. 現在の問合せが完了したら、長時間実行されているセッションの接続を切断します。

    長時間実行される問合せは、接続が移動される期間の前に停止するようにスケジュールしておくかキューに入れることをお薦めします。この手順では、まだ実行中で突然停止(強制終了)することが必要になった長時間実行セッションに対応します。

  4. 停止するインスタンスにログオンします。
  5. V$SESSIONをチェックして、まだサービスに接続されているセッションがあるかどうかを確認します。
    SQL> SELECT service_name, count(1) FROM v$session
 GROUP BY service_name ORDER BY 2;
  6. 以前に停止したサービスについてDBMS_SERVICE.DISCONNECT_SESSIONパッケージを実行します。

    たとえば:

    SQL> exec
 dbms_service.disconnect_session('oltp_work',DBMS_SERVICE.POST_TRANSACTION);
  7. V$SESSIONを再度チェックして、セッションがサービスからログオフしていることを確認します。
    SQL> SELECT service_name, count(1) FROM v$session
 GROUP BY service_name ORDER BY 2;
  8. ターゲット・データベースでGDSサービスを起動し、セッションが接続できるようにします。
    GDSCTL>start service -service sales_sb -database stm -gdspool sales
  9. ターゲット・データベースにログオンし、V$SESSIONをチェックして、サービスに接続されているセッションを確認します。
    SQL> SELECT service_name, count(1) FROM v$session
 GROUP BY service_name ORDER BY 2;

グローバル・データ・サービスでのOracle GoldenGateの使用

次のOracle GoldenGateロール・トランジションのトポロジの例は、2つのデータベース(GG replica1とGG replica2)からなります。Oracle GoldenGateは、単方向レプリケーションを使用し、最初はGG replica1でExtractを実行しGG replica2でReplicatを実行するように設定されています。一般的な手順は、双方向のGoldenGateレプリカまたはダウンストリーム・マイニングのGoldenGateレプリカにも当てはまります。

前提条件

この手順が正しく機能するには、次のものが必要です。

  • Oracle Databaseを使用するOracle GoldenGate構成(19c以上を推奨)

  • GoldenGateプロセスでは、ソースまたはターゲット・データベースへの接続に、GDSサービス名を使用するのではなく専用のTNS別名を使用する必要があります。GDSサービスを使用すると、データベース接続が途中で終了し、データが失われる可能性があります。

  • レプリケーション待機時間を追跡しReplicatでSCN同期が適用されるようにするために、GoldenGateソース・データベースおよびターゲット・データベースにハートビート表が実装されています。GoldenGateの自動ハートビート表機能を有効にする必要があります。自動ハートビート表の詳細は、Oracle GoldenGate管理ガイド(https://docs.oracle.com/en/middleware/goldengate/core/19.1/gclir/add-heartbeattable.html)を参照してください。

  • グローバル・サービス・マネージャを使用したグローバル・データ・サービス(GDS)構成(19c以上を推奨)

  • GDSサービスは、GoldenGate構成内のすべてのデータベースで実行できるように作成されています。

    たとえば:

    GDSCTL>add service -service sales_sb -preferred_all -gdspool sales
GDSCTL>modify service -gdspool sales -service sales_sb -database mts
 -add_instances -preferred mts1,mts2
GDSCTL>modify service -gdspool sales -service sales_sb -database stm
 -add_instances -preferred stm1,stm2
GDSCTL>start service -service sales_sb -gdspool sales

ノート:

ラグ許容範囲オプションを使用している場合は、グローバル・サービスに対するラグ制限を秒単位で指定します。add serviceまたはmodify serviceのオプションは-lag {lag_value | ANY}です。
  1. サービスおよび関連するインスタンスの現在のステータスをチェックし、それらが正常に移動できることを確認します。

    この時点では、サービスはソース・データベースでのみ使用可能である必要があります。

    GDSCTL>services
Service "sales_sb.sales.oradbcloud" has 2 instance(s). Affinity: ANYWHERE
   Instance "sales%1", name: "mts1", db: "mts", region: "slc", status: ready.
   Instance "sales%2", name: "mts2", db: "mts", region: "slc", status: ready.
  2. 接続を削除するソース・データベースでサービスを停止します(FORCEオプションは使用しない)。
    • この手順では、FANを使用するFAN対応接続プールが静止されます。
    • 新しい接続は、そのサービスを提供する他のインスタンスに送られ、アイドル・セッションはそのサービスを使用してプールから切断されます。
    • 既存の接続は、それらの作業が完了して接続プールに戻されるまで続行できます。
    GDSCTL>stop service -service sales_sb -database mts -gdspool sales -force

    セッションが切断および再配置されるまでの同意した時間を許可してから、次の手順に進みます。セッションの排出を許可する時間は、アプリケーションのワークロードおよびユーザー・トランザクションによって異なります。

  3. 現在のトランザクションが完了したら、長時間実行されているセッションの接続を切断します。

    長時間実行されるバッチ・ジョブは、メンテナンス・ウィンドウの前に停止またはキューに入れられるようにスケジュールすることをお薦めします。この手順では、まだ実行中で突然停止(たとえば、強制終了)する必要がある長時間実行セッションに対応します。長時間実行されているバッチ・ジョブが多重呼出し不変でありリカバリ可能である場合は、アプリケーション開発者に問い合せてから、長時間実行セッションの接続を切断します。

  4. 停止するインスタンスにログオンし、V$SESSIONをチェックして、まだそのサービスに接続されているセッションがあるかどうかを確認します。
    SQL> SELECT service_name, count(1) FROM v$session
 GROUP BY service_name ORDER BY 2;
  5. 以前に停止したサービスについてDBMS_SERVICE.DISCONNECT_SESSIONパッケージを実行します。

    たとえば:

    SQL> exec
 dbms_service.disconnect_session('oltp_work',DBMS_SERVICE.POST_TRANSACTION);
  6. V$SESSIONを再度チェックして、セッションがサービスからログオフしていることを確認します。
    SQL> SELECT service_name, count(1) FROM v$session
 GROUP BY service_name ORDER BY 2;
  7. GDSサービスに関連付けられているすべてのセッションが切断されたら、GoldenGateソース・データベースのすべてのデータがターゲット・データベースにレプリケートされたことを確認します。

    • GoldenGateソース・データベースからの現在のデータベースSCNを記録します。

      SQL> SELECT current_scn FROM v$database;

    • GoldenGateターゲット・データベースで、次の問合せを使用して、Replicatで適用されたSCNの監視を続けます。

      SQL> SELECT lwm_position FROM v$gg_apply_coordinator;
    • ターゲットのLWM_POSITION SCNが、最初の手順で記録したCURRENT_SCNより大きい場合は、すべてのトランザクションがソースからターゲット・データベースにレプリケートされたとみなしても安全です。これで、ユーザーはGoldenGateターゲット・データベースに切り替えることができるようになりました。

前述の手順により、正常なスイッチオーバーが可能になります。ただし、ソース・データベースを使用できないフェイルオーバー・イベントの場合は、次の手順を使用してデータ損失を見積もることができます。

  1. 自動ハートビート表を使用する場合は、次の問合せを使用してレプリケーション待機時間を判別します。

    SQL> col Lag(secs) format 999.9
SQL> col "Seconds since heartbeat" format 999.9
SQL> col "GG Path" format a32
SQL> col TARGET format a12
SQL> col SOURCE format a12
SQL> set lines 140
SQL> select remote_database "SOURCE", local_database "TARGET", incoming_path "GG Path",
 incoming_lag "Lag(secs)", incoming_heartbeat_age "Seconds since heartbeat" from gg_lag;

SOURCE        TARGET              GG Path                          Lag(secs) Seconds since heartbeat
------------  ------------        -------------------------------- --------- -----------------------
         MTS          GDST          EXT_1A ==> DPUMP_1A ==> REP_1A       7.3                     9.0

    前述の例は、ソース・データベースとターゲット・データベースの間でのデータ損失が7.3秒である可能性があることを示しています。

  2. ターゲット・データベースでGDSサービスを起動し、セッションが接続できるようにします。

    なお、アプリケーション・ワークロードである程度のデータ・ラグを許容できる場合は、前述の手順2より早くこの手順を実行できます。

    GDSCTL>start service -service sales_sb -database stm -gdspool sales

  3. ターゲット・データベースにログオンし、V$SESSIONをチェックして、サービスに接続されているセッションを確認します。 

    SQL> SELECT service_name, count(1) FROM v$session
 GROUP BY service_name ORDER BY 2;

リージョン間のグローバル・データ・サービス・フェイルオーバーのフロー

  1. 管理者が、本番データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーしました。この操作は、Data Guardファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。
  2. 管理者が、セカンダリ・サイトにある中間層アプリケーション・サーバーを起動します(まだ実行されていない場合)。
  3. セカンダリ・サイトのワイドエリア・トラフィック・マネージャの選択は、サイト全体の障害が発生した場合に自動的に実行できます。セカンダリ・サイトにあるワイドエリア・トラフィック・マネージャによって、セカンダリ・サイトにあるロード・バランサの仮想IPアドレスが返され、後続の再接続でクライアントが自動的に方向付けされます。このシナリオでは、サイト・フェイルオーバーは自動ドメイン・ネーム・システム(DNS)フェイルオーバーによって実行されます。
  4. 別の方法として、DNS管理者が、ワイドエリア・トラフィック・マネージャの選択をサイト全体または特定のアプリケーションのセカンダリ・サイトに手動で変更することもできます。

    次に、手動DNSフェイルオーバーの例を示します。

    • DNSをセカンダリ・サイトのロード・バランサを指すように変更します: プライマリ(プライマリ)DNSサーバーは新しいゾーン情報で更新され、この変更がDNS NOTIFYで通知されます。
    • セカンダリDNSサーバーにDNS NOTIFY通知によってゾーンの更新が通知され、セカンダリDNSサーバーで、新しいゾーン情報が取得されます。
    • キャッシュDNSサーバーから関連するレコードをクリアします。

      キャッシュDNSサーバーは、主にパフォーマンスとレスポンス速度を向上するために使用します。キャッシュ・サーバーは、ホスト問合せに応答して権威DNSサーバーから情報を取得し、そのデータをローカルに保存(キャッシュ)します。同じデータに対する2回目のリクエストや後続のリクエストがあると、キャッシュDNSサーバーは、レスポンスの存続時間(TTL)値が期限切れになるまで、ローカルに保存したデータ(キャッシュ)を使用して応答します。期限切れになると、ゾーン・マスターからのデータはリフレッシュされます。DNSレコードがプライマリDNSサーバーで変更される場合、キャッシュDNSサーバーは、TTLが期限切れになるまでキャッシュされたレコードの変更を取得しません。キャッシュをフラッシュすることでキャッシュDNSサーバーを強制的に権威DNSサーバーに再接続し、更新されたDNS情報を取得します。

    • キャッシュのフラッシュは、使用中のDNSサーバーがフラッシュ機能をサポートしている場合に実行します。標準DNS BINDバージョンのフラッシュ機能は、次のとおりです:
      • BIND 9.3.0: コマンドrndc flushname nameにより、キャッシュから個々のエントリをフラッシュします。
      • BIND 9.2.0および9.2.1: コマンドrndc flushにより、キャッシュをフラッシュできます。
      • BIND 8およびBIND 9(9.1.3以下): ネーム・サーバーを再起動してキャッシュをクリアします。
  5. ローカルDNSサービス・キャッシュをリフレッシュします。

    一部のオペレーティング・システムでは、DNS情報がローカル・ネーム・サービス・キャッシュにローカルにキャッシュされることがあります。その場合、DNSの更新を迅速に認識するには、このキャッシュもクリアする必要があります。

  6. セカンダリ・サイトのロード・バランサで、セカンダリ・サイトの中間層アプリケーション・サーバーにトラフィックを転送します。

グローバル・データ・サービスの制限事項および要件

要件 ネットワーク・ロード・バランサ Oracle GDS
地域ベース・ルーティング あり あり
接続時データベース・ロード・バランシング あり あり
クライアントへのルーティングおよびフェイルオーバー・インテリジェンスの公開 なし あり
レプリケーション・ラグベースのデータベース・ワークロードのルーティング なし あり
データベース間グローバル・サービス・フェイルオーバー なし あり
自動ロールベース・グローバル・サービス なし あり
すべてのレプリカにわたるデータベース・サービスの集中管理 なし あり
Oracle Active Data Guardのネイティブ統合 なし あり
コスト効率 追加支出が必要 Oracle Active Data GuardまたはOracle GoldenGateライセンスに含まれている