必须用独立service+ADG备库双层隔离,单靠srvctl add service仅实现请求分流而无法隔离SGA、Redo、Undo及I/O资源;真正隔离需通过ADG备库物理分离,RAC service仅作流量路由标签。
必须用独立 service + adg 备库双层隔离,只靠 rac service 分流不能防报表拖垮交易。
RAC 的 srvctl add service 确实能把报表请求路由到指定实例,但物理上仍共享同一套 SGA、Redo、Undo 和磁盘 I/O。一旦报表 SQL 执行大量全表扫描或并行查询,会直接争抢 buffer cache、触发大量 physical reads,甚至把交易事务的 undo 段撑爆 —— 这不是“路由隔离”,是“请求分流”,本质仍是共用资源。
gv$sysstat 里 physical reads 或 db block gets 突增,gv$session_longops 出现大量报表会话卡在 direct path read
-r rac1,rac1 实例的 CPU、内存、IO 全部打满时,整个数据库响应都会变慢instance_groups 和 parallel_instance_group 参数只能限制并行任务范围,对串行报表查询无效核心逻辑是让报表完全离开主库:用 RAC service 把报表流量引向专用 ADG 备库,主库只跑交易;RAC service 在这里只起“流量标签”作用,不承担资源隔离责任。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;ALTER DATABASE OPEN READ ONLY;ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
report_svc)srvctl add service -d reportdb -s report_svc -r rep1,rep2 -P BASICreportdb)下,不是主库名SERVICE_NAME=report_svc,且 TNS 中 ADDRESS 指向备库节点监听器,而非主库缺一不可,否则隔离失效:
MOUNTED 且正在应用 Redo —— 查 v$database,OPEN_MODE 为 MOUNTED、DATABASE_ROLE 为 PHYSICAL STANDBY,否则 ADG 启动失败PROTECTION_MODE 不能是 MAXIMUM PROTECTION —— 它会阻塞 ADG 的只读查询,导致报表报超时或 ORA-10458-r rep1,rep2)必须是备库所在 RAC 节点,且这些实例的数据库名(db_name)和 DB_UNIQUE_NAME 必须与备库一致,否则 srvctl status service 显示 not running真正起隔离作用的是 ADG 的物理分离,RAC service 只是让这层分离可被客户端精准寻址。没 ADG,再细的服务划分也挡不住 I/O 和内存的互相踩踏。