APサーバ構築３（JDBC接続）

データ・ソース構成

構成概要

WebLogicで使用するデータ・ソースのタイプは主に「汎用データ・ソース」、「マルチ・データ・ソース（MDS）」、「Active GlidLink（AGL）」の3タイプです。各データ・ソースの特徴はざっくりこんな感じです。

【WebLogicデータソース・タイプ】

データソース・タイプ	説明
汎用データ・ソース	シングル構成やH/A構成のDB接続に使用。複数インスタンス（RAC構成）を対象とした フェイルオーバー、接続ロードバランシング設定可能。 FCF（高速アプリケーション通知）使用不可
マルチデータ・ソース（MDS）	汎用データソースを束ねて論理的に一つのデータソースを構成。 データソース（通常タイプ）の機能に加え汎用データソース間でラウンドロビンによるリクエスト投入先DBインスタンスの振り分けが可能。FCFは使用不可
Active GridLink（AGL）	バック・エンド・ノードの能力(CPU、可用性、応答時間など)に応じた作業の分散を調整するランタイム接続ロード・バランシング（RCLB）、FCFによる高速フェイルオーバーを設定可能 ※AGLの使用にはServer Enterprise EditionまたはWebLogic Suiteのライセンスが必要 ※Active GridLink for RAC の使用権限（entitlement）は「WebLogic Suite」または「Exalogic Elastic Cloud Software」のライセンスの一部としてのみ付与（Oracle® Fusion Middleware Licensing Information User Manual P55）

正直なところ、私はAGLを実際の業務で扱ったことがないのでマニュアルを読んでもRCLBやFCFが実際にはどんな挙動を示すのかよくわかりません。なのでいずれAPサーバ#1にマルチデータ・ソース、APサーバ#2にActive GlidLink の2パターンでデータ・ソースを定義していくつか簡単なテストケースで機能面のざっくりした比較をやってみたいと思います。

※（2026/2/9）AGLのバランシングについて検証した結果をこちらに追加しました。「Web-AP-DB連携検証１（Active GridLink）」

とりあえずMDSはDBサーバ#1のPDB（prpdb1）とDBサーバ#2のPDB（prpdb2）に各100本、AGLはprpdb1 / prpdb2合計で200本の接続構成とし、各DSの挙動を見てから最終的な設定を決定します。MDS、AGLともにDBの接続サービスはonline_srvです。

事前準備

DBサーバ側のファイアウォール設定

現在、DBサーバのファイアウォールはDBサーバ間の接続しか許可していません。このままではAPサーバからDBに接続できないのでOracle Net接続およびONSへの接続を許可します。

【prsdb01、prsdb02、prsdb03 / rootユーザで実行】
-----------------------------------------------------------------------------
# firewalldの現在の設定を確認
firewall-cmd --list-all

# APサーバからのOracle Net、ONSへのアクセスを許可（firewall-cmd～--permanentまで1行で記述）
firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.30.51" port port="1521" protocol="tcp" accept' --permanent

firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.30.51" port port="6200" protocol="tcp" accept' --permanent

firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.30.52" port port="1521" protocol="tcp" accept' --permanent

firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.30.52" port port="6200" protocol="tcp" accept' --permanent

# 設定をリロード
firewall-cmd --reload

# 最新の設定を確認
firewall-cmd --list-all

CRS、DBインスタンス、PDB、サービス起動

DBサーバ#1、DBサーバ#2の CRSが停止している場合は起動します。

【prsdb01、prsdb02 / rootユーザで実行】
-----------------------------------------------------------------------------
# CRS起動（prsdb01→prsdb02の順に1台ずつCRSを起動）
/opt/app/21.0.0/grid/bin/crsctl start crs -wait

DBサーバ#1で DBインスタンス、PDB、online_srvサービスの起動状況を確認、停止している場合は起動します。

【prsdb01で実行】
-----------------------------------------------------------------------------
# oracleユーザにスイッチ
su - oracle

# DBの起動状況を確認
srvctl status database -db prdb

# DBが停止している場合は起動
srvctl start database -db prdb

# PDBの起動状況を確認
srvctl status pdb -db prdb -pdb prpdb

# PDBが停止している場合は起動
srvctl start pdb -db prdb -pdb prpdb

# online_srvサービスの起動状況を確認
srvctl status service -db prdb -service online_srv

# online_srvサービスが停止している場合は起動
srvctl start service -db prdb -service online_srv

アプリケーション用のオブジェクトを格納するための表領域とWebLogicからDBへの接続に使用するOracleユーザを作成します。このユーザはDB接続、オブジェクト作成、管理ビューへのアクセスを行うので必要な権限も付与しておきます。

【prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
# DBに接続
sqlplus / as sysdba

# コンテナをPDBに移動
alter session set container = prpdb;

# ユーザ・テーブル用表領域、ユーザ・インデックス用表領域を作成
create tablespace USERTBL01 datafile '+DG21/PRDB/prpdb/usertbl01.dbf' size 10G autoextend on next 16M;
create tablespace USERIDX01 datafile '+DG21/PRDB/prpdb/useridx01.dbf' size 5G autoextend on next 16M;

# ユーザ作成
create user PDBUSER identified by pdbuser
default tablespace USERTBL01 temporary tablespace TEMP
quota unlimited on USERTBL01
quota unlimited on USERIDX01;

# 権限付与
grant CREATE SESSION, RESOURCE, SELECT_CATALOG_ROLE to PDBUSER;

WebLogic起動

APサーバのAdmin Serverが停止している場合はAdmin Serverを起動します。

【prsap01、prsap02 / oracleユーザで実行】
-----------------------------------------------------------------------------
/opt/app/oracle/bin/startWebLogic_prs.sh

Managed Serverが起動している場合はManaged Serverを停止します。

【prsap01、prsap02 / oracleユーザで実行】
-----------------------------------------------------------------------------
/opt/app/oracle/bin/stopManagedWebLogic_prs.sh

マルチ・データ・ソース作成（APサーバ#1）

汎用データソースを2本作成し、これを束ねてマルチ・データ・ソースを構成します。汎用データ・ソース①は接続先DBインスタンスがprdb1、汎用データ・ソース②は接続先DBインスタンスがprdb2、負荷分散はマルチ・データ・ソース側に設定します。設定可能な振り分け方式はラウンドロビン一択です。

【マルチ・データ・ソース構成】

設定項目	設定値
マルチデータ・ソース名	DS_PDBUSER_10
汎用データ・ソース	GDS_PDBUSER_11 GDS_PDBUSER_12
負荷分散方式	ラウンドロビンによる各汎用データ・ソースへの静的ロードバランシング

【汎用データソース】

設定項目	汎用データ・ソース①	汎用データ・ソース②
データソース名	GDS_PDBUSER_11	GDS_PDBUSER_12
DB接続ユーザ	PDBUSER	PDBUSER
接続ホスト	prsdb01-con	prsdb02-con
接続サービス名	online_srv	online_srv
ロードバランス	OFF	OFF
初期容量 / 最大容量 / 最小容量	100 / 100 / 100	100 / 100 / 100

汎用データソース作成

WebLogic Remote Consoleを起動してAPサーバ#1に接続、ツリーの編集画面で「サービス」を展開、「データ・ソース」-「新規」をクリックします。

以下の設定で汎用データ・ソース①と汎用データ・ソース②を作成します。

【データ・ソース作成画面】

設定項目	汎用データ・ソース①	汎用データ・ソース②
名前	GDS_PDBUSER_11	GDS_PDBUSER_12
JNDI名	GDS_PDBUSER_11	GDS_PDBUSER_12
ターゲット	prs_ap01（チェックして「>」クリック）	prs_ap01（チェックして「>」クリック）
データ・ソース・タイプ	汎用データソース	汎用データソース
データベース・タイプ	Oracle	Oracle
データベース・ドライバ	*Oracle’s Driver (Thin) for RAC Service-Instance connections; Versions:Any	*Oracle’s Driver (Thin) for RAC Service-Instance connections; Versions:Any
グローバル・トランザクション・プロトコル	OnePhaseCommit	OnePhaseCommit
データベース名	prdb1	prdb2
ホスト名	prdb01-con	prdb02-con
サービス名	online_srv	online_srv
ポート	1521	1521
データベース・ユーザー名	PDBUSER	PDBUSER
パスワード	<DBUSERパスワード>	<DBUSERパスワード>
プロトコル	TCP	TCP

すべての項目の設定が完了したら画面上部の「作成」をクリックします。

汎用データ・ソースの作成に成功すると編集画面に遷移します。まず「構成のテスト」をクリックしてDBに接続できていることを確認します。

汎用データ・ソースの設定を行います。「接続プール」タブの「一般」タブと「拡張」タブをクリックして以下の通り編集します。なお、設定は各タブごとに保存します。

【接続プール – 一般タブ設定内容】

設定項目	GDS_PDBUSER_11	GDS_PDBUSER_12
URL※	jjdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prsdb01-con.exsample.lan)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=online_srv)))	jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prsdb02-con.exsample.lan)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=online_srv)))
初期要領	100	100
最大容量	100	100
最小要領	100	100

※各汎用データソースのURLにFAILOVERを設定すればAGLみたくDBノード障害時にアクティブ・ノードに接続が移動しますが、ChatGpt曰く接続管理にいろいろよろしくない面が生じるのでお勧めしないとのこと。

【接続プール – 拡張タブ設定内容】

設定項目	GDS_PDBUSER_11　/　GDS_PDBUSER_12
予約時に接続をテスト	オン
テスト頻度	60
テスト対象の表名	SQL select 1 from dual
縮小頻度	0
接続作成の再試行間隔 （この項目はデフォルトの0のままとします）	0 2

※【2026/2/20補記】
「接続作成の再試行間隔」を短く設定することで大量の「oracle.net.ns.NetException: ORA-12514」が標準出力ログに出力されてしまうことにノード障害検証をやっていて気づきました。…orz
現在ノード障害検証中ですが、汎用DSで接続再作成を設定しなくてもMDS側でノードチェックをして障害ノード復旧時に使用不可となっていた汎用DSを有効化していることが確認できたのでこの設定はデフォルトの0に戻します。

一通り設定が終わったら「一般」タブ（上段のタブ） -「構成のテスト」をクリックして構成に問題がないことを確認します。

マルチ・データ・ソース作成

WebLogic Remote Console画面左ツリーの「データ・ソース」をクリックしてデータソースの管理画面を表示、画面上部の「新規」をクリックします。

以下の設定でマルチ・データ・ソースを作成します。

【データ・ソース作成画面】

設定項目	設定値
名前	DS_PDBUSER_10
JNDI名	DS_PDBUSER_10
ターゲット	prs_ap01（チェックして「>」クリック）
データ・ソース・タイプ	マルチ・データ・ソース
アルゴリズム・タイプ	ロード・バランシング
XAドライバ	オフ
データ・ソース	GDS_PDBUSER_11、GDS_PDBUSER_12（両方にチェックして「>」クリック） ※この操作は一回やっても無反応、2回目で成功します。バグですかね

マルチ・データ・ソースの作成が完了すると管理画面に遷移します。「一般」タブの「テスト頻度」を60に設定して保存をクリック、画面上部「ショッピング・カート」-「変更のコミット」をクリックして変更を確定させます。

DBサーバ#1でPRDBに接続して現在のDBセッションを確認します。Managed Serverは起動していないので下記のSELECT文を実行すると「レコードが選択されませんでした。」と返されるはずです。

【prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
# PRDBに接続
sqlplus / as sysdba

-- コンテナをPDBに移動
alter session set container = PRPDB;

-- 現在のDBセッションを確認
set pages 999 lines 100
col USERNAME format a8
col MACHINE format a8 trunc
col PROGRAM format a10 trunc

select INST_ID, MACHINE, USERNAME, PROGRAM, count(*) SESS_CNT
from  GV$SESSION
where USERNAME is not NULL
and USERNAME != 'SYS'
group by INST_ID, MACHINE, USERNAME, PROGRAM
order by 1,2,3,4;
→ Managed Serverは起動していないので「レコードが選択されませんでした。」と返される

APサーバ#1のManaged Serverを起動します。Managed Serverを起動後、DBサーバ#1で同じSQLを再度実行してAPサーバ#1からDBサーバ#1、DBサーバ#2に各100本の接続が行われていることを確認します。

【prsap01 / oracleユーザで実行】
-----------------------------------------------------------------------------
/opt/app/oracle/bin/startManagedWebLogic_prs.sh

【prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
-- SQL再実行
r

-----------------------------------------------------------------------------
【SQL実行結果】
-----------------------------------------------------------------------------
SQL> r
  1  select INST_ID, MACHINE, USERNAME, PROGRAM, count(*) SESS_CNT,to_char(sysdate,'YYYY/MM/DD HH24:MI:SS') TMSTMP
  2  from  GV$SESSION
  3  where USERNAME is not NULL
  4  and USERNAME != 'SYS'
  5  group by INST_ID, MACHINE, USERNAME, PROGRAM
  6* order by 1,2,3,4

   INST_ID MACHINE  USERNAME PROGRAM      SESS_CNT TMSTMP
---------- -------- -------- ---------- ---------- -------------------
         1 prsap01. PDBUSER  Server            100 2025/07/09 15:18:13
         2 prsap01. PDBUSER  Server            100 2025/07/09 15:18:13

SQL>

Active GlidLink作成（APサーバ#2）

WebLogic Remote ConsoleでAPサーバ#2に接続して「ツリーの編集」画面から「サービス」-「データ・ソース」-「新規」をクリックします。

データ・ソースの作成画面が表示されるので以下のように設定して「作成」をクリックします。

【データ・ソース作成・設定内容】

設定項目	設定値
名前	DS_PDBUSER_10
JNDI名	DS_PDBUSER_10
ターゲット	prs_ap02（チェックして「>」クリック）
データ・ソース・タイプ	GridLinkデータ・ソース
データベース・ドライバ	*Oracle’s Driver (Thin) for GridLink Connections; Versions:Any
グローバル・トランザクション・プロトコル	OnePhaseCommit
リスナー	prsdb01-con.exsample.lan:1521 prsdb02-con.exsample.lan:1521
サービス名	online_srv
データベース・ユーザー名	PDBUSER
パスワード	<PDBUSERパスワード>
プロトコル	TCP
FANの有効化	オン
ONSノード※	prsdb01-con.exsample.lan:6200,prsdb02-con.exsample.lan:6200

※2025/9/23修正：ONSノードが実IP（ホスト名）となっていましたがVIP（ホスト名）が正解です。
※ここに記載した設定は ノード障害検証後に最終的な設定値と入れ替えます。

Active GlidLinkの作成に成功すると管理画面に遷移するので「構成のテスト」をクリックして構成に問題がないことを確認します。

「接続プール」タブをクリックして「一般」、「拡張」を以下の通り設定します。

【接続プール設定内容】

タブ	設定項目	設定値
一般	初期容量	200
一般	最大容量	200
一般	最小容量	200
拡張	予約時に接続をテスト	オン
拡張	テスト頻度	60
拡張	縮小頻度	0
拡張	接続作成の再試行間隔	2 60

※2026/3/3 「接続作成の再試行間隔」修正

接続プールの設定及び保存が終了したら画面上部「ショッピング・カート」-「変更をコミット」をクリックして変更を確定させます。

Active GlidLinkの作成が完了したらDBサーバ#1でDB接続状況の確認用SQLを再実行して現在のDB接続状況を確認します。

【prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
-- SQL再実行
r

-----------------------------------------------------------------------------
【SQL実行結果】
-----------------------------------------------------------------------------
SQL> r
  1  select INST_ID, MACHINE, USERNAME, PROGRAM, count(*) SESS_CNT,to_char(sysdate,'YYYY/MM/DD HH24:MI:SS') TMSTMP
  2  from  GV$SESSION
  3  where USERNAME is not NULL
  4  and USERNAME != 'SYS'
  5  group by INST_ID, MACHINE, USERNAME, PROGRAM
  6* order by 1,2,3,4

   INST_ID MACHINE  USERNAME PROGRAM      SESS_CNT TMSTMP
---------- -------- -------- ---------- ---------- -------------------
         1 prsap01. PDBUSER  Server            100 2025/07/09 15:18:13
         2 prsap01. PDBUSER  Server            100 2025/07/09 15:18:13

SQL>
-- 現時点ではAPサーバ#1からDBサーバへの接続のみ存在

APサーバ#2でManaged Serverを起動します。

【prsap02 / oracleユーザで実行】
-----------------------------------------------------------------------------
/opt/app/oracle/bin/startManagedWebLogic_prs.sh

DBサーバ#1でDB接続状況の確認用SQLを再実行してAPサーバ#2からDBサーバ#1、DBサーバ#2のそれぞれ約100本の接続が行われていることを確認します。

【prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
-- SQL再実行
r

-----------------------------------------------------------------------------
【SQL実行結果】
-----------------------------------------------------------------------------
SQL> r
  1  select INST_ID, MACHINE, USERNAME, PROGRAM, count(*) SESS_CNT,to_char(sysdate,'YYYY/MM/DD HH24:MI:SS') TMSTMP
  2  from  GV$SESSION
  3  where USERNAME is not NULL
  4  and USERNAME != 'SYS'
  5  group by INST_ID, MACHINE, USERNAME, PROGRAM
  6* order by 1,2,3,4

   INST_ID MACHINE  USERNAME PROGRAM      SESS_CNT TMSTMP
---------- -------- -------- ---------- ---------- -------------------
         1 prsap01. PDBUSER  Server            100 2025/07/09 16:08:33
         1 prsap02. PDBUSER  Server            100 2025/07/09 16:08:33
         2 prsap01. PDBUSER  Server            100 2025/07/09 16:08:33
         2 prsap02. PDBUSER  Server            100 2025/07/09 16:08:33

SQL>
-- 今回はたまたまAPサーバ#2からDBサーバ#1、DBサーバ#2に各100本の接続を生成。タイミングによっては少しバラけます

これでデータ・ソースの作成は一旦終了です。続けて細かい挙動をいろいろテストしてみたいところですが、実際にアプリからDBに接続してみないとロードバランシングの挙動だの通常のフェイルオーバーとFCFの比較だのといった確認ができません。ということで次は接続確認用のWebアプリケーションを作成します。

APサーバ構築　関連ページ
１．Weblogicインストール
２．WebLogicドメイン構築
３．JDBC接続
４．DB接続確認用アプリ作成
５．アプリ・デプロイ
６．本番モード切替

修正履歴

2025/9/23

Active GridLinkの構成からONSノードの指定をDBサーバの実IP（ホスト名）指定からVIP（ホスト名）指定に修正しました。

実アドレス指定でも動作はしますが接続先DBインスタンスのサーバ・ダウンにはうまく対応できません（検知に時間がかかる）。

なお、「Oracle WebLogic Server JDBCデータ・ソースの管理」には”ONSノード・リストを構成する場合、値を指定せず、自動ONSによるONS構成の実行を許可することをお薦めします。”なんて書いてありますが、実際にその通りにしてみたところリクエスト投入先のDBインスタンスに偏りが生じてランタイム・ロード・バランシングがうまく機能しないように見受けられたためONSノードの設定自体は（VIP指定に修正したけれども）残しています。

2025/10/25
「構成概要」のAGL、MDSの記述がごちゃごちゃしていたんでずっぱり簡素化させました。

2026/2/3

Active GlidLinkのライセンスはEnterprise Edition以上との認識が誤っていました。WebLogic SuiteまたはExalogic Elastic Cloud
Softwareが必要です。

2026/2/19
APサーバ#2のAGL検証を実施したので検証ページのリンクを「構成概要」に追加しました。

2026/2/20
汎用DSの「接続作成の再試行間隔」を2秒に設定していましたが、これではノード障害時に大量の接続エラーメッセージが出力されてしまうことが検証で判明しました。現在ノード障害検証をやっているところですが想定外の話が出てきましたのでとりあえずデフォルトの0に戻しておきます。

2026/3/3
MDSを構成する汎用DSの「接続作成の再試行間隔」は2/20に修正したのにAGLの設定がそのままになっていました orz。MDSの場合は汎用DSに設定しなくてもMDS側で再接続してくれるのですがAGLの場合はそうした機能がないようなので明示的に設定します。ただし2秒は短すぎますよね（MDSで試験的に入れた値をそのままセットしていました）。MDSの再試行間隔はデフォルトで120秒だそうで、これはテスト頻度のデフォルト値と一致しています。AGLのテスト頻度は60秒なのでとりあえずこれをそのまま「接続作成の再試行間隔」に設定しておいて現在実施中のノード障害検証で調整します。