如何配置Oracle共享服务器_DISPATCHERS参数与网络连接池

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