环境：Oracle 11g RAC + ASM，业务库 FSPDB，两个实例（fspdb1 @ cspserver1，fspdb2 @ cspserver2）
一、故障背景
本次故障由业务侧首先发现，而非监控或备份系统告警。
业务层面症状：
- 程序频繁卡住，接口响应变慢
- 部分操作长时间无返回
- 偶发数据库连接异常
随后发现的关联问题：
- RMAN 备份卡住或失败
- EXP / EXPDP 导出部分对象卡住
- 问题集中在接口日志表
FDP.BDP_ITF_ACCESSLOG
排查目标：
- 解释业务程序为何频繁卡住
- 找出 RMAN / EXPDP 备份失败原因
- 判断是否存在数据库对象损坏
- 验证是否为 RAC 单节点异常
- 尽快完成可用数据备份，恢复业务稳定
二、故障现象
2.1 业务程序频繁卡住
数据库侧观察到大量业务会话等待，主要集中在以下 SQL（SQL_ID：77whgc1ruc23s）：
INSERT INTO BDP_ITF_ACCESSLOG
(ID, ORG_CODE, APP_CODE, ITF_ID, CALL_TIME,
TAKING_TIME, DATA_COUNT, SUCCESS, ERROR_MSG,
REQUEST_PARAM, RESPONSE_RESULT)
VALUES
(:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11)
会话等待事件：
| 等待事件 | 含义 |
|---|---|
enq: XL - fault extent map |
extent map 访问异常 |
read by other session |
数据块读取等待 |
ASM file metadata operation |
ASM 元数据操作 |
buffer busy waits |
缓冲区竞争 |
KSV master wait |
节点间协调等待 |
这些等待说明问题已超出慢 SQL 范畴，涉及数据块读取、ASM 元数据和节点 I/O 链路。
2.2 RMAN 备份失败
逐个 datafile 备份后，异常集中在：
datafile 8：+DATA/fspdb/datafile/dms_data.1891.1231221965
RMAN 读取该文件时卡住或失败，说明问题在于访问该 ASM 数据文件的链路本身，而非 RMAN 命令。
2.3 EXP / EXPDP 导出异常
绕开 RMAN 尝试逻辑导出，出现以下报错：
EXP-00056: ORACLE error 1115 encountered
ORA-01115: IO error reading block from file
ORA-01110: data file 8: '+DATA/fspdb/datafile/dms_data.1891.1231221965'
ORA-15055: unable to connect to ASM instance
逻辑导出在读取同一对象时也异常，进一步指向 ASM / 数据文件访问链路问题。
三、问题对象定位
3.1 定位异常数据文件
SELECT file_id, tablespace_name, file_name
FROM dba_data_files
WHERE file_id = 8;
FILE_ID : 8
TABLESPACE_NAME : DMS_DATA
FILE_NAME : +DATA/fspdb/datafile/dms_data.1891.1231221965
3.2 查看 file#8 上的对象
SELECT owner, segment_name, segment_type, file_id,
ROUND(SUM(bytes)/1024/1024, 2) size_mb
FROM dba_extents
WHERE file_id = 8
GROUP BY owner, segment_name, segment_type, file_id
ORDER BY size_mb DESC;
OWNER SEGMENT_NAME SEGMENT_TYPE FILE_ID SIZE_MB
FDP BDP_ITF_ACCESSLOG TABLE 8 64
file#8 上的主要对象即为接口日志表 FDP.BDP_ITF_ACCESSLOG。
3.3 表结构
该表包含两个 CLOB 字段，初期怀疑是 LOB 导致问题。但查询 LOB 段分布后确认：LOB segment 主要位于 file#6，file#8 上主要是 TABLE 段 extent，LOB 字段并非直接根因。
字段：ID, ORG_CODE, APP_CODE, ITF_ID, CALL_TIME,
TAKING_TIME, DATA_COUNT, SUCCESS, ERROR_MSG,
REQUEST_PARAM(CLOB), RESPONSE_RESULT(CLOB)
四、分段读取验证
使用 rowid 范围对 file#8 做分段读取测试：
SELECT COUNT(*)
FROM FDP.BDP_ITF_ACCESSLOG
WHERE rowid BETWEEN
dbms_rowid.rowid_create(1, 106051, 8, 128, 0)
AND
dbms_rowid.rowid_create(1, 106051, 8, 255, 32767);
COUNT(*) = 2317
Elapsed: 00:05:27.21
结论： file#8 上的数据并非完全不可读，但少量数据块读取耗时超过 5 分钟，足以导致业务卡顿、RMAN 卡住和 EXPDP 失败。
五、关键等待事件分析
故障期间，以下进程均出现异常等待：
| 进程 | 等待事件 |
|---|---|
| DBW0 / DBW1 | enq: XL - fault extent map |
| SMON | enq: CR - block range reuse ckpt |
| Data Pump Worker DW00 | enq: XL - fault extent map |
| 业务 JDBC 会话 | enq: XL - fault extent map / read by other session |
enq: XL - fault extent map 多次集中出现在 BDP_ITF_ACCESSLOG 相关操作中，说明数据库在访问或维护该表 extent map 时发生了异常等待，且已影响到后台进程、Data Pump 和业务连接。
六、RAC 节点对比验证（关键）
6.1 仅运行 2 节点
关闭 fspdb1，仅保留 fspdb2 运行，在 2 节点上：
创建新表空间：
CREATE TABLESPACE DMS_DATA_NEW
DATAFILE '+DATA' SIZE 1G AUTOEXTEND ON;
-- Tablespace created. ✓
导出问题表：
expdp '/ as sysdba' tables=FDP.BDP_ITF_ACCESSLOG \
directory=dump_dir dumpfile=BDP_ITF_ACCESSLOG.dmp \
logfile=BDP_ITF_ACCESSLOG.log cluster=n
exported "FDP"."BDP_ITF_ACCESSLOG" 10.90 GB 48,906,479 rows
Job successfully completed elapsed 0:03:01 ✓
6.2 反向验证：仅运行 1 节点
关闭 fspdb2，仅启动 fspdb1，对同一张表执行 expdp：
State: EXECUTING
Bytes Processed: 0
Completed Rows: 48,648,127（卡住）
会话中可见：
- DW00 等待
enq: XL - fault extent map - 业务 JDBC 会话等待
enq: XL - fault extent map - 业务 JDBC 会话等待
read by other session
6.3 节点对比结论
| 操作 | 2 节点（cspserver2） | 1 节点（cspserver1） |
|---|---|---|
| 创建表空间 | ✓ 成功 | — |
| 导出问题表 | ✓ 3 分钟完成 | ✗ 卡住 |
| ASM 访问 | 正常 | 异常 |
| 监听注册 | 正常 | 异常 |
结论：故障不在表本身，不在整个 ASM DATA 磁盘组，而在 cspserver1 / fspdb1 的节点访问链路。
七、OS 与 ASM 层证据
dmesg 记录（1 节点）：
INFO: task oracle:4977 blocked for more than 120 seconds.
对应进程：grid 4977 asm_vmb0_+ASM1，调用栈涉及 oracleadvm → AsmIoctl → blkdev_ioctl。
ASM 日志：
ASM client fspdb1:fspdb disconnected unexpectedly
System State dumped
Errors in ASM trace
1 节点 ASM/ADVM/OS I/O 调用链路存在明确异常。
八、监听异常
重启 1 节点主机后，监听出现异常：
ora.LISTENER.lsnr ONLINE INTERMEDIATE cspserver1 Not All Endpoints Registered
ora.LISTENER_SCAN1.lsnr ONLINE INTERMEDIATE cspserver1 Not All Endpoints Registered
本地监听仅有 IPC endpoint，缺少 TCP endpoint，无任何服务注册，导致应用报错：
ORA-12514: TNS:listener does not currently know of service requested
ORA-12516: TNS:listener could not find available handler
监听异常说明，问题已从数据库内部等待蔓延至节点网络与服务注册层。
九、应急处理
9.1 排除问题表，先备份其他对象
通过传统 exp 导出时排除 FDP.BDP_ITF_ACCESSLOG，确保核心业务数据安全。
成功备份用户：FSP、FSP2、FSP22、FSP3、FSP33、FSP35
Export terminated successfully without warnings. ✓
9.2 用 2 节点完成问题表导出
仅保留 cspserver2 运行后，expdp 成功：
10.90 GB，48,906,479 行，用时 3 分钟 ✓
9.3 隔离 1 节点，业务切换到 2 节点
- 停止 fspdb1，业务连接全部切到 fspdb2
- 重置应用 JDBC 连接池
- 验证 inst_id = 2 的会话占比
十、根因确认
最终处置： 关闭节点一，将 cspserver1 对应虚拟机迁移至其他宿主机。迁移后数据库访问恢复正常，业务稳定。
根因定论：
本次故障为虚拟化宿主机层面异常，导致 Oracle RAC 单节点（cspserver1）访问 ASM 存储、处理 extent map、执行 Data Pump 导出及监听服务注册时均表现异常。cspserver2 全程运行正常。迁移虚拟机后故障消失，确认问题位于原宿主机或其存储/网络链路层，数据库对象本身未损坏。
十一、故障链路
业务程序频繁卡住
↓
数据库会话出现 enq: XL - fault extent map / read by other session
↓
问题集中在 FDP.BDP_ITF_ACCESSLOG（file#8）
↓
RMAN 备份 datafile 8 卡住 / EXP/EXPDP 导出异常
↓
RAC 节点对比：2 节点正常，1 节点复现异常
↓
1 节点 ASM/ADVM/监听均出现异常迹象
↓
怀疑虚拟化宿主机或链路问题
↓
关闭节点一，迁移虚拟机至其他宿主机
↓
数据库恢复正常
十二、经验教训
12.1 RAC 故障必须做节点对比验证
同一对象、同一磁盘组、同一操作，2 节点正常、1 节点异常，这种对比能快速排除以下误判：SQL 问题、表损坏、ASM 整体故障、备份命令问题、目录空间不足。
12.2 业务卡顿与备份失败往往同根
本次表面上有多个独立问题（业务卡顿、RMAN 失败、EXPDP 异常、监听异常），实际均指向同一底层原因——节点访问链路异常。排查时要将等待事件、ASM 日志、OS 日志、RAC 节点状态、应用连接行为串联分析，而不是逐一孤立处理。
12.3 虚拟化环境要关注宿主机层
Oracle RAC 运行在虚拟化平台上时，出现单节点异常，除数据库和 ASM 之外，还需重点排查：
- 虚拟化宿主机状态及平台日志（VMware/其他）
- 虚拟磁盘链路（PVSCSI 控制器、共享存储路径、多路径）
- 宿主机网络与虚拟交换机
- 物理网卡状态
本次通过迁移虚拟机恢复，说明宿主机层面排查不可忽视。
12.4 大日志表需要主动治理
FDP.BDP_ITF_ACCESSLOG 数据量达数千万行，含 CLOB 字段，长期不归档将带来：备份时间过长、导出困难、热点写入、故障时排查成本高、恢复窗口被拉长。
建议措施：
- 按
CALL_TIME做范围分区 - 定期归档历史数据，拆分冷热数据
- 控制 CLOB 字段大小
- 对日志表单独制定备份策略
- 定期清理过期数据
十三、后续优化建议
13.1 连接串规范化
应用不应写死单节点 IP，应使用 SCAN 连接串，结合 service 策略控制连接落点。
检查项：JDBC URL 是否写死 cspserver1 IP；是否使用 SCAN；service 是否正确注册；remote_listener 是否配置；连接池是否支持故障转移。
13.2 监听和服务注册巡检
纳入日常巡检的命令：
srvctl status scan srvctl status scan_listener srvctl status database -d fspdb lsnrctl services LISTENER lsnrctl services LISTENER_SCAN1
重点关注：LISTENER 是否 ONLINE；是否出现 INTERMEDIATE；是否存在 TCP endpoint；数据库 service 是否 READY。
13.3 节点健康检查
dmesg | egrep -i "blocked for more than|I/O error|timeout|reset|oracleadvm|asm"
vmstat 1 10
iostat -x 1 10
重点关注 blocked task、ASM/ADVM 调用栈、I/O timeout、磁盘 await 异常、节点间表现不一致。
13.4 备份策略多元化
单一备份方式存在风险，建议组合使用：
- RMAN 全库备份 + RMAN validate
- 关键业务表 expdp 逻辑备份
- 归档日志备份
- 定期恢复演练
- 大表单独备份策略，尤其是含 CLOB 的日志表
附：为什么排除"表损坏"和"ASM 整体故障"
排除表损坏： 2 节点完整导出了 48,906,479 行、10.90 GB 数据，且迁移宿主机后恢复正常。表是触发异常的热点，不是根因。
排除 ASM 整体故障： 若 +DATA 磁盘组整体故障，两节点均应异常。但 2 节点可正常创建表空间、完整导出问题表、业务访问相对正常，说明共享存储本身可用，异常来自某一节点的访问链路。
