DISPATCHERS 参数应写在 init.ora 或 SPFILE 中，属数据库实例参数，需通过 ALTER SYSTEM SET ... SCOPE=BOTH; 生效；它控制共享服务器模式下的 dispatcher 进程数量，与 listener.ora 无关。
DISPATCHERS 参数写在哪？不是在 listener.ora 里
很多人一上来就去改 listener.ora，结果重启监听器没用——dispatchers 是数据库实例参数，必须设在 init.ora 或 spfile 里，通过 alter system 生效。它控制的是实例启动后创建多少个 dispatcher 进程，跟监听器配置是两件事。
常见错误现象：lsnrctl status 看不到 DEDICATED 以外的服务名；客户端连上后查 v$session.server 全是 DEDICATED；v$dispatcher 查不到记录。
- 使用场景：启用共享服务器（Shared Server）模式时才需要配，
SHARED_SERVERS> 0 是前提 - 参数差异：
DISPATCHERS='(PROTOCOL=TCP)(DISPATCHERS=2)'表示启 2 个 TCP dispatcher；加(SERVICE=orclXDB)可指定服务名，否则默认用 DB_NAME - 修改后必须执行
ALTER SYSTEM SET DISPATCHERS='...' SCOPE=BOTH;，仅改 SPFILE 不生效
为什么设置了 DISPATCHERS 却没看到 dispatcher 进程？
最常被忽略的一点：Oracle 不会“预创建”所有 dispatcher 进程。它按需启动，默认有延迟和上限控制。哪怕你写了 (DISPATCHERS=5)，初始可能只起 1 个，后续根据连接压力动态拉起。
验证方式：连接后查 v$dispatcher，看 STATUS 是否为 WAIT；再看 v$shared_server_monitor 的 CURRENT_DISPATCHERS 值。
- 容易踩的坑：误以为没生效，反复重启实例；其实要等真实连接进来触发调度逻辑
- 性能影响：dispatcher 过多会争抢共享池内存，每个 dispatcher 默认占约 1MB PGA；建议从 2–4 起步，观察
v$queue中WAIT队列长度再调 - 兼容性注意：如果客户端用 JDBC Thin，必须确保 URL 含
server=shared，否则仍走专有模式
网络连接池怎么和 DISPATCHERS 配合？
Oracle 自身没有“连接池”概念，所谓连接池通常指应用层（如 UCP、Tomcat JDBC Pool）或中间件（如 WebLogic）维护的连接缓存。它们和 DISPATCHERS 的关系是间接的：连接池复用的每个物理连接，在共享服务器下，最终都由某个 dispatcher 转发给 shared server 处理。
关键点在于连接池的 idle timeout 和 dispatcher 的 CONNECT_TIMEOUT 要对齐，否则会出现“连接还活着但 dispatcher 已断开”的假死现象。
- 使用场景：Java 应用配 UCP 时，
connectionPool.setInactiveConnectionTimeout(60)应 ≤ dispatcher 的CONNECT_TIMEOUT（默认 60 秒） - 参数差异：dispatcher 的超时由
(CONNECT_TIMEOUT=30)控制，写在DISPATCHERS字符串里，不是独立参数 - 容易踩的坑：连接池设了 300 秒空闲超时，但 dispatcher 默认 60 秒就断开 client socket，导致应用拿到“已断连”的连接还往里发 SQL，报错
ORA-03113: end-of-file on communication channel
如何确认当前连接真的走共享路径？
不能只看参数是否设置，得从会话现场验证。最直接的办法是登录后立刻查两个视图，缺一不可。
- 查
v$session：重点看SERVER列是否为SHARED，不是DEDICATED或空值 - 查
v$session_connect_info：确认NETWORK_SERVICE_BANNER包含Shared Server，且DISPATCHER列非空 - 性能线索：
v$queue中QUEUED值持续 > 0，说明 dispatcher 队列有积压，共享路径确实在工作 - 容易踩的坑：用
sqlplus / as sysdba登录永远是专用模式；必须用普通用户、且连接字符串明确带server=shared（如jdbc:oracle:thin:@//host:1521/orcl?server=shared）
真正难的不是配参数，是让应用流量稳定落在 dispatcher 上——协议、驱动、连接串、防火墙 MTU、甚至客户端操作系统 socket 缓冲区大小，都会悄悄绕过你设的 DISPATCHERS。先跑通一个连接，再放大并发，比一开始就调高数值靠谱得多。
