oracle rac不提供sql级qos，必须通过service_name绑定dbms_resource_manager消费组，并在各实例启用统一resource_manager_plan实现业务流量分级控制。
oracle rac 本身不提供应用层流量级别的 qos（如按 sql 类型、客户端 ip 或服务名限速），真正的业务级资源管控必须依赖 dbms_resource_manager + 服务名（service）+ 客户端连接上下文的组合，而非 crs 层的 qos management（后者只管服务器池级 cpu/内存配额，不识别 sql 或会话语义）。
用 DBMS_RESOURCE_MANAGER 绑定服务名做资源分组
Oracle RAC 中区分“不同业务流量”的最小可控单元是数据库服务（service_name），不是实例、节点或应用用户名。你必须为每类业务创建独立服务，并将其绑定到 Resource Manager 消费组。
- 创建服务时指定
clb_goal=SHORT（短连接）或clb_goal=LONG（长连接），影响负载均衡策略，但不影响资源限制 - 服务必须通过
srvctl add service添加，并在srvctl start service后才生效；仅在数据库内建 service 不被集群识别 - 每个服务需映射到一个消费组（如
OLTP_GROUP、REPORT_GROUP），再通过DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE设置 CPU、I/O、并发会话等硬限制 - 注意：Resource Manager 的 CPU 资源限制在 RAC 中是“实例本地生效”，不是跨实例全局强制——若某服务连接只落在 node1，node2 上的限制不会起作用
为什么不能直接用 Oracle QoS Management 管业务流量
Oracle Database QoS Management（通过 EM Cloud Control 配置）管理的是 server pool 级别的 CPU 和内存配额，它调度的对象是“运行数据库实例的物理/虚拟机”，不是“某条报表 SQL”或“某个 Java 应用的连接”。它无法感知 SQL 类型、模块名、操作类型（SELECT vs INSERT）、甚至无法区分不同 service_name 的资源消耗差异。
- 如果你看到 EM 中 “Quality of Service Management” 页面里只能选 server pool、定义响应时间 SLO（如 ≤500ms），那说明你正在配置的是集群级资源水位线，不是业务流控
-
QOS_POLICY=ENABLED的 server pool 只影响 CRS 是否允许 QoS Agent 启动，跟单个会话能跑多快毫无关系 - 试图用 QoS Management 限制“报表服务慢查询拖垮 OLTP”会失败——它最多在整体 CPU 过载时把整个实例降频，而不是 kill 掉那个执行了 3 小时的 SELECT
真实可行的业务流量分级控制链路
要实现“报表查询不抢 OLTP 事务资源”，必须串联三层机制，缺一不可：
- 客户端连接时明确指定
service_name（例如 JDBC URL 加?service_name=hr_oltp），不能依赖默认 service - 数据库侧用
DBMS_SERVICE.CREATE_SERVICE创建服务，并在DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING中将该 service 映射到对应消费组（如HR_OLTP_GROUP） - Resource Plan 中对
HR_OLTP_GROUP设置CPU_P1=100（最高优先级）、PARALLEL_DEGREE_LIMIT_P1=4（防并行滥用），对报表组设CPU_P2=30+ACTIVE_SESS_POOL_P1=8（硬性并发数封顶） - 必须启用
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'MY_RAC_PLAN'，且该 plan 需在所有 RAC 实例上一致；否则节点间策略不同步会导致行为不一致
容易被忽略的 RAC 特有陷阱
在 RAC 环境下启用 Resource Manager，以下几点不检查就会出问题：
-
GV$RSRC_CONSUMER_GROUP显示各实例上消费组活跃会话数，但GV$RSRC_SESSION_INFO才能看到每个会话实际归属的消费组——别只看V$视图，它只反映本实例 - 如果使用 SCAN listener 连接，确保
local_listener和remote_listener都正确指向各自节点的 VIP，否则 service 路由可能绕过 Resource Manager 上下文继承 - Resource Manager 对并行查询（PX）的控制力度弱于串行 SQL；
PARALLEL_SERVERS_TARGET是实例级总控，而消费组的PARALLEL_DEGREE_LIMIT_P1仅作用于单个会话发起的 PX，不防跨会话累积 - 审计日志和闪回日志写入不受 Resource Manager 限制——它们走的是后台进程路径，不属于任何消费组
真正管住业务流量的不是“QoS”这个词本身，而是你是否让每条连接从建立那一刻就携带可识别、可映射、可限制的 service 标签，并让 Resource Manager 在每个实例上持续执行这个标签对应的规则。RAC 的分布式本质决定了，任何想绕过 service + consumer group + plan 三层绑定的“统一管控”，都会在某个节点上失效。
