oracle rac索引块争用需从物理路径隔离、b树结构优化、块级锁粒度三层面协同解决，单点优化无效；新建indexdg后io仍集中同一lun，主因磁盘组映射同raid组且未配置failgroup或high类型，导致asm无法跨路径条带化。
Oracle RAC 中索引块争用不是靠加索引或调参数就能压下去的——它本质是物理路径没隔离、B树结构被并发写穿、锁粒度卡在块级这三个层面同时失效的结果。单点优化基本无效。
为什么新建INDEXDG磁盘组后IO还是打在同一LUN上
常见错误现象是：创建了INDEXDG，把索引表空间建在上面，但iostat -x 1仍显示emcpoweru（data_center_17）%util持续95%+，而emcpowert（data_center_16）几乎空闲。
- 根本原因不是磁盘组名字起得不够好，而是两个磁盘组实际映射到了同一RAID组（比如都落在CKM00141100044的同一组15K SAS盘）
-
INDEXDG创建时用了默认COMPATIBLE.ASM='12.1.0.0.0'，没启用ASM_DISKGROUP_TYPE=HIGH或显式指定FAILGROUP，导致ASM无法跨物理路径做条带化 - Oracle不认“表空间名含INDX”，只认
v$asm_alias里的TYPE='INDEX'和AU分配位置；没绑定模板，文件就按默认策略落盘
验证方法：SELECT f.name, d.path, d.failgroup FROM v$asm_file f, v$asm_disk d, v$asm_alias a WHERE a.name = 'YOUR_INDEX_NAME' AND a.file_number = f.file_number AND f.disk_kffxp = d.disk_number AND f.group_number = d.group_number; ——若d.path仍是emcpoweru，说明没生效。
gc current split等待事件怎么快速收敛
这是RAC索引分裂独有的性能黑洞：单次分裂涉及6–10次跨节点通信，比单实例慢5–8倍。它不是等出来的，是结构同步卡住的。
- 典型触发场景包括：单调递增主键并发插入（如订单表）、在线索引重建（
ALTER INDEX REBUILD）、PCTFREE=0加速块填充、B树深度>4 - 关键参数要调：
_index_split_prefetch_size设为非零值启用批量优化；_gc_affinity_time不能低于30分钟，否则节点间资源亲和性频繁重置 - 序列必须缓存且绑定实例：
CREATE SEQUENCE seq CACHE 1000 NOORDER INSTANCES 2，否则NOCACHE或CACHE 20在高并发下必然引发跨节点争用
enq: TX - index contention等待时间超200秒意味着什么
平均等待202540ms（>200秒）不是普通争用，是进程已hang住。AWR里看到索引对象Row Lock Waits占比最高，但插入频率、索引分裂次数、负载都没变——说明不是业务量问题，而是锁链卡死。
- 先查
v$lock中是否多个会话对同一索引段持有TX锁且长时间不释放 - 再看
v$session_longops是否有Parallel Query卡在Sort Segment，这常是MLOG$_表行锁热点的副产品 - 反向键索引（
REVERSE KEY）可缓解但不万能：它只对等值查询有效，一旦SQL含BETWEEN或>，Oracle会直接放弃走索引，反而更慢
物化视图刷新在RAC里为何锁得更死
RAC下DBMS_MVIEW.REFRESH默认atomic_refresh=TRUE，会触发TRUNCATE+INSERT，强制广播TM全局锁——哪怕只刷几万行，所有实例也得协商一致才能继续。
- 错峰调度必须精确到毫秒级：
NEXT_DATE不能只写SYSDATE + 1/24，得用SYSDATE + 1/24 + DBMS_RANDOM.VALUE(0, 1)/86400错开 -
atomic_refresh=FALSE改走DELETE+INSERT，只持TX行锁，但前提是FAST可刷新：SELECT fast_refreshable FROM user_mviews必须返回FAST - MLOG$_表必须建复合索引：
CREATE INDEX idx_mlog_snap_seq ON mlog$_xxx(snaptime$$, sequence$$)，否则多实例并发扫描时反复争抢同一数据块
真正难处理的从来不是单个索引设计，而是索引、物化视图、序列、ASM路径这四层耦合在一起的锁链。拆开任何一层都可能让其他层暴露新瓶颈。
