Every Day of a DBA，第172期: OFFLINE DROP 紧急救援

一、故障概述

ITMS 数据库（Oracle）服务无法正常启动。执行 startup 后，实例成功启动、数据库完成 MOUNT，但 OPEN 阶段失败，报出 ORA-01115、ORA-27070、OSD-04016 及 O/S-Error（OS 23）循环冗余检查等介质相关错误。结合 Windows 事件日志中 disk 源事件 ID 7（“有不正确的区块”）在时间与盘符上的相互印证，判断故障根因为数据文件所在磁盘存在物理坏扇区（介质层损坏），而非数据库或文件系统逻辑损坏。

经 chkdsk E: /f /r 对文件系统进行修复后，因损坏发生在数据文件内部数据块，文件系统层无法自愈。最终在归档模式下，对 4 个损坏数据文件执行 ALTER DATABASE DATAFILE ... OFFLINE DROP 后，数据库成功 OPEN，实例恢复对外服务。目前仅这 4 个已 OFFLINE DROP 的数据文件（15、17、20、35）内所存放的数据不可用，同一表空间下其余完好数据文件中的对象仍可正常访问；需尽快通过备份恢复或重建方式补齐这 4 个数据文件，并同步更换故障磁盘，规避再次故障风险。

二、环境信息

三、故障现象与初步诊断

（一）startup 现象

执行 startup 后，实例正常启动、数据库完成 MOUNT，但 OPEN 阶段失败，具体输出如下：

SQL> startup
ORACLE instance started.
Total System Global Area  2.7191E+10 bytes
Database mounted.
ORA-01110: data file 15: 'E:\APP\ADMINISTRATOR\ORADATA\ITMS\CROSS_RECORDLIST_T_07.DBF'
ORA-01115: IO error reading block from file 15 (block # 1)
ORA-27070: async read/write failed
OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 23) 数据错误(循环冗余检查)。

（二）关键报错分析

ORA-01115 表明从数据文件 15 读取块失败，ORA-01110 定位到具体文件为 CROSS_RECORDLIST_T_07.DBF，且失败块号为 1（即数据文件头块）。ORA-27070 与 OSD-04016 说明底层异步 I/O 请求排队失败，而最底层的 O/S-Error（OS 23）"数据错误（循环冗余检查）"表明操作系统在读取物理扇区时发生循环冗余校验（CRC）失败。CRC 错误是磁盘物理坏道、介质损坏的典型特征，通常与数据库逻辑无关。

（三）磁盘层印证（Windows 事件）

同期 Windows 事件日志中报出如下事件，指向同一物理磁盘存在坏块：

事件 ID 7 disk：设备 \Device\Harddisk0\DR0 有一个不正确的区块

事件 ID 7（源为 disk，“有不正确的区块”）是 Windows 存储栈在设备级报告的坏块事件，与 Oracle 报错在时间与盘符上吻合，两者相互印证：故障位于磁盘介质层，而非 Oracle 或文件系统逻辑层。

（四）诊断结论

故障根因判定为：E 盘所在物理磁盘（Harddisk0\DR0）存在坏扇区，CROSS_RECORDLIST_T_07.DBF 等数据文件所在区域介质损坏，导致 Oracle 读取数据文件头块失败。

四、处置过程

（一）阶段一：文件系统修复（chkdsk E: /f /r）

因卷正被其他进程使用，chkdsk 提示强制卸除卷后执行。检查与修复过程及关键结果如下：

C:\Users\Administrator>chkdsk E: /f /r
文件系统的类型是 NTFS。
...
阶段 1: 检查基本文件系统结构...  已处理 66816 个文件记录。
阶段 2: 检查文件名链接...  已处理 74776 个索引项。
阶段 3: 检查安全描述符...  已处理 3980 个数据文件。
阶段 4: 在用户文件数据中查找损坏的群集...
Windows 替换了名为 \app\ADMINI~1\oradata\itms\CR07DF~1.DBF 的 45269 文件中的不正确
Windows 替换了名为 \app\ADMINI~1\oradata\itms\CR31AB~1.DBF 的 45271 文件中的不正确
Windows 替换了名为 \app\ADMINI~1\oradata\itms\CRBD93~1.DBF 的 45274 文件中的不正确
Windows 替换了名为 \app\ADMINI~1\oradata\itms\CROSS_03.DBF 的 53911 文件中的不正确
Windows 替换了名为 \app\ADMINI~1\oradata\itms\CROSS_04.DBF 的 54903 文件中的不正确
阶段 5: 查找损坏的空闲群集...  已处理 32500853 个可用簇。
将 13 个不正确的群集添加到了不正确的群集文件。正在更正卷位图的错误。
Windows 已更正文件系统。无需采取进一步操作。
坏扇区         52 KB。
磁盘上共 211738367 个分配单元，32500853 个可用的分配单元。

chkdsk 检测到坏扇区（52 KB），并将 5 个数据文件（CR07DF~1、CR31AB~1、CRBD93~1、CROSS_03、CROSS_04）中的不正确簇替换标记。需要说明的是，chkdsk 仅将坏簇在文件系统中标记或替换，无法修复已损坏的数据块内容，因此数据文件内部的介质损坏仍会持续。

（二）阶段二：再次 OPEN 失败，报错升级

文件系统修复后再次执行 OPEN，数据文件 15 验证检查仍失败，报错如下：

ORA-01122: database file 15 failed verification check
ORA-01110: data file 15: 'E:\APP\ADMINISTRATOR\ORADATA\ITMS\CROSS_RECORDLIST_T_07.DBF'
ORA-01210: data file header is media corrupt
ORA-1122 signalled during: alter database open...
Checker run found 4 new persistent data failures

告警日志中同时出现内部异常：

Mon Oct 05 13:32:42 2026
ALTER DATABASE OPEN
Exception [type: IN_PAGE_ERROR, ] [] [PC:0x63EE8875, 0000000063EE8875]
ORA-07445: exception encountered: core dump [PC:0x63EE8875] [IN_PAGE_ERROR]

分析：ORA-01210 明确数据文件头（block 1）为介质损坏（media corrupt），OPEN 校验无法通过；Checker 检测到 4 个数据文件存在持久性损坏；OPEN 期间触发 ORA-07445（IN_PAGE_ERROR）内部异常导致核心转储。此时文件系统修复已不足以解决 Oracle 数据块损坏问题。

（三）阶段三：归档模式应急恢复（OFFLINE DROP）

数据库处于归档模式，可在 MOUNT 状态下将损坏的数据文件置为 OFFLINE DROP，跳过损坏文件以完成 OPEN，保障数据库先恢复对外服务。执行命令如下：

SQL> ALTER DATABASE DATAFILE 15 OFFLINE DROP;
SQL> ALTER DATABASE DATAFILE 17 OFFLINE DROP;
SQL> ALTER DATABASE DATAFILE 20 OFFLINE DROP;
SQL> ALTER DATABASE DATAFILE 35 OFFLINE DROP;
SQL> ALTER DATABASE OPEN;

（四）阶段四：OPEN 成功确认

OPEN 成功后，实例自动执行崩溃恢复（crash recovery），相关告警日志如下：

ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
 read 6417 KB redo, 970 data blocks need recovery
Started redo application at Thread 1: logseq 155485, block 51473
Completed redo application of 3.22MB
Completed crash recovery at Thread 1: logseq 155486, block 12806, scn 3779672087
970 data blocks read, 970 data blocks written, 6417 redo k-bytes read
Thread 1 advanced to log sequence 155487 (thread open)
Thread 1 opened at log sequence 155487
Successful open of redo thread 1
Completed: ALTER DATABASE OPEN

崩溃恢复完成（单线程，970 个数据块恢复，日志序列由 155485 推进至 155487），数据库成功打开。

五、结果确认

数据库已成功 OPEN，实例状态确认为 OPEN：

SQL> select status from v$instance;
STATUS
------
OPEN

当前结果：数据库恢复对外服务；崩溃恢复正常完成；实例日志序列推进至 155487。仅 4 个 OFFLINE DROP 数据文件（15、17、20、35）内的数据暂不可用，同一表空间下其他完好数据文件不受影响。

六、遗留风险与后续处理建议

（一）已 OFFLINE DROP 数据文件恢复（最高优先）

数据文件 15（CROSS_RECORDLIST_T_07.DBF）以及 17、20、35 已通过 OFFLINE DROP 标记为永久脱机。需要说明的是，OFFLINE DROP 仅影响被操作的数据文件本身，不会使整个表空间不可用：只有存放在这 4 个数据文件中的段（表、索引等）在访问时才会报错，同一表空间下其余完好数据文件内的对象仍可正常查询与读写。这 4 个数据文件的恢复属于最优先处理事项。

1. 先通过视图确认这 4 个文件对应的文件名与表空间（用户现场日志未提供 17、20、35 的物理文件名，需以下列查询确认）：

SELECT file#, name, status, tablespace_name
  FROM v$datafile
 WHERE file# IN (15, 17, 20, 35);

2. 恢复方案（二选一或组合）：

（1）若数据库存在有效的 RMAN 备份（含所需归档日志），可对相关数据文件执行 RESTORE 加 RECOVER，将其恢复到一致性状态后再 ONLINE。

（2）若无有效备份，需评估丢失该表空间数据的影响：若属可重建表（如明细/历史数据），可 DROP 对应表空间（含 OFFLINE DROP 的数据文件）后重建并重新加载数据；否则相关数据将无法找回，需与业务侧确认影响范围与补救方案。

3. 恢复期间数据库保持归档模式，确保在线日志与归档日志链完整，为后续恢复提供前提。

（二）数据完整性核查

对已成功 OPEN 的其余数据文件，建议通过 DBMS_REDEFINITION、ANALYZE 或业务侧数据校验核对数据完整性；对疑似坏块可用 DBMS_REPAIR 定位（注意其会跳过坏块，需评估对数据一致性的影响）。若磁盘继续出现坏道，需及时用事件日志与告警日志复核。

（三）硬件层面处置

当前已检测到 52 KB 坏扇区，物理磁盘（Harddisk0\DR0）已出现坏道，后续风险持续存在。建议：

1. 尽快将 E 盘数据备份并迁移至健康磁盘，减少在坏区上的读写；
2. 更换故障物理磁盘，更换后使用 chkdsk 或磁盘厂商工具执行全盘扫描与坏块重映射；
3. 更换完成并验证数据可读后再切换回新盘运行。

（四）备份与恢复策略（长期）

1. 建立并定期验证 RMAN 全量备份加归档日志备份策略，定期执行 RESTORE VALIDATE / RESTORE PREVIEW 演练；
2. 合理配置快速恢复区（当前 db_recovery_file_dest_size 为 307200 MB，约 300 GB，使用率约 3.05%）；
3. 对重要数据文件启用块级校验（DB_BLOCK_CHECKSUM），以便早期发现介质损坏；
4. 对关键表空间数据文件建立定期巡检（查 V$DATAFILE_HEADER 状态、事件日志坏块记录等）。

七、总结

本次故障为物理磁盘介质坏块导致的数据文件损坏。完整处置路径为：诊断（Oracle 报错与 Windows 事件互证，判定介质层故障）→ 文件系统修复（chkdsk，无法修复 Oracle 数据块）→ 归档模式下对 4 个损坏数据文件执行 OFFLINE DROP 完成应急 OPEN → 后续数据文件恢复与故障磁盘更换。

当前数据库已 OPEN 并恢复对外服务，但 4 个已 OFFLINE DROP 数据文件的恢复、数据完整性核查与故障磁盘更换仍需尽快完成，以彻底消除隐患。

附录 A：关键错误码速查表