本文收录于 《全栈 Bug 调优实战版》 专栏。专栏聚焦真实项目中的各类疑难 Bug从成因剖析 → 排查路径 → 解决方案 → 预防优化全链路拆解形成一套可复用、可沉淀的实战知识体系。无论你是初入职场的开发者还是负责复杂项目的资深工程师都可以在这里构建一套属于自己的「问题诊断与性能调优」方法论助你稳步进阶、放大技术价值。特别说明文中问题案例来源于真实生产环境与公开技术社区并结合多位一线资深工程师与架构师的长期实践经验经过人工筛选与AI系统化智能整理后输出。文中的解决方案并非唯一“标准答案”而是兼顾可行性、可复现性与思路启发性的实践参考供你在实际项目中灵活运用与演进。欢迎订阅本专栏一次订阅后专栏内所有文章可永久免费阅读后续更新内容皆不用再次订阅持续更新中。 问题描述详细问题描述如下Oracle插入数据时卡住一直执行不保存显示正在读取控制文件查询视图没有锁表空间没有满其他用户有一个表空间文件损坏状态。如何解决全文目录 问题描述 请知悉如下方案不保证一定适配你的问题✅️问题理解✅️问题解决方案方案 A先做“证据闭环定位”——确认到底是不是受损数据文件 / 控制文件 I/O 导致方案 B确认有损坏文件后立即做“隔离 恢复”——这是最稳妥的生产修复路径方案 C如果是“局部坏块”而不是整个文件坏掉走块级恢复或对象级绕行方案 D如果最后确认不是受损文件直接命中业务对象那就转查“控制文件 / 存储 I/O / 同盘拖死”✅️问题延伸✅️问题预测✅️小结 结语 互动说明 文末福利技术成长加速包 Who am I? 请知悉如下方案不保证一定适配你的问题如下是针对上述问题进行专业角度剖析答疑不喜勿喷仅供参考✅️问题理解这个现象我先给你一个偏结论型判断大概率不是“锁”问题而是“介质 / 数据文件 / 控制文件 I/O / 恢复状态”这一类问题。你说“查询视图没有锁、表空间没有满、插入一直执行不保存、界面还显示正在读取控制文件”这类组合症状和典型的行锁/表锁阻塞并不一致更像是会话卡在control file / datafile 相关等待事件上或者某个数据文件已经异常导致 Oracle 在做文件头校验、控制文件信息读写、恢复检查、段扩展、索引维护、UNDO 访问时被底层 I/O 拖住了。Oracle 官方文档里明确区分了这类等待control file sequential read是“读取控制文件”control file single write是“以 CF enqueue 保护的控制文件原子写入”control file parallel write则是“向所有控制文件写物理块”并会发生在控制文件事务启动、提交等场景。你提到“其他用户有一个表空间文件损坏状态”这个信息非常关键。Oracle 官方说明是如果损坏的是非 SYSTEM、且不包含活动 UNDO 的数据文件数据库可以保持 open只把受影响文件/表空间脱机但如果是 SYSTEM 或活动 UNDO 相关文件数据库通常会直接受重创甚至关闭。所以“库还开着、不见锁、但 DML 卡住”非常符合“某个非 SYSTEM 文件坏了但你的 insert 在执行过程中间接碰到了这个坏文件/坏存储”的场景。这个“碰到”不一定是表本体也可能是索引、LOB、分区、用户默认表空间、UNDO、段扩展、对象元数据、文件头检查甚至是同一块存储上的控制文件 I/O 被拖慢——这里我明确说明后半句是基于 Oracle 工作机制和现场经验做的推断不是你现有描述下 100% 已证实的事实。另外“没有锁”不等于“没有阻塞”。Oracle 的大量“卡住”并不是锁等待而是I/O wait、recovery wait、control file wait、file header read/write。你现在最需要的不是继续盯锁视图而是先把当前卡住会话的 wait event、对应文件号、目标对象、告警日志串起来。Oracle 也提供了专门视图V$RECOVER_FILE用来显示需要介质恢复的文件V$DATAFILE_HEADER能看出数据文件头是否可读、是否需要 recovery、是否 fuzzyV$DATABASE_BLOCK_CORRUPTION用来定位已发现的坏块。下面这张流程图就是我对你这个问题的故障链理解 ✅️问题解决方案方案 A先做“证据闭环定位”——确认到底是不是受损数据文件 / 控制文件 I/O 导致这是我最推荐你先做的方案原因很简单现在不要先修库先把“卡住会话 → 等待事件 → 对应文件 → 是否损坏 → 是否与 insert 目标对象相关”这条链闭合。否则很容易误把“控制文件读取”当成根因而实际上真正根因是底层坏盘、坏 datafile、索引所在文件损坏、或 alert log 中已经报过 ORA-01157 / ORA-01110 / block corruption。第 1 步抓住当前卡住会话到底在等什么selectsid,serial#,username,status,state,event,wait_class,seconds_in_wait,p1,p2,p3,sql_id,blocking_session,module,programfromv$sessionwhereusernameisnotnullandstatusACTIVEorderbyseconds_in_waitdesc;你重点看这些 eventcontrol file sequential readcontrol file single writecontrol file parallel writedb file sequential readdb file single writelog file syncenq: CF - contentionbuffer busy waitsread by other session如果真的是控制文件相关等待Oracle 文档已经说明了这些 wait 的含义control file sequential read就是读控制文件control file single write是受 CF enqueue 保护的控制文件共享信息写入control file parallel write是向所有控制文件写物理块可能发生在控制文件事务启动、提交时。第 2 步看数据库是否已经认定某些文件需要恢复selectrf.file#,df.name,ts.nameastablespace_name,rf.online_status,rf.errorfromv$recover_file rfjoinv$datafile dfondf.file# rf.file#joinv$tablespacetsonts.ts# df.ts#orderbyrf.file#;V$RECOVER_FILE本身就是 Oracle 用来显示“哪些文件需要 media recovery”的视图。第 3 步直接看文件头能不能读、是否 fuzzy、是否需要恢复selectfile#,name,status,error,recover,fuzzy,checkpoint_change#fromv$datafile_headerorderbyfile#;这里如果ERROR非空、RECOVERYES、或者文件头列大面积为空问题就已经非常实锤了。Oracle 文档明确写了如果数据文件头读取失败后续列会是 NULL如果校验失败其余列可能无效出现错误时通常要先从备份 restore 再 recover。第 4 步查是否已有坏块记录selectfile#,block#,blocks,corruption_change#fromv$database_block_corruptionorderbyfile#, block#;V$DATABASE_BLOCK_CORRUPTION就是 Oracle 用来记录已发现坏块的视图。第 5 步把 insert 目标对象和损坏文件关联起来这一步非常重要很多人会漏掉。你要确认坏掉的文件是不是正好承载了你要插入的表、索引、LOB、分区。先找表和索引在哪个表空间selectowner,segment_name,segment_type,tablespace_namefromdba_segmentswhereownerupper(:owner)and(segment_nameupper(:table_name)orsegment_namein(selectindex_namefromdba_indexeswheretable_ownerupper(:owner)andtable_nameupper(:table_name)))orderbysegment_type,segment_name;再看这些对象落在哪些 datafileselecte.owner,e.segment_name,e.segment_type,e.tablespace_name,e.file_id,df.file_namefromdba_extents ejoindba_data_files dfondf.file_ide.file_idwheree.ownerupper(:owner)and(e.segment_nameupper(:table_name)ore.segment_namein(selectindex_namefromdba_indexeswheretable_ownerupper(:owner)andtable_nameupper(:table_name)))groupbye.owner,e.segment_name,e.segment_type,e.tablespace_name,e.file_id,df.file_nameorderbye.segment_name,e.file_id;如果目标表或其索引命中了“损坏状态”的 datafile那基本就定性了insert 不是没执行而是在写入/索引维护/块访问过程中卡在坏文件或坏存储上。第 6 步同时查 alert logselectoriginating_timestamp,message_textfromv$diag_alert_extwhereoriginating_timestampsystimestamp-interval30minuteand(message_textlikeORA-%orlower(message_text)like%datafile%orlower(message_text)like%control file%orlower(message_text)like%corrupt%orlower(message_text)like%recovery%)orderbyoriginating_timestampdesc;如果现场出现ORA-01157、ORA-01110、I/O error、corrupt block、file header read error这个问题就不是“SQL 执行慢”而是“数据库文件已异常”。Oracle 对ORA-01157的官方定义就是后台进程无法识别/锁定某个数据文件数据库会禁止访问这个文件但其他文件可能不受影响动作是让操作系统把文件恢复可访问然后ALTER SYSTEM CHECK DATAFILES或重新 open。这一方案的结论目标只有一个把问题从“感觉像控制文件问题”收敛为真的是control file*wait还是db file*wait 被客户端误显示为“读取控制文件”受损文件是否与目标对象直接相关是单文件损坏还是同一存储路径导致控制文件和数据文件一起慢。方案 B确认有损坏文件后立即做“隔离 恢复”——这是最稳妥的生产修复路径如果你通过V$RECOVER_FILE / V$DATAFILE_HEADER / alert log已经确认某个 datafile 有问题那就不要再让业务硬顶着跑了。生产上正确动作是先隔离故障文件所属表空间再用 RMAN restore/recover。Oracle 官方说明很明确做tablespace recovery时数据库可以 open但表空间必须 offline做datafile recovery时数据库也可以保持 open但损坏文件必须 offline除非它属于 SYSTEM 表空间。标准做法1先把受影响表空间下线altertablespaceYOUR_TS offline immediate;如果是明确的 datafile也可以针对文件处理但大多数现场我建议先按表空间隔离业务语义更清晰。2RMAN 恢复run { sql alter tablespace YOUR_TS offline immediate; restore tablespace YOUR_TS; recover tablespace YOUR_TS; sql alter tablespace YOUR_TS online; }如果你是按 datafile 恢复run { sql alter database datafile 12 offline; restore datafile 12; recover datafile 12; sql alter database datafile 12 online; }3恢复后再验证select*fromv$recover_file;selectfile#, name, error, recover, fuzzy from v$datafile_header order by file#;select*fromv$database_block_corruption;如果恢复后这些视图都干净再重新做 insert 验证。这个方案适用的前提你有 RMAN 备份受损文件不是 SYSTEM / 当前活动 UNDO 的关键文件你允许短时间隔离部分业务对象。这个方案为什么最靠谱因为你现在的根因明显已经偏“存储/文件/恢复”方向了。继续让 session 卡着只会把应用侧线程、连接池、事务、重试逻辑、甚至更多会话一起拖死。方案 C如果是“局部坏块”而不是整个文件坏掉走块级恢复或对象级绕行有些现场并不是整个 datafile 挂了而是某几个 block 坏了。这种情况下不一定非要整文件 restore/recover。Oracle 提供两类工具RMAN block recoveryOracle 文档说明RMAN 可以用RECOVER CORRUPTION LIST修复V$DATABASE_BLOCK_CORRUPTION里列出的坏块。DBMS_REPAIROracle 文档说明DBMS_REPAIR可用于检测并处理表/索引中的损坏块在修复或重建过程中还能尽量让对象继续可用。适合块级恢复的场景V$DATABASE_BLOCK_CORRUPTION里只有少数块目标对象清晰你不想整表空间下线太久有可靠备份链。RMAN 示例recover corruption list;或者指定块blockrecover datafile 12 block 34567;对象级绕行思路如果坏的是索引块优先考虑drop / rebuild index如果坏的是某个可迁移对象考虑CTAS 导出可读数据、重建表如果坏的是 LOB / 分区按分区或对象做局部切换如果坏块只影响少数脏数据且业务允许可临时绕过坏对象、先保核心链路。这个方案的优点是业务影响更小缺点是你必须非常确定损坏范围不然容易“修了表面、没修根因”。方案 D如果最后确认不是受损文件直接命中业务对象那就转查“控制文件 / 存储 I/O / 同盘拖死”这个方案是很多人容易忽略的即使坏文件和你的表不是同一个表空间也可能因为控制文件、数据文件、redo、ASM 磁盘组、LUN、挂载点在同一存储链路上导致 insert 看起来卡在“读取控制文件”。这是因为 Oracle 的控制文件读取/写入本身就可能发生而且控制文件共享信息写入还受 CF enqueue 串行保护一旦底层 I/O 很慢很多会话都可能被串着拖住。Oracle 官方对control file single write和control file parallel write的定义已经把这种串行/物理写入特征说得很清楚了。你要补查这些点1控制文件位置是否和故障 datafile 在同一盘组 / 同一路径selectnamefromv$controlfile;selectfile#, name from v$datafile order by file#;2OS / 存储层是否已有异常Linuxiostat -x 1multipathmultipath -llASM查磁盘组告警、rebalance、offline disk存储侧看 LUN latency、路径 flap、阵列告警3是否出现 file header / checkpoint / control file 相关告警alert logASM alertOS kernel log存储监控4控制文件是否做了多路复用且落在不同物理盘Oracle 官方建议控制文件至少保留两份并放在不同物理磁盘上控制文件损坏会导致实例无法正常工作。如果这里查出来是控制文件和问题 datafile 共盘 / 同一故障存储路径那你真正要修的是存储和控制文件布局而不是业务 SQL。✅️问题延伸这个问题最值得延伸的点是很多 DBA/开发会误判成下面几类1误判为“应用没提交”其实不是没提交而是事务在数据库端卡在 wait 上。尤其客户端一直转圈时肉眼最容易以为“insert 已经执行完了只是没 commit”。2误判为“没有锁就没事”这是 Oracle 现场排障里非常常见的坑。锁只是阻塞的一类I/O wait、recovery wait、control file wait、file header 校验失败一样能把 DML 卡死。3误判为“其他用户的数据文件坏了和我无关”不一定。只要出现下面任一情况就可能有关你的表 / 索引 / LOB / 分区就在那个文件上坏文件对应的是共享对象或共用表空间同一存储路径上的控制文件也被拖慢目标会话在申请 extent、更新索引、访问 undo 时碰到了异常底层存储不是“单文件问题”而是“整块 LUN / diskgroup 问题”。4误判为“表空间没满所以不是存储问题”表空间没满只能排除“空间不足”排不了文件丢失文件头损坏坏块底层磁盘高延迟ASM/文件系统路径异常控制文件读写抖动所以这类问题的正确排障顺序不是“先看锁、再看表空间大小”而是会话等待 → 文件恢复状态 → 文件头 → 坏块 → alert log → 存储层✅️问题预测如果这个问题不尽快处理我会预测后续很可能出现这些现象1更多 DML 开始堆积insert 先卡后面 update / delete / commit 也会开始异常因为连接池线程被占住事务链路会越积越多。2alert log 开始连续报错尤其是ORA-01157ORA-01110block corruptionfile header read errorI/O error其中ORA-01157官方就明确是“后台进程无法识别/锁定数据文件”。3受影响表空间逐步不可用如果恢复不及时相关对象会从“偶发卡顿”发展成“稳定失败”。4如果底层是共享存储故障控制文件 / redo / 更多 datafile 会一起受影响这时就不是单对象问题而是实例层级稳定性问题了。5如果坏的是 SYSTEM / 活动 UNDO风险会陡然升级Oracle 文档明确说这种场景数据库可能直接 shutdown。✅️小结我给你的最终判断是这不是一个“普通 insert 慢”或“普通锁等待”的问题而是一个高概率和“损坏数据文件 / 坏块 / 恢复状态 / 控制文件或底层存储 I/O”相关的故障。✅最靠谱、最落地的处理顺序是先抓当前卡住会话的真实 wait event立刻查V$RECOVER_FILE、V$DATAFILE_HEADER、V$DATABASE_BLOCK_CORRUPTION把受损文件和目标表/索引/LOB/分区关联起来查 alert log确认是否已有 ORA-01157 / ORA-01110 / corruption确认后立即对受损表空间做 offline RMAN restore/recover若只是局部坏块优先考虑 block recover / DBMS_REPAIR / 索引重建若业务对象没直接命中坏文件则转查同存储上的控制文件与 I/O 链路。一句话压缩“显示正在读取控制文件”大概率只是表象真正根因多半在损坏文件或底层 I/O。” 结语 互动说明希望以上分析与解决思路能为你当前的问题提供一些有效线索或直接可用的操作路径。若你按文中步骤执行后仍未解决不必焦虑或抱怨这很常见——复杂问题往往由多重因素叠加引起欢迎你将最新报错信息、关键代码片段、环境说明等补充到评论区我会在力所能及的范围内结合大家的反馈一起帮你继续定位 如果你有更优或更通用的解法非常欢迎在评论区分享你的实践经验或改进方案你的这份补充可能正好帮到更多正在被类似问题困扰的同学正所谓「赠人玫瑰手有余香」也算是为技术社区持续注入正向循环 文末福利技术成长加速包 文中部分问题来自本人项目实践部分来自读者反馈与公开社区案例也有少量经由全网社区与智能问答平台整理而来。若你尝试后仍没完全解决问题还请多一点理解、少一点苛责——技术问题本就复杂多变没有任何人能给出对所有场景都 100% 套用的方案。如果你已经找到更适合自己项目现场的做法非常建议你沉淀成文档或教程这不仅是对他人的帮助更是对自己认知的再升级。如果你还在持续查 Bug、找方案可以顺便逛逛我专门整理的 Bug 专栏《全栈 Bug 调优实战版》️这里收录的都是在真实场景中踩过的坑希望能帮你少走弯路节省更多宝贵时间。✍️如果这篇文章对你有一点点帮助欢迎给 bug菌 来个一键三连关注 点赞 收藏你的支持是我持续输出高质量实战内容的最大动力。同时也欢迎关注我的硬核公众号 「猿圈奇妙屋」获取第一时间更新的技术干货、BAT 等互联网公司最新面试真题、4000G 技术 PDF 电子书、简历 / PPT 模板、技术文章 Markdown 模板等资料通通免费领取。你能想到的绝大部分学习资料我都尽量帮你准备齐全剩下的只需要你愿意迈出那一步来拿。 Who am I?我是 bug菌热活跃于 CSDN | 掘金 | InfoQ | 51CTO | 华为云 | 阿里云 | 腾讯云 等技术社区CSDN 博客之星 Top30、华为云多年度十佳博主/卓越贡献者、掘金多年度人气作者 Top40掘金、InfoQ、51CTO 等平台签约及优质作者全网粉丝累计30w。更多高质量技术内容及成长资料可查看这个合集入口 点击查看 ️硬核技术公众号「猿圈奇妙屋」期待你的加入一起进阶、一起打怪升级。- End -
Oracle插入数据时卡住，一直执行不保存，显示正在读取控制文件...如何解决？
本文收录于 《全栈 Bug 调优实战版》 专栏。专栏聚焦真实项目中的各类疑难 Bug从成因剖析 → 排查路径 → 解决方案 → 预防优化全链路拆解形成一套可复用、可沉淀的实战知识体系。无论你是初入职场的开发者还是负责复杂项目的资深工程师都可以在这里构建一套属于自己的「问题诊断与性能调优」方法论助你稳步进阶、放大技术价值。特别说明文中问题案例来源于真实生产环境与公开技术社区并结合多位一线资深工程师与架构师的长期实践经验经过人工筛选与AI系统化智能整理后输出。文中的解决方案并非唯一“标准答案”而是兼顾可行性、可复现性与思路启发性的实践参考供你在实际项目中灵活运用与演进。欢迎订阅本专栏一次订阅后专栏内所有文章可永久免费阅读后续更新内容皆不用再次订阅持续更新中。 问题描述详细问题描述如下Oracle插入数据时卡住一直执行不保存显示正在读取控制文件查询视图没有锁表空间没有满其他用户有一个表空间文件损坏状态。如何解决全文目录 问题描述 请知悉如下方案不保证一定适配你的问题✅️问题理解✅️问题解决方案方案 A先做“证据闭环定位”——确认到底是不是受损数据文件 / 控制文件 I/O 导致方案 B确认有损坏文件后立即做“隔离 恢复”——这是最稳妥的生产修复路径方案 C如果是“局部坏块”而不是整个文件坏掉走块级恢复或对象级绕行方案 D如果最后确认不是受损文件直接命中业务对象那就转查“控制文件 / 存储 I/O / 同盘拖死”✅️问题延伸✅️问题预测✅️小结 结语 互动说明 文末福利技术成长加速包 Who am I? 请知悉如下方案不保证一定适配你的问题如下是针对上述问题进行专业角度剖析答疑不喜勿喷仅供参考✅️问题理解这个现象我先给你一个偏结论型判断大概率不是“锁”问题而是“介质 / 数据文件 / 控制文件 I/O / 恢复状态”这一类问题。你说“查询视图没有锁、表空间没有满、插入一直执行不保存、界面还显示正在读取控制文件”这类组合症状和典型的行锁/表锁阻塞并不一致更像是会话卡在control file / datafile 相关等待事件上或者某个数据文件已经异常导致 Oracle 在做文件头校验、控制文件信息读写、恢复检查、段扩展、索引维护、UNDO 访问时被底层 I/O 拖住了。Oracle 官方文档里明确区分了这类等待control file sequential read是“读取控制文件”control file single write是“以 CF enqueue 保护的控制文件原子写入”control file parallel write则是“向所有控制文件写物理块”并会发生在控制文件事务启动、提交等场景。你提到“其他用户有一个表空间文件损坏状态”这个信息非常关键。Oracle 官方说明是如果损坏的是非 SYSTEM、且不包含活动 UNDO 的数据文件数据库可以保持 open只把受影响文件/表空间脱机但如果是 SYSTEM 或活动 UNDO 相关文件数据库通常会直接受重创甚至关闭。所以“库还开着、不见锁、但 DML 卡住”非常符合“某个非 SYSTEM 文件坏了但你的 insert 在执行过程中间接碰到了这个坏文件/坏存储”的场景。这个“碰到”不一定是表本体也可能是索引、LOB、分区、用户默认表空间、UNDO、段扩展、对象元数据、文件头检查甚至是同一块存储上的控制文件 I/O 被拖慢——这里我明确说明后半句是基于 Oracle 工作机制和现场经验做的推断不是你现有描述下 100% 已证实的事实。另外“没有锁”不等于“没有阻塞”。Oracle 的大量“卡住”并不是锁等待而是I/O wait、recovery wait、control file wait、file header read/write。你现在最需要的不是继续盯锁视图而是先把当前卡住会话的 wait event、对应文件号、目标对象、告警日志串起来。Oracle 也提供了专门视图V$RECOVER_FILE用来显示需要介质恢复的文件V$DATAFILE_HEADER能看出数据文件头是否可读、是否需要 recovery、是否 fuzzyV$DATABASE_BLOCK_CORRUPTION用来定位已发现的坏块。下面这张流程图就是我对你这个问题的故障链理解 ✅️问题解决方案方案 A先做“证据闭环定位”——确认到底是不是受损数据文件 / 控制文件 I/O 导致这是我最推荐你先做的方案原因很简单现在不要先修库先把“卡住会话 → 等待事件 → 对应文件 → 是否损坏 → 是否与 insert 目标对象相关”这条链闭合。否则很容易误把“控制文件读取”当成根因而实际上真正根因是底层坏盘、坏 datafile、索引所在文件损坏、或 alert log 中已经报过 ORA-01157 / ORA-01110 / block corruption。第 1 步抓住当前卡住会话到底在等什么selectsid,serial#,username,status,state,event,wait_class,seconds_in_wait,p1,p2,p3,sql_id,blocking_session,module,programfromv$sessionwhereusernameisnotnullandstatusACTIVEorderbyseconds_in_waitdesc;你重点看这些 eventcontrol file sequential readcontrol file single writecontrol file parallel writedb file sequential readdb file single writelog file syncenq: CF - contentionbuffer busy waitsread by other session如果真的是控制文件相关等待Oracle 文档已经说明了这些 wait 的含义control file sequential read就是读控制文件control file single write是受 CF enqueue 保护的控制文件共享信息写入control file parallel write是向所有控制文件写物理块可能发生在控制文件事务启动、提交时。第 2 步看数据库是否已经认定某些文件需要恢复selectrf.file#,df.name,ts.nameastablespace_name,rf.online_status,rf.errorfromv$recover_file rfjoinv$datafile dfondf.file# rf.file#joinv$tablespacetsonts.ts# df.ts#orderbyrf.file#;V$RECOVER_FILE本身就是 Oracle 用来显示“哪些文件需要 media recovery”的视图。第 3 步直接看文件头能不能读、是否 fuzzy、是否需要恢复selectfile#,name,status,error,recover,fuzzy,checkpoint_change#fromv$datafile_headerorderbyfile#;这里如果ERROR非空、RECOVERYES、或者文件头列大面积为空问题就已经非常实锤了。Oracle 文档明确写了如果数据文件头读取失败后续列会是 NULL如果校验失败其余列可能无效出现错误时通常要先从备份 restore 再 recover。第 4 步查是否已有坏块记录selectfile#,block#,blocks,corruption_change#fromv$database_block_corruptionorderbyfile#, block#;V$DATABASE_BLOCK_CORRUPTION就是 Oracle 用来记录已发现坏块的视图。第 5 步把 insert 目标对象和损坏文件关联起来这一步非常重要很多人会漏掉。你要确认坏掉的文件是不是正好承载了你要插入的表、索引、LOB、分区。先找表和索引在哪个表空间selectowner,segment_name,segment_type,tablespace_namefromdba_segmentswhereownerupper(:owner)and(segment_nameupper(:table_name)orsegment_namein(selectindex_namefromdba_indexeswheretable_ownerupper(:owner)andtable_nameupper(:table_name)))orderbysegment_type,segment_name;再看这些对象落在哪些 datafileselecte.owner,e.segment_name,e.segment_type,e.tablespace_name,e.file_id,df.file_namefromdba_extents ejoindba_data_files dfondf.file_ide.file_idwheree.ownerupper(:owner)and(e.segment_nameupper(:table_name)ore.segment_namein(selectindex_namefromdba_indexeswheretable_ownerupper(:owner)andtable_nameupper(:table_name)))groupbye.owner,e.segment_name,e.segment_type,e.tablespace_name,e.file_id,df.file_nameorderbye.segment_name,e.file_id;如果目标表或其索引命中了“损坏状态”的 datafile那基本就定性了insert 不是没执行而是在写入/索引维护/块访问过程中卡在坏文件或坏存储上。第 6 步同时查 alert logselectoriginating_timestamp,message_textfromv$diag_alert_extwhereoriginating_timestampsystimestamp-interval30minuteand(message_textlikeORA-%orlower(message_text)like%datafile%orlower(message_text)like%control file%orlower(message_text)like%corrupt%orlower(message_text)like%recovery%)orderbyoriginating_timestampdesc;如果现场出现ORA-01157、ORA-01110、I/O error、corrupt block、file header read error这个问题就不是“SQL 执行慢”而是“数据库文件已异常”。Oracle 对ORA-01157的官方定义就是后台进程无法识别/锁定某个数据文件数据库会禁止访问这个文件但其他文件可能不受影响动作是让操作系统把文件恢复可访问然后ALTER SYSTEM CHECK DATAFILES或重新 open。这一方案的结论目标只有一个把问题从“感觉像控制文件问题”收敛为真的是control file*wait还是db file*wait 被客户端误显示为“读取控制文件”受损文件是否与目标对象直接相关是单文件损坏还是同一存储路径导致控制文件和数据文件一起慢。方案 B确认有损坏文件后立即做“隔离 恢复”——这是最稳妥的生产修复路径如果你通过V$RECOVER_FILE / V$DATAFILE_HEADER / alert log已经确认某个 datafile 有问题那就不要再让业务硬顶着跑了。生产上正确动作是先隔离故障文件所属表空间再用 RMAN restore/recover。Oracle 官方说明很明确做tablespace recovery时数据库可以 open但表空间必须 offline做datafile recovery时数据库也可以保持 open但损坏文件必须 offline除非它属于 SYSTEM 表空间。标准做法1先把受影响表空间下线altertablespaceYOUR_TS offline immediate;如果是明确的 datafile也可以针对文件处理但大多数现场我建议先按表空间隔离业务语义更清晰。2RMAN 恢复run { sql alter tablespace YOUR_TS offline immediate; restore tablespace YOUR_TS; recover tablespace YOUR_TS; sql alter tablespace YOUR_TS online; }如果你是按 datafile 恢复run { sql alter database datafile 12 offline; restore datafile 12; recover datafile 12; sql alter database datafile 12 online; }3恢复后再验证select*fromv$recover_file;selectfile#, name, error, recover, fuzzy from v$datafile_header order by file#;select*fromv$database_block_corruption;如果恢复后这些视图都干净再重新做 insert 验证。这个方案适用的前提你有 RMAN 备份受损文件不是 SYSTEM / 当前活动 UNDO 的关键文件你允许短时间隔离部分业务对象。这个方案为什么最靠谱因为你现在的根因明显已经偏“存储/文件/恢复”方向了。继续让 session 卡着只会把应用侧线程、连接池、事务、重试逻辑、甚至更多会话一起拖死。方案 C如果是“局部坏块”而不是整个文件坏掉走块级恢复或对象级绕行有些现场并不是整个 datafile 挂了而是某几个 block 坏了。这种情况下不一定非要整文件 restore/recover。Oracle 提供两类工具RMAN block recoveryOracle 文档说明RMAN 可以用RECOVER CORRUPTION LIST修复V$DATABASE_BLOCK_CORRUPTION里列出的坏块。DBMS_REPAIROracle 文档说明DBMS_REPAIR可用于检测并处理表/索引中的损坏块在修复或重建过程中还能尽量让对象继续可用。适合块级恢复的场景V$DATABASE_BLOCK_CORRUPTION里只有少数块目标对象清晰你不想整表空间下线太久有可靠备份链。RMAN 示例recover corruption list;或者指定块blockrecover datafile 12 block 34567;对象级绕行思路如果坏的是索引块优先考虑drop / rebuild index如果坏的是某个可迁移对象考虑CTAS 导出可读数据、重建表如果坏的是 LOB / 分区按分区或对象做局部切换如果坏块只影响少数脏数据且业务允许可临时绕过坏对象、先保核心链路。这个方案的优点是业务影响更小缺点是你必须非常确定损坏范围不然容易“修了表面、没修根因”。方案 D如果最后确认不是受损文件直接命中业务对象那就转查“控制文件 / 存储 I/O / 同盘拖死”这个方案是很多人容易忽略的即使坏文件和你的表不是同一个表空间也可能因为控制文件、数据文件、redo、ASM 磁盘组、LUN、挂载点在同一存储链路上导致 insert 看起来卡在“读取控制文件”。这是因为 Oracle 的控制文件读取/写入本身就可能发生而且控制文件共享信息写入还受 CF enqueue 串行保护一旦底层 I/O 很慢很多会话都可能被串着拖住。Oracle 官方对control file single write和control file parallel write的定义已经把这种串行/物理写入特征说得很清楚了。你要补查这些点1控制文件位置是否和故障 datafile 在同一盘组 / 同一路径selectnamefromv$controlfile;selectfile#, name from v$datafile order by file#;2OS / 存储层是否已有异常Linuxiostat -x 1multipathmultipath -llASM查磁盘组告警、rebalance、offline disk存储侧看 LUN latency、路径 flap、阵列告警3是否出现 file header / checkpoint / control file 相关告警alert logASM alertOS kernel log存储监控4控制文件是否做了多路复用且落在不同物理盘Oracle 官方建议控制文件至少保留两份并放在不同物理磁盘上控制文件损坏会导致实例无法正常工作。如果这里查出来是控制文件和问题 datafile 共盘 / 同一故障存储路径那你真正要修的是存储和控制文件布局而不是业务 SQL。✅️问题延伸这个问题最值得延伸的点是很多 DBA/开发会误判成下面几类1误判为“应用没提交”其实不是没提交而是事务在数据库端卡在 wait 上。尤其客户端一直转圈时肉眼最容易以为“insert 已经执行完了只是没 commit”。2误判为“没有锁就没事”这是 Oracle 现场排障里非常常见的坑。锁只是阻塞的一类I/O wait、recovery wait、control file wait、file header 校验失败一样能把 DML 卡死。3误判为“其他用户的数据文件坏了和我无关”不一定。只要出现下面任一情况就可能有关你的表 / 索引 / LOB / 分区就在那个文件上坏文件对应的是共享对象或共用表空间同一存储路径上的控制文件也被拖慢目标会话在申请 extent、更新索引、访问 undo 时碰到了异常底层存储不是“单文件问题”而是“整块 LUN / diskgroup 问题”。4误判为“表空间没满所以不是存储问题”表空间没满只能排除“空间不足”排不了文件丢失文件头损坏坏块底层磁盘高延迟ASM/文件系统路径异常控制文件读写抖动所以这类问题的正确排障顺序不是“先看锁、再看表空间大小”而是会话等待 → 文件恢复状态 → 文件头 → 坏块 → alert log → 存储层✅️问题预测如果这个问题不尽快处理我会预测后续很可能出现这些现象1更多 DML 开始堆积insert 先卡后面 update / delete / commit 也会开始异常因为连接池线程被占住事务链路会越积越多。2alert log 开始连续报错尤其是ORA-01157ORA-01110block corruptionfile header read errorI/O error其中ORA-01157官方就明确是“后台进程无法识别/锁定数据文件”。3受影响表空间逐步不可用如果恢复不及时相关对象会从“偶发卡顿”发展成“稳定失败”。4如果底层是共享存储故障控制文件 / redo / 更多 datafile 会一起受影响这时就不是单对象问题而是实例层级稳定性问题了。5如果坏的是 SYSTEM / 活动 UNDO风险会陡然升级Oracle 文档明确说这种场景数据库可能直接 shutdown。✅️小结我给你的最终判断是这不是一个“普通 insert 慢”或“普通锁等待”的问题而是一个高概率和“损坏数据文件 / 坏块 / 恢复状态 / 控制文件或底层存储 I/O”相关的故障。✅最靠谱、最落地的处理顺序是先抓当前卡住会话的真实 wait event立刻查V$RECOVER_FILE、V$DATAFILE_HEADER、V$DATABASE_BLOCK_CORRUPTION把受损文件和目标表/索引/LOB/分区关联起来查 alert log确认是否已有 ORA-01157 / ORA-01110 / corruption确认后立即对受损表空间做 offline RMAN restore/recover若只是局部坏块优先考虑 block recover / DBMS_REPAIR / 索引重建若业务对象没直接命中坏文件则转查同存储上的控制文件与 I/O 链路。一句话压缩“显示正在读取控制文件”大概率只是表象真正根因多半在损坏文件或底层 I/O。” 结语 互动说明希望以上分析与解决思路能为你当前的问题提供一些有效线索或直接可用的操作路径。若你按文中步骤执行后仍未解决不必焦虑或抱怨这很常见——复杂问题往往由多重因素叠加引起欢迎你将最新报错信息、关键代码片段、环境说明等补充到评论区我会在力所能及的范围内结合大家的反馈一起帮你继续定位 如果你有更优或更通用的解法非常欢迎在评论区分享你的实践经验或改进方案你的这份补充可能正好帮到更多正在被类似问题困扰的同学正所谓「赠人玫瑰手有余香」也算是为技术社区持续注入正向循环 文末福利技术成长加速包 文中部分问题来自本人项目实践部分来自读者反馈与公开社区案例也有少量经由全网社区与智能问答平台整理而来。若你尝试后仍没完全解决问题还请多一点理解、少一点苛责——技术问题本就复杂多变没有任何人能给出对所有场景都 100% 套用的方案。如果你已经找到更适合自己项目现场的做法非常建议你沉淀成文档或教程这不仅是对他人的帮助更是对自己认知的再升级。如果你还在持续查 Bug、找方案可以顺便逛逛我专门整理的 Bug 专栏《全栈 Bug 调优实战版》️这里收录的都是在真实场景中踩过的坑希望能帮你少走弯路节省更多宝贵时间。✍️如果这篇文章对你有一点点帮助欢迎给 bug菌 来个一键三连关注 点赞 收藏你的支持是我持续输出高质量实战内容的最大动力。同时也欢迎关注我的硬核公众号 「猿圈奇妙屋」获取第一时间更新的技术干货、BAT 等互联网公司最新面试真题、4000G 技术 PDF 电子书、简历 / PPT 模板、技术文章 Markdown 模板等资料通通免费领取。你能想到的绝大部分学习资料我都尽量帮你准备齐全剩下的只需要你愿意迈出那一步来拿。 Who am I?我是 bug菌热活跃于 CSDN | 掘金 | InfoQ | 51CTO | 华为云 | 阿里云 | 腾讯云 等技术社区CSDN 博客之星 Top30、华为云多年度十佳博主/卓越贡献者、掘金多年度人气作者 Top40掘金、InfoQ、51CTO 等平台签约及优质作者全网粉丝累计30w。更多高质量技术内容及成长资料可查看这个合集入口 点击查看 ️硬核技术公众号「猿圈奇妙屋」期待你的加入一起进阶、一起打怪升级。- End -
