service必须显式启动，否则监听器无法识别，应用连接报ora-12514；需先用srvctl status service确认状态，若“not running”则执行srvctl start service，并通过lsnrctl services验证load字段是否出现。
Service必须显式启动，否则监听器根本看不到
srvctl add service只写入集群注册表，不启动服务。没启动的服务在lsnrctl services里查不到，应用连就会报ORA-12514。这不是配置错，是压根没跑起来。
- 先确认状态：
srvctl status service -d <db_name> -s <service_name></service_name></db_name>，如果显示“not running”，立刻执行srvctl start service -d <db_name> -s <service_name></service_name></db_name> - 再验证监听器是否识别：
lsnrctl services LISTENER_SCAN1 | grep -A 5 "Service \"<service_name>\""</service_name>，输出里必须有service_handler="DEDICATED", load=xx字段，否则说明注册失败 - 服务启动依赖实例在线，用
srvctl status instance -d <db_name></db_name>确认目标实例处于ONLINE状态
CLB_GOAL和GOAL不能混用，作用层级完全不同
CLB_GOAL管的是新连接怎么分发，GOAL管的是已建连接要不要重路由——后者只在启用FAN且配合UCP/OJDBC时才生效。很多人把两者都设成SERVICE_TIME，结果发现连接池里的老连接死活不切，就是没搞清边界。
-
CLB_GOAL = SERVICE_TIME：SCAN Listener根据各实例最近的V$SERVICEMETRIC.CURRENT_LOAD（需AWR启用）选节点，适合响应时间敏感型业务 -
CLB_GOAL = THROUGHPUT：按TPS分发，适合高并发OLTP场景；设完必须srvctl stop service → srvctl start service才加载 -
GOAL = SERVICE_TIME仅影响支持FAN的连接池（如UCP），让池子主动把慢连接迁走；设GOAL = NONE则只做故障转移，不做动态重路由
客户端必须用SERVICE_NAME，INSTANCE_NAME或SID会绕过全部机制
Oracle RAC的负载均衡、故障转移、TAF、动态重定位全靠SERVICE_NAME驱动。写INSTANCE_NAME=rac1或SID=rac1等于直接拔掉RAC的电源线——连接硬绑到单实例，后续所有服务配置都失效。
- tnsnames.ora里只保留
(SERVICE_NAME = myapp_svc)，删掉任何INSTANCE_NAME、SID、SERVER=DEDICATED等冗余项 - Java应用用JDBC Thin URL时，格式必须是
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=myapp_svc)))，URL里加LOAD_BALANCE=on无效 - 不同业务线强制拆成不同service：比如
reporting_svc和trading_svc，再用DBMS_SERVICE.MODIFY_SERVICE动态调实例归属，这才是真实隔离
preferred/available实例配错，服务要么起不来要么切不动
配-r和-a不是填两个实例名就完事。administrator-managed库和policy-managed库规则相反，填错直接报PRKO-2002或服务卡死在单点。
- administrator-managed（最常见）：直接写实例名，例如
-r rac1,rac2 -a rac3，表示默认在rac1/rac2跑，rac3只作备用 - policy-managed（用server pool）：
-r必须填pool名，填实例名会失败；-a不支持server pool模式，留空即可 - 只设
-r rac1不设-a，rac1挂了服务直接offline；设了-a rac2但没开failover_type=SESSION，故障时连接仍会断开
最容易被忽略的是PMON上报延迟和DNS缓存。改完REMOTE_LISTENER后不立刻执行ALTER SYSTEM REGISTER，SCAN Listener可能等3分钟才拿到新负载；而连接池预热阶段，若SCAN DNS返回IP顺序固定，初始几十个连接会全扎堆一个实例——这不是配置问题，是时间窗口和基础设施协同问题。
