ORA-01172报错卡在文件块恢复，数据库死活不动远程帮忙修复

（来源：某知名IT技术社区论坛，用户“迷茫的DBA”发帖） “救命啊！各位大佬，遇到一个极其棘手的问题，数据库是Oracle 19c，跑在Linux系统上，服务器之前因为存储有点问题突然断电了，重启之后数据库就起不来了，我尝试用startup命令启动，结果报了一个ORA-01172的错误，具体信息好像是说某个数据文件（比如是5号文件）的某个块（比如是1234号块）需要恢复，而且恢复卡住了，我接着用recover datafile 5命令进行恢复，它提示需要某个归档日志，我也给了，但奇怪的是，恢复过程一下子就显示‘完成介质恢复’，感觉特别快，完全不像是正常恢复一个坏块的样子，然后我再去启动数据库，还是报同样的ORA-01172错误，一模一样的数据文件号和块号，就这样陷入了死循环：启动报错 -> 恢复说完成 -> 启动继续报错，数据库就跟死了一样，卡在这里一动不动，我试了好几次，包括尝试自动恢复recover automatic datafile 5，结果也一样，这到底是怎么回事？是不是存储层面那个块真的物理损坏了？还是我恢复的方法不对？在线等，急！”

（来源：另一位资深DBA“Oracle老法师”在同一个帖子下的长篇回复） “楼主这个问题很典型，我遇到过不止一次，你先别慌，ORA-01172这个错误本身的意思是‘线程恢复因某个块需要恢复而停止’，简单说，就是数据库在启动过程中，进行实例恢复（Instance Recovery，就是利用在线日志把断电前没写完的数据写回去）时，发现某个数据块（就是你看到的5号文件的1234号块）的状态不对劲，它认为这个块需要先进行介质恢复（Media Recovery，就是需要用到归档日志的恢复）才能继续。

但问题就出在你执行恢复命令后,它为什么‘秒完’并且无效，根据我的经验，有几种可能，你需要按顺序排查：

第一,也是最常见的一种，归档日志序列出现断裂或者日志本身损坏，你回想一下，当恢复进程向你要归档日志时，你提供的日志文件名是不是它真正需要的下一个？或者，它需要的那个归档日志文件是不是已经丢失、损坏或者根本没生成？（因为断电可能正好发生在日志切换的时候），你可以尝试手动指定你认为可能是下一个的日志文件，或者用LIST FAILURE和ADVISE FAILURE命令（如果你有Oracle Data Guard选件的话）来获取更详细的建议，但很多时候，就是缺了某个日志。

第二,那个数据块可能真的发生了物理损坏，Oracle的恢复机制尝试去应用日志，但发现日志里记录的要修改的内容，无法应用到当前这个损坏的块上，因为它连基本的块头信息都读不通了，所以恢复过程可能‘象征性’地走了一下流程，然后放弃了，但实际上问题没解决，如果是这种情况，常规恢复就没用了。

第三,隐藏的Bug或内部错误，在某些Oracle版本中，可能存在与特定类型的块恢复相关的Bug，导致恢复逻辑出现错误判断。

我给你的远程排查思路是：

1. 确认归档日志链：仔细检查从当前数据文件头记录的最新SCN（系统改变号）开始，一直到最新的归档日志，序列号是否连续，文件是否存在且可读，可以用SELECT * FROM V$LOG_HISTORY;之类的视图辅助查看。
2. 尝试不完全恢复：如果确认某个日志丢失了，并且无法找回，你可能不得不考虑做一次基于时间点或SCN的不完全恢复，将数据库恢复到丢失日志之前的某个一致性状态，但这意味着会丢失一部分数据，操作要非常小心，务必先有备份！
3. 使用DBVERIFY检查块损坏：用Oracle自带的dbv工具检查那个报错的数据文件，命令大概是dbv FILE=你的数据文件全路径 BLKSIZE=8192（块大小根据你的数据库设置），如果dbv报告该块确实物理损坏，那就坐实了。
4. 物理损坏的终极手段：如果确认是物理损坏，而你有备份和归档日志，那么最干净的办法是从备份中恢复那个数据文件，然后重新进行恢复（RECOVER DATAFILE），如果没有备份，万不得已时，可以考虑使用ALTER DATABASE DATAFILE ... OFFLINE DROP（仅限非系统表空间的数据文件！）把这个坏的数据文件脱机掉，然后打开数据库，但这样会导致这个数据文件里的所有数据丢失，需要根据业务重要性来决定，如果是系统表空间的文件坏了，此路不通。
5. 联系Oracle支持：如果以上都解决不了，并且问题极其重要，最好的办法是开具一个SR（Service Request）给Oracle官方支持，他们可能有更内部的工具和知识库来处理这种棘手的块恢复问题。

你现在卡住的这个状态,我强烈怀疑是第一种或第二种情况，先重点查归档日志链的完整性。”

（来源：某技术博客文章《ORA-01172故障排查实录》节选） “笔者曾经处理过一例与楼主描述几乎一模一样的故障，最终的原因出乎意料：存储闪存卡的缓存策略问题，服务器虽然重启了，但存储控制器的电池后备单元（BBU）失效，导致断电时缓存中的数据（包括部分Oracle数据块）未能正确写盘，造成了数据块内部的‘逻辑损坏’，这种损坏让Oracle的恢复进程误判了状态，解决方案是，在硬件厂商修复了存储问题后，我们最终还是从备份中恢复了那个数据文件才彻底解决问题，当软件层面排查陷入僵局时，别忘了向下看一眼硬件，特别是存储子系统。”

（来源：Oracle官方文档关于ORA-01172的简要说明，经由DBA口述理解） “官方对这个错误的解释是恢复过程因为需要恢复指定的块而停止，它建议的操作就是开始恢复，并应用所有必要的重做日志直到该块被恢复，但像楼主这种情况，显然恢复过程没有真正成功，官方文档没有深入探讨这种‘恢复死循环’的特殊情况，这通常需要结合具体环境分析。”

综合以上来源的信息,处理“ORA-01172报错卡在文件块恢复，数据库死活不动”的问题，核心在于打破“启动-恢复失败-再启动”这个循环，关键在于精准定位恢复过程“假成功”的原因，是日志问题、块物理损坏还是其他更深层次的原因，然后采取针对性的措施，从检查日志链完整性到验证块损坏情况，再到考虑不完全恢复或从备份还原，每一步都需要谨慎操作，在远程协助的情况下，清晰的沟通和按步骤的排查至关重要。