srvctl 不管理微服务连接池，仅操作 OCR 注册的集群资源（如数据库、实例、service 等）；微服务连接池属应用层行为，由 HikariCP、UCP 等实现，srvctl 既不感知也不支持其启停、配置或状态查询。
Oracle 23c RAC 中 srvctl 不管理微服务连接池 —— 它根本不认识这个概念。
srvctl 只操作 OCR 中注册的集群资源：数据库、实例、监听器、service（即传统 Oracle Service）、server pool 等。所谓“微服务连接池”是应用层或中间件（如 Spring Boot + HikariCP、Oracle Wallet + JDBC 连接池、或 Oracle Autonomous Database 的 Microservices API）的行为，不在 CRS 资源模型内。srvctl 对它既不感知，也无法启停、配置或监控。
srvctl add service 创建的 service 不是“连接池”，而是故障转移单元
你在 23c RAC 中用 srvctl add service 添加的资源，比如：
srvctl add service -d orcl -s app_svc -r node1 -a node2 -P basic -e select -w 5 -z 3
这个 app_svc 是一个集群 service 资源，作用是：
- 告诉监听器（
lsnrctl）该 service 应该在哪节点上注册（首选/备用） - 为 TAF（Transparent Application Failover）提供元数据支撑（
-P、-e等参数生效的前提） - 被客户端 JDBC URL 中的
service_name=app_svc引用，从而绑定到特定节点策略
但它本身不维护连接、不复用会话、不做连接验证或超时回收 —— 这些全是应用端连接池（如 UCP、HikariCP、Tomcat JDBC Pool）的职责。
为什么你查不到“微服务连接池”状态？因为 srvctl status 根本不支持
执行以下命令只会返回空或报错：
srvctl status service -s app_pool
常见错误现象：
-
PRCD-1001: Service app_pool does not exist：service 名未在 OCR 注册（不是“没启动”，是压根不存在） -
PRCR-1001: Resource does not exist：尝试对非标准资源类型（如自定义连接池进程）执行 srvctl 操作
原因很直接：srvctl 的资源类型白名单里没有 connection_pool 或 microservice_pool。它只认 ora.、ora.、ora. 这类命名规范的 CRS 资源。
真正需要关注的是 service + 客户端连接池的协同配置点
在 23c RAC 中让“微服务”稳定使用 service，关键不在 srvctl，而在两端对齐：
-
TAF 类型必须匹配应用行为：若应用使用长连接且执行大量
SELECT，务必设-e select；若只是短事务，-e session更安全 -
JDBC URL 必须显式指定 service_name，不能只靠 SCAN IP + SID：
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scan.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=app_svc))) -
UCP（Universal Connection Pool）需启用 FAN：设置
oracle.ucp.fanEnabled=true，否则连接池无法响应 service 漂移事件，会继续往宕机节点发请求 -
避免混淆 service 名与 PDB 名：23c 支持多租户，但
srvctl add service -d orcl -pdb pdb1 -s api_svc中的-pdb仅影响 service 默认路由目标，并不创建“PDB 级连接池”
srvctl 做不了连接健康检查、不会自动剔除失效连接、也不参与连接创建时机决策 —— 这些逻辑全在应用代码或连接池配置里。你调用 srvctl start service -s app_svc，只是把 service 资源拉起来并注册到监听器；之后第一个 JDBC 连接进来时，才由连接池决定是否新建物理连接、复用旧连接、或触发 FAN 回调。
最容易被忽略的一点：srvctl 管理的 service 在节点重启后默认不会自动恢复（除非显式 srvctl enable service），而连接池如果没配 testOnBorrow 或 validationQuery，就会持续向已下线的 service 发请求，直到连接超时。这不是 srvctl 的问题，但排查时常常误以为是它没起作用。
