在Oracle RAC环境中，新建连接最终由哪个实例承载，并不是完全随机的结果。服务属性中的CLB_GOAL参数决定了监听器在收到客户端连接请求后，按照什么样的统计维度来挑选目标实例。这个参数只有LONG和SHORT两个取值，但它们的差别会直接影响整个集群的会话分布和资源消耗。很多RAC节点负载不均的问题，表面看是连接数差异，实际根源往往在于CLB_GOAL的选择与业务连接模型不匹配。

一、LONG与SHORT的统计口径差异

SHORT目标关注的是每个实例的当前活动会话数。所谓活动会话，是指正在执行SQL或者处于活动事务中的会话，不包括空闲等待的会话。监听器会从各个实例获取活动连接计数，当新的连接请求到达时，优先把请求分发给活动会话最少的实例。这种策略在短连接场景下表现很好，比如典型的OLTP小额交易系统，连接建立后执行几条SQL就很快释放，活动会话数能够比较真实地反映实例的即时工作压力。

但SHORT有一个容易被忽视的盲区：它不统计空闲会话。如果应用使用连接池，连接建立后长时间保持不断开，大量空闲连接可能堆积在某个实例上。此时该实例的活动会话数看似很低，于是持续接收新连接，但进程数、内存占用和连接管理开销已经被空闲会话抬得很高，最终造成资源分配失衡。

LONG目标则把统计范围扩大到实例上的总会话数，既包括活动会话，也包括空闲会话。监听器按照总会话数来分配新连接，让每个实例承载的会话总数尽量接近。这种口径对长连接应用更加友好，尤其是使用中间件连接池、会话复用率较高的系统，能够避免某个实例因为活动会话少而不断被塞入新连接，导致总会话数远超其他节点。

换句话说，SHORT看的是瞬时工作负载，LONG看的是会话总量负担。两者不存在绝对的优劣，关键要看业务的连接生命周期以及系统资源的主要瓶颈在哪一侧。

二、监听器如何实现两种目标

Oracle RAC的每个实例都会通过后台进程将服务统计信息发布到监听器。对于SHORT目标，实例发布给监听器的核心指标是当前活动会话数；对于LONG目标，监听器使用的是该服务在各个实例上的总会话数。当客户端连接字符串配置了服务名，并且客户端将连接请求发送到SCAN监听器或节点监听器时，监听器会根据服务定义中的CLB_GOAL值选择最合适的实例，然后把连接转发过去。

这里需要区分客户端负载均衡和服务端负载均衡。客户端连接串中的LOAD_BALANCING参数负责在多个监听器地址之间随机选择，如果只有一个SCAN名称或者没有启用客户端负载均衡，请求仍然会到达监听器，由监听器依据CLB_GOAL完成实例级分配。也就是说，CLB_GOAL真正发挥作用的位置在监听器这一层，与客户端是否配置LOAD_BALANCING并不冲突。

在实际测试中，可以明显观察到两种目标的分配行为差异。例如建立一个包含两个实例的RAC服务，分别设置CLB_GOAL为SHORT和LONG，然后模拟连接池批量创建连接，再让一部分连接进入空闲状态。使用SHORT时，新连接会继续涌向活动会话少的实例；使用LONG时，新连接会优先分配到总会话数少的实例，从而让两边的会话总量保持更稳定的比例。

三、配置方法与验证手段

创建服务时可以通过srvctl命令直接指定CLB_GOAL。下面分别演示设置SHORT和LONG的用法，运行时负载均衡目标统一使用SERVICE_TIME便于对比。

# 创建使用SHORT连接负载均衡目标的服务
srvctl add service -db racdb -service app_svc_short -clbgoal SHORT -rlbgoal SERVICE_TIME
# 创建使用LONG连接负载均衡目标的服务
srvctl add service -db racdb -service app_svc_long -clbgoal LONG -rlbgoal SERVICE_TIME
# 启动服务
srvctl start service -db racdb -service app_svc_short
srvctl start service -db racdb -service app_svc_long

如果服务已经存在，只需要调整连接负载均衡目标，可以使用modify命令，无需停服重建。

srvctl modify service -db racdb -service app_svc_short -clbgoal LONG

配置完成后，可以通过DBA_SERVICES视图确认服务当前的CLB_GOAL值。这个视图会显示服务名、网络名称以及连接负载均衡目标等关键属性。

SELECT service_id, name, clb_goal
FROM dba_services
WHERE name IN ('app_svc_short', 'app_svc_long')
ORDER BY name;

要观察两种目标下的实际分配效果，可以查看每个实例上该服务的会话数量。总会话数用来验证LONG目标，活动会话数用来验证SHORT目标。

-- 查看各实例上的总会话数
SELECT inst_id, COUNT(*) AS total_sessions
FROM gv$session
WHERE service_name = 'app_svc_long'
GROUP BY inst_id
ORDER BY inst_id;
-- 查看各实例上的活动会话数
SELECT inst_id, COUNT(*) AS active_sessions
FROM gv$session
WHERE service_name = 'app_svc_short'
  AND status = 'ACTIVE'
GROUP BY inst_id
ORDER BY inst_id;

测试时建议使用连接池模拟真实业务，因为单纯用SQL*Plus反复连接断开，连接生命周期过短，很难体现出LONG和SHORT的差异。让一部分连接执行完SQL后保持空闲，再观察新连接的分配方向，就能更直观地理解两种统计口径带来的不同结果。

四、选型建议与常见误区

选择SHORT还是LONG，核心判断依据是业务连接的保持时间和空闲比例。如果应用连接建立后很快释放，或者空闲会话占比很低，SHORT能够让活动负载更均匀。如果应用采用连接池，连接长时间驻留，大量会话处于空闲状态，LONG更有利于控制各实例的总体会话规模，避免资源的隐性倾斜。

下面通过一个简单表格对比两者的关键差异。

常见误区之一是认为SHORT等同于短连接，LONG等同于长连接。实际上它们描述的是统计会话数时的口径，而不是对连接生命周期的限制。即使使用长连接，如果所有连接都在持续执行SQL，活动会话数始终接近总会话数，SHORT同样能有效工作。

另一个误区是把CLB_GOAL当成运行时负载均衡的替代品。CLB_GOAL只作用于新建连接的选择阶段，连接建立之后的工作请求调度由RLB_GOAL控制。典型的组合是CLB_GOAL使用LONG来平衡会话总量，RLB_GOAL使用SERVICE_TIME根据实例响应时间调整请求路由，两者配合才能实现更完整的负载管理。

还有一点值得注意，CLB_GOAL的统计信息发布存在一定延迟，监听器看到的会话计数并不是毫秒级实时值。因此在快速批量创建连接时，可能出现短暂的分配不均衡，这属于正常现象，不应单纯根据几秒钟的分布判断配置失效。

总的来说，Oracle RAC集群中的LONG与SHORT并没有绝对推荐项，只有与业务连接模型匹配的选择。理解它们各自统计的是活动会话还是总会话，再结合测试观察实际分配结果，才能让服务负载均衡策略真正贴合系统运行状态。