优先检查sequence未启用CACHE或误开ORDER，改用CACHE 1000 NOORDER；避免单调递增索引前导列，启用REVERSE KEY或哈希扰动；RAC中undo表空间必须实例独占且不共享，redo日志需ASM高速存储并控制单组300–800MB。
Oracle RAC高并发写入时的热点块争用怎么破？
rac下高并发写入最常卡在gc buffer busy acquire或enq: tx - row lock contention，本质是多个实例争抢同一数据块（比如单个主键序列生成的id导致的索引叶块热块）。这不是undo或redo配置能直接解决的问题。
- 优先检查是否存在
sequence未启用CACHE或ORDER被误开——用SELECT sequence_name, cache_size, order_flag FROM dba_sequences确认；建议设CACHE 1000 NOORDER - 索引设计上避免单调递增字段（如
created_date）做前导列，可改用REVERSE KEY索引或加哈希扰动（如MOD(id, 16)分区） - 确认表是否启用了
ASSM（自动段空间管理），禁用FREELISTS——RAC中手工管理空闲列表会加剧争用
undo表空间在RAC里要不要每个实例单独配？
必须每个实例独占一个undo表空间，且不能共用。RAC中UNDO_MANAGEMENT=auto时，每个实例由UNDO_TABLESPACE参数指定自己的undo表空间，共享undo会导致事务可见性错乱和ORA-01555。
- 检查命令：
SHOW PARAMETER undo_tablespace，确保各节点值不同（如UNDOTBS1、UNDOTBS2） - undo大小按峰值事务量估算：每秒最大DML事务数 × 平均事务undo块数 × 1.5（预留），不建议盲目调大
UNDO_RETENTION——它只影响保留时间，不扩大空间 - 避免在undo表空间上启用
AUTOEXTEND无限增长，应预分配足够大小并监控v$undostat中的unexpiredblkstotal与expiredblkstotal比例
redo日志在RAC中如何分配才不拖慢提交？
RAC的redo写入瓶颈不在“分配”，而在“同步”——每个实例的LGWR必须将redo传给其他实例的LMS进程做全局缓存一致性校验。慢就慢在这里，不是磁盘I/O本身。
- 在线redo日志组必须跨所有实例可用（即放在ASM磁盘组或集群文件系统），但每个实例有自己的
LOGFILE成员，通过ALTER DATABASE ADD LOGFILE INSTANCE 'rac1' ...显式绑定 - 禁止把redo日志放在NFS或低延迟容忍差的存储上；ASM推荐使用
EXTERNAL REDUNDANCY+高速SSD，避免镜像带来双倍IO - 如果出现
log file sync等待过高，先查v$system_event中该事件的平均等待时间，再看是否因频繁小事务（如循环单条INSERT）导致——合并为BULK INSERT或启用COMMIT WRITE BATCH NOWAIT缓解
为什么调大undo/redo参数后性能反而更差？
常见于盲目增大UNDO_RETENTION却没扩容undo表空间，或给redo日志设了超大size（如2GB）但归档跟不上，触发log file switch (archiving needed)阻塞。
- undo表空间不足时，Oracle会主动覆盖未过期undo，导致ORA-01555；此时增大
UNDO_RETENTION只会加速报错，应先扩容数据文件 - redo日志太大 → 切换频率降低 → 单次归档压力暴涨 → 归档进程
ARCn卡住；生产环境单个redo日志建议控制在300–800MB，切换间隔保持在15–20分钟 - RAC中还要确认
_gc_policy_time（默认60秒）未被误调小——过短会导致频繁重平衡，放大全局锁开销
真正卡点往往藏在序列、索引、redo传输链路这些地方，而不是undo/redo的数字本身。
