control file sequential read等待高90%非磁盘慢，而是V$视图查询、RMAN或expdp高频低效访问控制文件所致；应先查v$session定位等待会话及module，再关联v$sql分析SQL文本与执行计划，确认是否含XML操作、全表扫描或大量NOT EXISTS子查询，并检查控制文件状态与路径。
control file sequential read 等待高，90%不是磁盘慢，而是控制文件被高频、低效访问——尤其集中在 V$ 视图查询、RMAN 元数据操作或 expdp 表空间枚举上。
查谁在读控制文件（v$session + event 过滤）
先确认是不是前台或后台进程真正在“卡”在控制文件读上：
- 执行
SELECT sid, serial#, username, program, module, event, seconds_in_wait FROM v$session WHERE event = 'control file sequential read' AND state = 'WAITING'—— 注意只看state = 'WAITING'，status = 'ACTIVE'才是真阻塞 - 若
module是Data Pump Worker或rman，基本可锁定是 expdp/RMAN 引发的元数据扫描；若是SQL*Plus或应用连接，重点查它刚执行的 SQL 是否含V$BACKUP、V$TABLESPACE等视图 - RAC 环境必须在每个节点单独查，
v$session不跨实例
定位具体 SQL（v$sql + v$sqlarea 关联）
拿到等待会话的 sql_id 后，直接查执行计划和文本：
- 用
SELECT sql_fulltext FROM v$sqlarea WHERE sql_id = '看原始语句，重点关注是否含' SYS_XMLGEN、XMLFORMAT.createFormat2（这是 expdp 慢的典型特征，见 Bug 14794472） - 若语句含大量
NOT EXISTS子查询或对SYS.KU$_TABLESPACE_VIEW全表扫描，说明表空间数过多（如 3700+）触发了低效元数据遍历 - 手工执行该 SQL 并加
/*+ NO_XML_QUERY_REWRITE */提示，或临时禁用 XML 格式化，验证是否提速
检查控制文件副本与 I/O 路径（物理层确认）
虽然多数情况不是磁盘问题，但需快速排除硬件/配置异常：
- 运行
SELECT name, status FROM v$controlfile，确认所有控制文件状态为ONLINE，且路径不在 NFS 上（NFS 可能导致ORA-01172类错误） - 用
ls -l检查各控制文件所在文件系统是否满、是否有硬链接或挂载选项异常（如noac） - 对比
AWR中control file sequential read的平均等待时间（Avg wait (ms)）：若 > 10ms 且持续上升，再查存储响应时间；若 20），纯属逻辑访问过载
规避高频读的临时手段（不改架构时的实操）
当无法立即减少表空间数或升级补丁时，可用以下方式缓解：
- 对 expdp，加参数
EXCLUDE=TABLESPACE（如果业务允许不导出表空间定义），或拆成按用户导出，绕过全库元数据扫描 - 对 RMAN，避免频繁执行
LIST BACKUP或CROSSCHECK，改用 catalog 模式并定期RESYNC CATALOG，减少直接读控制文件 - 禁止非必要会话查询
V$BACKUP、V$ARCHIVED_LOG等重型视图，改用物化视图或定时快照表替代
真正难处理的是那种“没报错、没长事务、但控制文件读 Waits/txn 突然翻倍”的情况——它往往藏在某个定时脚本里反复调用 DBMS_METADATA.GET_DDL('TABLESPACE', ...)，或者监控工具每分钟刷一次 V$LOGHIST。这类问题不会出现在 AWR top SQL 里，得靠 v$session_wait 实时抓取 + sql_id 反查源头。
