導入
「接続ユーザーが増えるとサーバープロセスが増えすぎる」「バッチ処理のレスポンスが不安定」——そんな悩みがあるなら、まずは Oracle の“専用サーバー接続（Dedicated Server）”を正しく理解しておくと判断が速くなります。専用サーバーは1セッション＝1サーバープロセスというシンプルな方式です。設定も動作も分かりやすく、重い処理・長時間の処理に向いています。
本記事では、専用サーバー接続の仕組み、設定・確認方法、共有サーバーとの違い、メリット／デメリット、実行例、そして運用時のよくある質問までを一気に整理します。図とコマンド例を多めに載せるので、そのまま現場の手順書として活用できます。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
専用サーバー接続とは
専用サーバー接続は、クライアントからの各セッションごとに専用のサーバープロセス（専用サーバー）を割り当てる接続方式です。典型的なワークロード（バッチ、長時間の SQL、PL/SQL、データ移行など）に相性が良く、チューニングやトラブルシュートも直感的です。
【図1：専用サーバー接続の流れ】
クライアント → リスナー(1521) → 専用サーバープロセス → SGA/データファイル
│ │
│――――――――セッションごとに1つ――――――――│
ポイント：
・セッションごとに OS プロセス（専用サーバー）が1つ確保される
・同時接続数が増えるほど OS プロセス数も増える
- 既定（デフォルト）：多くの環境では、共有サーバーを有効化していなければ専用サーバーが既定になります。
- 強制：クライアント側の接続記述子に
SERVER=DEDICATEDを明示すれば、共有サーバー構成下でも専用を強制できます。
共有サーバー接続との違い（ざっくり比較）
【図2：専用 vs 共有のイメージ】
専用サーバー： 1セッション＝1プロセス（見通し良い・重い処理向き）
共有サーバー： 複数セッション⇔少数の共有サーバー（大量同時接続向き）
- 専用サーバー
- 長時間処理・高負荷処理で安定しやすい
- セッション単位で分離が明確（トラブルシュートが容易）
- 同時接続が非常に多いと OS プロセス数が膨らむ
- 共有サーバー
- 多数の同時接続（アイドルが多い）に有利
- ディスパッチャ／共有サーバーの設計と監視が必要
- 重い処理が混在するとスループットに影響が出やすい
共有サーバー接続についてはこちら。
専用サーバー接続の設定方法
接続記述子で専用サーバーを強制する（推奨）
tnsnames.ora で SERVER=DEDICATED を指定します。これがもっとも簡単で安全です。
# tnsnames.ora の例
ORCLPDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <dbhost.example.com>)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = <orclpdb1>)
(SERVER = DEDICATED)
)
)
SQL*Plus 例：
$ sqlplus demo_app/Password#1@ORCLPDB1
サーバー側で「実質専用のみ」にする（共有サーバー無効化）
共有サーバーを使わない構成に固定したい場合は、ディスパッチャを無効化し、SHARED_SERVERS を 0 にします。
-- 共有サーバー関連の無効化（SPFILE 使用例）
SQL> ALTER SYSTEM SET DISPATCHERS='' SCOPE=BOTH;
SQL> ALTER SYSTEM SET SHARED_SERVERS=0 SCOPE=BOTH;
-- 必要に応じてインスタンス再起動
注意：これを行っても、クライアント側で
SERVER=DEDICATEDを指定するベストプラクティスは変わりません。アプリごとに接続方式を明示でき、将来の構成変更にも強くなります。
動作確認と監視のポイント
いまのセッションが専用かどうかを確認する
V$SESSION.SERVER 列で判定できます（DEDICATED / SHARED など）。
-- 自分のセッションのサーバー種別を確認
SQL> SELECT sid, serial#, server
FROM v$session
WHERE audsid = USERENV('SESSIONID');
-- 特定ユーザーのセッション一覧
SQL> SELECT sid, serial#, server, machine, program
FROM v$session
WHERE username = 'DEMO_APP';
OS プロセス（SPID）との対応付け
SQL> SELECT s.sid, s.serial#, s.username, s.program,
p.spid AS os_spid
FROM v$session s
JOIN v$process p ON p.addr = s.paddr
WHERE s.username = 'DEMO_APP';
OS_SPIDが専用サーバープロセスの PID です。ps -ef | grep <SPID>で OS 側の観察が可能。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
リスナーからの確認
$ lsnrctl services
Service "orclpdb1" has 1 instance(s).
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
“DEDICATED” のハンドラが提示されていれば OK です。
実行例（ユーザー作成／権限付与／テーブル作成を含む）
以下は CDB 構成の PDB（例：ORCLPDB1） でアプリ用ユーザーを作成し、SERVER=DEDICATED で接続・実行する一連の例です。必要に応じて名称は環境に合わせて置き換えてください。
1) ユーザーと権限の作成（SYS で PDB に接続して実行）
-- SYSDBA で PDB へ
SQL> CONNECT sys/******@ORCLPDB1 AS SYSDBA;
-- アプリユーザー作成（デフォルト表領域 USERS を想定）
SQL> CREATE USER demo_app IDENTIFIED BY "Password#1"
DEFAULT TABLESPACE users
QUOTA 200M ON users;
-- 必要最小限の権限を付与
SQL> GRANT CREATE SESSION, CREATE TABLE TO demo_app;
SQL> GRANT UNLIMITED TABLESPACE TO demo_app; -- または QUOTA で制御
2) アプリユーザーでテーブル作成・データ投入
SQL> CONNECT demo_app/Password#1@ORCLPDB1;
-- サンプルテーブル
SQL> CREATE TABLE orders (
id NUMBER PRIMARY KEY,
item VARCHAR2(50) NOT NULL,
qty NUMBER NOT NULL,
ordered_at TIMESTAMP DEFAULT SYSTIMESTAMP
);
SQL> INSERT INTO orders (id, item, qty) VALUES (1, 'HDMI-CABLE', 2);
SQL> INSERT INTO orders (id, item, qty) VALUES (2, 'SSD-1TB', 1);
SQL> COMMIT;
SQL> SELECT * FROM orders ORDER BY id;
ID ITEM QTY ORDERED_AT
---------- --------- ------ ------------------------------------
1 HDMI-CABLE 2 2025-08-16 15:12:34.123456 +09:00
2 SSD-1TB 1 2025-08-16 15:12:34.223456 +09:00
3) 専用サーバーで接続しているかを確認
SQL> SELECT sid, serial#, server
FROM v$session
WHERE audsid = USERENV('SESSIONID');
SID SERIAL# SERVER
---------- --------- ---------
131 5123 DEDICATED
4) OS プロセスをひもづけて確認
SQL> SELECT s.sid, p.spid AS os_spid, s.program
FROM v$session s
JOIN v$process p ON p.addr = s.paddr
WHERE s.audsid = USERENV('SESSIONID');
SID OS_SPID PROGRAM
---------- ------ ---------------------------------
131 28451 sqlplus@dbhost (TNS V1-V3)
OS からも：
$ ps -fp 28451
UID PID PPID C STIME TTY TIME CMD
oracle 28451 28410 0 15:12 ? 00:00:00 oracle@ORCLPDB1 (DEDICATED)
メリット・デメリット・注意点
メリット
- 見通しの良さ：1 セッション 1 プロセスで、トラブルシュートが容易。
- 重い処理に強い：バッチ、ETL、長時間 SQL/PLSQL で安定しやすい。
- 設定がシンプル：
SERVER=DEDICATEDを接続記述子で明示すれば完了。 - 予測しやすいリソース消費：各セッションの上限見積りが立てやすい。
デメリット
- 大量同時接続には不利：プロセスがセッション数に比例して増える。
- OS リソース圧迫：
PROCESSES/SESSIONSパラメータや OS の制限に注意。 - コネクションストーム時のオーバーヘッド：プロセス生成が立て込みやすい。
注意点
- アプリごとの方針を明確化：重い処理は専用、軽量・大量同時接続は共有や接続プールなど、役割分担を。
- 上限制御：
V$PARAMETERでprocesses/sessionsを定期確認、計画的に見直す。 - プールの併用：中間層（UCP/OCI）や DRCP の併用で接続数を平準化できるケースもある。
よくある質問
Q1. 専用サーバーはデフォルトですか？
A. 多くの環境で、共有サーバーを構成していなければ専用が使われます。確実に専用にしたい場合は、接続記述子で SERVER=DEDICATED を指定してください。
Q2. 共有サーバーを構成していても、一部のアプリだけ専用にできますか？
A. 可能です。該当アプリの接続先（tnsnames.ora）で SERVER=DEDICATED を指定したエイリアスを用意します。
Q3. どのくらいの同時接続まで専用で耐えられますか？
A. サーバーの CPU/メモリ、OS のプロセス上限、PROCESSES/SESSIONS 設定値に依存します。負荷試験で実測・監視し、無理がある場合は共有サーバーや接続プールの導入を検討してください。
Q4. DRCP（Database Resident Connection Pooling）との違いは？
A. DRCP はサーバー側の接続プーリング機構で、専用/共有とは別カテゴリです。大量の短命接続が多い言語（例：PHP）で効果を発揮します。重い長時間処理なら専用のほうが扱いやすいケースが多いです。
Q5. 監視は何を見れば良いですか？
A. V$SESSION・V$PROCESS・リスナーの services/status、OS のプロセス数・メモリ・ロードアベレージを定常監視します。しきい値を決めてアラート化すると運用が安定します。
まとめ（要点）
- 専用サーバー＝1セッション1プロセス。重い処理・長時間処理に向く。
- 確実に専用へは、接続記述子に
SERVER=DEDICATEDを指定するのが最短。 - 共有サーバー無効化は
DISPATCHERS=''とSHARED_SERVERS=0。 - 確認は
V$SESSION.SERVER、V$PROCESSのSPID、lsnrctl services。 - 運用は
processes/sessions上限、接続プールの併用、監視設計が鍵。
[参考]
Oracle Database Net Services 管理者ガイド 19c
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント