5 Global Data Servicesの使用(アーキテクチャ、ユースケース、アプリケーション開発)
5.1 分散データベース
データベースがデータ・レジデンシ、グローバルなスケーラビリティ、パフォーマンス、可用性のために分散されている環境では、GDSはインテリジェントなトラフィック・ディレクタおよびワークロード・コーディネータとして機能します
- シャード・ディレクタおよびシャード・カタログ: GDSはシャード対応プロキシとして機能し、クライアント・リクエストをインターセプトして、関連するデータを含む適切なシャードにルーティングします。
- データ・ローカリティ: GDSは、データが存在するシャードにリクエストが送信されるようにし、データの移動を最小限に抑え、パフォーマンスを最適化します。
- スケーラビリティと並列性: GDSは、シャードを追加することでデータベースのスケール・アウトを容易にします。また、パラレル問合せ機能を利用して問合せのパフォーマンスを向上させることができます。
- アプリケーション開発の簡素化: GDSは、アプリケーションからシャーディング・スキームの複雑さを隠し、単一の論理ユニットとしてデータベースと対話できるようにします。
分散データベースのユースケース
- グローバルなE-Commerceプラットフォーム: 複数のリージョンにまたがる製品データを格納して、世界中のユーザーに短い待機時間のアクセスを提供します。
- ソーシャル・メディア・ネットワーク: ユーザー・プロファイル、投稿およびメディアを地理的に分散したノードに分散して、スケーラビリティとレスポンス時間を向上させます。
- 金融サービス: 一貫性と高可用性を確保しながら、複数のリージョンにわたるトランザクションおよび顧客データを管理します。
- コンテンツ配信ネットワーク(CDN): ビデオやイメージなどの大規模なデータセットを様々なデータ・センターに分散して、エンドユーザーへのコンテンツ配信を最適化します。
- IoTアプリケーション: グローバルに分散されたセンサーからのリアルタイム・データを処理し、ローカル処理と一元化された分析を必要とします。
5.1.1 Oracle ShardingでのGlobal Data Servicesの使用
Oracle Shardingを使用すると、ハードウェアやソフトウェアを共有しないOracleデータベースのプール間でデータを配布およびレプリケーションできます。データベースのプールは1つの論理データベースとしてアプリケーションに示されます。プールにデータベース(シャード)を追加するだけで、任意のレベル、任意のプラットフォームにアプリケーション(データ、トランザクションおよびユーザー)を柔軟にスケーリングできます。最大1000個のシャードまでのスケール・アップがサポートされています。
Oracle Shardingは、スケーラビリティに対して同様のアプローチを使用するカスタムのデプロイメントに比べ、より優れたランタイム・パフォーマンスとよりシンプルなライフサイクル管理を提供します。リレーショナル・スキーマ、SQL、およびその他のプログラム・インタフェース、複雑なデータ型のサポート、オンライン・スキーマの変更、マルチコア・スケーラビリティ、高度なセキュリティ、圧縮、高可用性、ACIDプロパティ、読取り一貫性、JSONを使用した開発者の俊敏性などを含むエンタープライズDBMSの利点も提供します。
Oracle Globally Distributed Databaseは、Oracle Database Global Data Services機能に基づいて構築されているため、トポロジを計画するには、Global Data Servicesのアーキテクチャと管理を理解する必要があります。
Oracle Globally Distributed Databaseを使用すると、グローバル・データベースをデプロイできます。このグローバル・データベースでは、1つの論理データベースを複数の地理的位置に分散できます。これにより、データ・プライバシ規則の要件(データ主権)を満たせるようになり、特定のデータを利用者の近くに保存できるようにもなります(データ近接性)。
データ主権とは、一般的に、データが作成された地域に固有の規制によってデータが管理されることを指します。これらのタイプの規制では、データの保存場所、データへのアクセス方法、データの処理方法およびデータのライフサイクルが指定されることがあります。国境やパブリック・クラウド・リージョンをまたぐデータの急増に伴い、100か国以上でデータの保存場所と転送方法に関する規制が可決されました。特に、個人を特定できる情報(PII)は、それが収集される国の法律およびガバナンス構造の対象となることが増えています。多くの場合、他の国へのデータ転送は、その国が同様のレベルのデータ保護を提供しているかどうか、およびその国が科学捜査で協力するかどうかに基づいて制限または許可されます。
5.2 Global Data ServicesでのTrue Cacheの使用
Oracle True Cacheは、Oracle Database用の、一貫性が確保され自動管理される、インメモリーSQLキャッシュです。True Cacheにより、データベースの負荷を軽減しながら、アプリケーションのレスポンス時間が短縮されます。自動キャッシュ管理と一貫性により、アプリケーション開発が簡素化され、開発の労力とコストが削減されます。
Oracle True CacheをOracle Database Global Data Services (GDS)とともにデプロイすると、複数のTrue Cacheおよびその他のデータベース・レプリカにわたり、ワークロード・ルーティング、動的ロード・バランシングおよびサービス・フェイルオーバーを管理できます。
グローバル・サービスは、機能的に、単一インスタンス・データベースまたはOracle Real Application Clusters (Oracle RAC)データベースによって提供されるローカル・データベース・アプリケーション・サービスに似ています。グローバル・サービスとローカル・サービスとの主な違いは、グローバル・サービスが複数のデータベースのインスタンスを対象とするのに対し、ローカル・サービスが単一データベースのインスタンスを対象とする点です。
次の図は、単一リージョンでのGDSを使用した基本的なTrue Cache構成を示しています:
図5-1 GDSとのTrue Cacheの統合
この例では、2つのTrue Cacheと1つのプライマリ・データベースを持つリージョンが1つあります。True Cacheは、キャッシュをウォームアップするため、またはキャッシュ・ミスがある場合に、プライマリ・データベースから読み取ります。ブロックがキャッシュされると、プライマリ・データベースからのREDO適用によってブロックが自動的に更新されます。アプリケーションは、頻繁な読取りがTrue Cacheに送信され、書込みおよび頻度の低い読取りがプライマリ・データベースに送信されるように構成されます。
GDS構成には、次のコンポーネントが含まれています:
- GDSカタログには、GDS構成の構成データが格納されています。この例では、GDSカタログはプライマリ・データベースの外部でホストされています。
-
グローバル・サービス・マネージャ(GSM)は、サービス・レベルのロード・バランシング、フェイルオーバー、およびGDS構成でのサービスの一元的な管理を提供します。高可用性を実現するには、各リージョンに2つのGSMを含めることがベスト・プラクティスです。
- GDSプールは、プライマリ・データベースとTrue Cacheに共通のグローバル・サービス・セットを提供します。1つのリージョンに複数のGDSプールを含めることができ、これらのプールは複数のregions.Inにまたがることができます。この例では、
SALESプールはプライマリ・データベースのSALESグローバル・サービスとTrue CacheのSALES_TCグローバル・サービスを提供します。 - Oracle Notification Service (ONS)サーバーは、各GSMにあります。リージョン内のすべてのONSサーバーは、ONSサーバー・ネットワーク内で相互接続されています。GSMにより、ランタイム・ロード・バランシング勧告が作成され、ONSサーバー・ネットワークを介してそれらがOracle Universal Connection Pool (UCP) JDBC接続プールに公開されます。アプリケーションはプールからの接続をリクエストし、アプリケーション構成およびGDS構成に応じてリクエストがTrue Cacheまたはプライマリ・データベースに送信されます。
True Cacheでは、Oracle Global Data Services (GDS)との次のような統合が提供されます。
- GDSでは、グローバル・サービス用の
-role TRUE_CACHEオプションが用意されています。 JDBC SetReadOnly()を使用したTrue Cacheアプリケーション・プログラミング・モデルでは、グローバル・サービスがサポートされています。- GDSでは、複数のTrue Cacheの間のロード・バランシングおよびサービス・フェイルオーバーが提供されます。
True CacheとOracle GDSのデプロイには、次の制限事項があります。
- GDSCTLでTrue Cacheサービスを追加する場合、
-failover_primaryオプションには、バグ36740927用のパッチが必要です。 - アプリケーションでJDBCプログラミング・モデルが使用されている場合は、プライマリ・データベース・サービスとTrue Cacheサービスの名前を両方とも、ドメイン名(
sales.example.comやsales_tc.example.comなど)で完全修飾する必要があります。これは、GDSにデフォルトのドメイン名があり、それがデータベースのdomain_nameパラメータとは異なるためです。また、この完全修飾サービス名は64文字までに制限されています。
Oracle GDSを使用したOracle True Cacheのデプロイに関する詳細な手順は、Oracle Global Data Servicesを使用したOracle True Cacheのデプロイを参照してください
5.3 サポートされているレプリケーション・テクノロジおよび実装アーキテクチャ
高可用性、障害時リカバリまたは読取りスケーリングのためにデータベースがレプリケートされる環境では、Oracle GDSは次のものを提供します:
- グローバル・サービス管理: GDSはグローバル・サービス抽象化を作成し、基礎となるレプリケートされたデータベースの複雑さをアプリケーションからマスキングします。
- ワークロード・ルーティング: GDSは、データベース・ロール(読取り/書込み、読取り専用)、リージョン、レプリケーション・ラグ、リソース容量などの要因に基づいて、クライアント・リクエストを適切なデータベース・インスタンスにインテリジェントにルーティングします。
- ロード・バランシング: GDSは、負荷条件とネットワーク待機時間を考慮して、ワークロードのバランスを動的に調整します。
- フェイルオーバーおよびスイッチオーバー: GDSは、障害発生時にスタンバイ・データベースへのデータ・サービスのフェイルオーバーを自動化し、アプリケーションの継続的な可用性を確保します。
- 一元的な管理: GDSカタログは、グローバル・サービスとその関連データベースの構成と健全性を管理および監視するための中心的なポイントを提供します。
レプリケートされたデータベースのユースケース
- 障害時リカバリ・システム: プライマリ・システムに障害が発生した場合に、フェイルオーバーのためにプライマリ・データベースをスタンバイ・データベースにレプリケートします。
- コンテンツ管理システム(CMS): 複数のリージョンにわたって高速アクセスのためにデータをレプリケートする、読取り負荷の高いWebサイト(コンテンツ配信、E-Commerce、航空会社の予約システムなど)。
- ビジネス・インテリジェンス(BI)およびアナリティクス: レプリケートされたデータベースは、プライマリ・データベースのオフロード中にレプリカに対する複雑な読取り負荷の高い問合せを処理します。
- 顧客関係管理(CRM)システム: 分散したチームに顧客データをレプリケートし、高可用性とクライアント情報への迅速なアクセスを実現します。
- モバイル・アプリケーション: 複数のリージョンにデータベースをレプリケートすることで、グローバルに分散したユーザー・ベースへの短い待機時間読取りアクセスを保証します。
5.3.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
5.3.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}です。
前述の手順により、正常なスイッチオーバーが可能になります。ただし、ソース・データベースを使用できないフェイルオーバー・イベントの場合は、次の手順を使用してデータ損失を見積もることができます。
-
自動ハートビート表を使用する場合は、次の問合せを使用してレプリケーション待機時間を判別します。
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秒である可能性があることを示しています。
-
ターゲット・データベースでGDSサービスを起動し、セッションが接続できるようにします。
なお、アプリケーション・ワークロードである程度のデータ・ラグを許容できる場合は、前述の手順2より早くこの手順を実行できます。
GDSCTL> start service -service sales_sb -database stm -gdspool sales -
ターゲット・データベースにログオンし、
V$SESSIONをチェックして、サービスに接続されているセッションを確認します。SQL> SELECT service_name, count(1) FROM v$session GROUP BY service_name ORDER BY 2;
5.3.3 Global Data ServicesでのRAFTレプリケーションの使用
Raftレプリケーションは、分散データベース内のすべてのシャード間のレプリケーションの自動構成を容易にするコンセンサスベースのレプリケーション・プロトコルです。Raftレプリケーションはアプリケーションとシームレスに統合され、その運用における透過性を提供します。シャード・ホストの障害または分散データベースの構成の動的変更の場合、Raftレプリケーションはレプリケーション設定を自動的に再構成します。システムは、宣言的なアプローチを使用してレプリケーション係数を構成し、指定した数のレプリカを一貫して使用できるようにします。
Raftレプリケーションが有効な場合、分散データベースには複数のレプリケーション・ユニットが含まれます。レプリケーション・ユニット(RU)は、同じレプリケーション・トポロジを持つ一連のチャンクです。各RUには、異なるシャードに配置された複数のレプリカがあります。Raftコンセンサス・プロトコルは、障害、ネットワーク・パーティション化、メッセージ損失または遅延の場合にレプリカ間で一貫性を維持するために使用されます。
SwiftフェイルオーバーはRaftレプリケーションのキー属性であり、ノード障害が発生した場合でもすべてのノードをアクティブのままにできます。特に、この機能には1秒未満の自動フェイルオーバー・メカニズムが組み込まれており、データの整合性と運用の継続性が強化されています。これにより、この機能は高可用性とスケーラブルなデータベース・システムを求める組織に適しています。
Oracle GDSには、システム管理のシャード・データベースでRaftレプリケーションを有効化および管理するためのGDSCTLコマンドおよびオプションが用意されています。
Raftレプリケーションの有効化
シャード・カタログを構成するときに、Raftレプリケーションを有効にします。Raftレプリケーションを有効にするには、シャード・カタログの作成時にcreate shardcatalogコマンドでネイティブ・レプリケーション・オプションを指定します。たとえば、gdsctl> create shardcatalog ... -repl nativeです
ノート:
RAFTレプリケーションの構成およびデプロイの詳細は、RAFTレプリケーションの構成および管理を参照してください
5.5 アプリケーション開発時の考慮点
5.5.1 グローバル・データ・サービスのアプリケーション・ワークロード適合性
グローバル・データ・サービス(GDS)は、レプリケーション対応のアプリケーション・ワークロードに最適です。これは、レプリケートされた環境で動作するように設計されています。GDS導入に適したアプリケーションには、次のいずれかの特徴があります:
-
アプリケーションで、Oracle Active Data GuardまたはOracle GoldenGateレプリカを使用するために作業を読取り専用、読取り多用および読取り/書込みサービスに分けることができる。GDSでは、読取り専用、読取り/書込みおよび読取り多用のトランザクションは区別されません。読取り/書込みサービスと読取り専用または読取り多用サービスを区別するようにアプリケーションの接続を更新する必要があります。また、GDS管理者が、適切なデータベースでグローバルサービスを構成できます。たとえば、レポート作成アプリケーションは、Oracle Active Data Guardスタンバイ・データベースで読取り専用サービスとともに直接機能できます。
-
管理者が、Oracle GoldenGateレプリカを利用するために、マルチマスター更新の競合を認識して回避または解決する必要がある。たとえば、競合解決が組み込まれたインターネット・ディレクトリ・アプリケーションでは、読取り/書込みワークロードを複数のデータベースに分散できます。各データベースは読取り/書込みでオープンされ、Oracle GoldenGateマルチマスター・レプリケーションを使用して同期されます。
-
理想的には、アプリケーションでレプリケーション・ラグを許容できる。たとえば、顧客が読取り専用レプリカを使用して各自の出荷のステータスを追跡できる、Webベースの荷物追跡アプリケーションです(レプリカがソース・トランザクション・システムより10秒以上遅れない)。
5.5.2 グローバル・データ・サービスでの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自動構成によって定義されており、node_groups(デフォルト)の場合は、それ以上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構成ファイル内でそれらのノード・グループを指定します。
5.5.3 クライアント側の構成
ベスト・プラクティスとしては、複数のグローバル・サービス・マネージャを高可用性にする必要があります。クライアントを、ローカル、リモートまたは単一クライアント・アクセス名(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以上に設定します。
5.5.4 ユニバーサル接続プールを使用したJavaクライアント用のFANの構成
Oracle DatabaseのJDBC ThinドライバとともにFCFを利用するための最良の方法は、ユニバーサル接続プール(UCP)またはWebLogic Server Active GridLinkの使用です。
ユニバーサル接続プールでプール・プロパティFastConnectionFailoverEnabledを設定すると、高速接続フェイルオーバー(FCF)が有効になります。Active GridLinkでは、デフォルトで、FCFが常に有効になっています。IBM WebSphereやApache Tomcatなどのサードパーティ・アプリケーション・サーバーでは、接続プールの代替としてUCPがサポートされています。
他のWebサーバーへのUCPの埋込みの詳細は、次の技術概要を参照してください。
-
UCPでの計画済または計画外のデータベース停止時間および実行時ロード・バランシングのためのWebSphereアプリケーションの設計およびデプロイ(https://www.oracle.com/docs/tech/database/planned-unplanned-rlb-ucp-websphere.pdf)
-
UCPでの計画済または計画外のデータベース停止時間および実行時ロード・バランシングのためのTomcatアプリケーションの設計およびデプロイ (https://www.oracle.com/docs/tech/database/planned-unplanned-rlb-ucp-tomcat.pdf)
高速接続フェイルオーバーを有効にするには、次の構成手順に従います。
- 接続URLでは、サービス名構文を使用し、動的データベース・サービス名およびJDBC URL構造の指定によってベスト・プラクティスに従う必要があります(前述および後述)。
他のすべてのURL形式は高可用性ではありません。このURLでは、JDBC ThinまたはJDBC OCIを使用できます。
- ウォレット認証が確立されていない場合は、リモート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)))"); - プール・プロパティ
setFastConnectionFailoverEnabled=trueが設定されていることを確認します。 -
CLASSPATHには、ons.jar、ucp.jarおよびJDBCドライバjarファイルが含まれている必要があります。たとえば、ojdbc8.jarです。 - Oracle DatabaseとともにJDBC Thinを使用している場合は、アプリケーション・コンティニュイティを、FANの受信後に接続をフェイルオーバーするように構成できます。
- 自動構成されたのとは異なるONSエンドポイントがデータベースで必要な場合は、そのONSエンドポイントを有効にできます。
auto-onsが有効になっている状態で複数のクラスタが存在する状況では、auto-onsにより、次のガイドラインに従ってノード・リストが生成されます:
アクティブなノードリストすべてについて、
oracle.ons.maxconnectionsは、デフォルトで3に設定されます。そのため、これを明示的に設定する必要はありません。この例では、ONSクライアントで、合計6つの接続の保持が試みられます。
5.5.5 OCIクライアント用のFANの構成
プール・ソリューションに関係なくすべてのクライアントでFANを使用できるように、OCIクライアントによりドライバ・レベルでFANが埋め込まれます。サーバーとクライアントの両方でリリース19c以降が使用されていることが理想的です。
SQL*PlusおよびPHPの場合の構成
- サービスについて通知を設定します。
- PHPクライアントの場合のみ、
oci8.events=Onをphp.iniに追加します。重要: xmlに
events=-falseが指定されている場合、またはイベントが指定されていない場合は、これにより、FANの使用が無効化されます。oraccess.xmlの使用中にSQL*PlusおよびPHPでFANを保持するには、events=-trueを設定します。 - クライアント側で、クライアントおよびOracle Databaseを使用して、xmlにおいてFANを有効にします。
OCIクライアントの場合の構成
- 開始しているONSリスナーを検索する場所をOCIに指示します。
クライアント・インストールには、クライアント・ライブラリにリンクされてONSが付属しています。auto-configを使用すると、ONSエンドポイントがそのTNSアドレスから検出されます。この自動による方法をお薦めします。ODP.Netと同様に、手動によるONS構成も
oraaccess.xmlを使用してサポートされています。 - OCI接続に対してFAN高可用性イベントを有効にします。
FANを有効にするには、OCIファイルのxmlを編集してグローバル・パラメータ・イベントを指定します。このファイルは
$ORACLE_HOME/network/adminにあります。詳細は、「ステップ3: FANが使用されていることの確認」を参照してください。 - ONSリスナーを検索する場所をOCIに指示します。
クライアント・インストールには、クライアント・ライブラリにリンクされてONSが付属しています。auto-configを使用すると、ONSエンドポイントがそのTNSアドレスから検出されます。この自動による方法をお薦めします。ODP.Netと同様に、手動によるONS構成も
oraaccess.xmlを使用してサポートされています。 - すべてのOCIクライアントに対して、そのサーバー上でFANを有効にします。
すべてのOCIクライアント(SQL*Plusを含む)に対して、データベース・サーバーでFANを有効にする必要があります。
5.5.6 ログオン・ストームの制御
小さい接続プールをお薦めしますが、接続数が多い場合はチューニングによりログオン・ストームを制御できます。
Oracle MAAでは、グローバル・サービス・マネージャをホストするサーバーで次のようにチューニングすることをお薦めしています。
-
OSレベルでリスニング・バックログを増やします。
サーバーを再起動せずに新しい値を有効にするには、rootとして次のことを実行します。
echo 8000 > /proc/sys/net/core/somaxconn -
再起動後も値が保持されるようにするには、この設定を/etc/sysctl.confに追加します。
net.core.somaxconn=6000 -
グローバル・サービス・マネージャ・リスナーに対して
queuesizeを増やします。Oracleホームで、リスナーが実行されているoraを更新して、
queuesizeパラメータを増やします。TCP.QUEUESIZE=6000