2026-10-04 · 约 6 分钟
ORA-01578（数据块损坏）、ORA-01113（文件需要介质恢复）、ORA-01122（数据文件校验失败）、ORA-600/ORA-7445（内部错误）。根因多为存储掉电写坏块、磁盘坏道、误删数据文件/表空间、控制文件丢失、REDO 日志损坏。
立即停止业务写入；对控制文件、数据文件、在线 REDO、归档日志、参数文件做只读副本；不要对运行中的实例直接拷数据文件，不要清空回收站或切换日志覆盖。先 DBVERIFY 定位损坏对象，再决定恢复路径。
第一层 Flashback Table：对象仍在回收站（recyclebin）时，FLASHBACK TABLE ... TO BEFORE DROP 秒级找回；第二层 Flashback Query：依赖 UNDO 表空间，AS OF TIMESTAMP 回看历史版本；第三层 LogMiner：解析 REDO/归档日志，重建 DELETE/UPDATE 前镜像，适合 UNDO 已被覆盖的场景。
优先 RMAN blockrecover 做单块恢复（影响面最小）；无备份时用 DUL/ODU/PRM 等第三方工具直接解析数据文件抽取表数据；控制文件损坏先重建控制文件再挂载。整个过程在离线副本上操作，避免二次覆盖。
多数可以。块损坏通常只影响部分对象，先固证再用 Flashback/RMAN blockrecover 或 DUL 工具分级恢复，核心表恢复率较高。切勿反复强制启动试错，避免二次损坏。
能。对象在回收站走 Flashback Table；UNDO 未覆盖走 Flashback Query；UNDO 已覆盖但归档日志完整，可用 LogMiner 解析重建。前提是停止写入、保留归档日志。
视损坏范围：单表 Flashback 分钟级；RMAN 单块恢复小时级；全库工具解析通常 1-3 个工作日。到店免费检测，出具报告后报价。
控制文件、数据文件、REDO/归档日志、参数文件（spfile/pfile）的只读副本；如已在本地做过操作，请一并说明操作顺序，便于判断覆盖风险。
Oracle 起不来时，报错码会指向不同层次：控制文件、数据文件、redo、undo。 处置顺序错了，最坏的结果是把还能恢复的库做成必须做不完全恢复。
| 项目 | 取值 / 位置 | 说明 |
|---|---|---|
| 数据块大小 | 常见 8KB（db_block_size，建库时确定，不可改） | 块头含缓存头与事务槽信息 |
| SCN | 系统变更号，贯穿数据块、redo、控制文件 | 不一致时数据库会拒绝打开 |
| 控制文件 | 记录数据文件与 redo 的位置、SCN | 控制文件损坏时可用备份或重建 |
| Redo 日志 | 在线/归档，记录变更 | 实例恢复与介质恢复都依赖它 |
| Undo | 回滚段，支撑一致性读与回滚 | undo 丢失会导致无法回滚未提交事务 |
# 1) 先看告警日志，确认是哪一层出错（不要急着 startup force）
tail -100 $ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log
# 2) 只读检查数据文件块完整性
dbv file=/u01/oradata/ORCL/system01.dbf blocksize=8192
# 3) 有备份时优先用 RMAN 做恢复演练（在副本上）
rman target /
RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;实务顺序：先备份整个 $ORACLE_BASE（含控制文件、redo、归档、参数文件），再动手。 常见错误是直接 `startup force` 反复重启——每次重启都可能推进 SCN、改写控制文件， 把原本可以只做介质恢复的场景，变成必须做不完全恢复（丢数据）。
参数判定、镜像方案、固件损坏这类问题，聊清楚不收钱；需要现场检测、书面报价或上门，统一走 项目1 服务页（到店免费检测，出报告后报价，不出结果不收费）。
18620311365
深圳市福田区深南中路2070号电子科技大厦A座35楼D22（华强北地铁站D1口步行320米）