史上最全Oracle文件损坏处理办法 (附实验步骤)

　　本文转自 | 数据和云

　　作者| 杨豹

　　概述

　　本文将给大家介绍oracle各类文件损坏的现象和应对策略，请注意所有的恢复都是基于有备份的情况，所以请开启数据库的日常备份。

　　文章将从以下文件展开：a. 密码文件b. 参数文件c. 控制文件d. 数据文件(分普通表空间数据文件，其它表空间数据文件如system、sysaux、undo)e. 日志文件(分current、active、inactive)

　　在正式实验之前，我先问一个问题，上面这些文件，哪个损坏最致命？欢迎在文末留言处留言。

　　环境准备

　　本实验在oracle 11G归档模式下进行，实验前先对数据库做个全库备份。

　　文件说明：密码文件存储的是sys密码

　　模拟故障：清空该文件

　　现象：使用sys通过oracle net登录报密码错误sqlplus sys/123456@10.40.16.120:1521/orcltest as sysdba

　　修复：使用自带工具orapwd重新生成密码文件

　　文件说明：这里所说的参数文件指的是spfile，该文件存储的是实例启动的参数和控制文件的路径

　　模拟故障：清空该文件

　　现象：修改数据库参数时会报错

　　修复：使用rman还原参数文件

　　注意在还原spfile的时候如果还原到spfile原先的位置，会报ORA-32011: cannot restore SPFILE to location already being used by the instance所以需要还原到一个新的路径，然后手工移过去PS：参数文件也可以从内存中直接创建一个新的，更省事（create spfile='/home/oracle/spfileorcltest.ora' from memory;）

　　文件说明：控制文件记录数据库文件的信息和日志的信息等查看控制文件

　　模拟故障：将该文件清空

　　现象：前台正常的增删改查不受影响，但一旦出现切换日志或产生检查点时数据库宕机

　　数据库alert日志

　　可以看到ckpt这个进程最先发现控制文件损坏了，实例之后被lgwr进程杀掉。可能大家在做实验的时候发现实例是被ckpt杀掉，这也是有可能的，反正可以肯定的一点是，实例最后肯定会挂掉修复：使用rman还原控制文件

　　说明：

　　a. 不要使用删控制文件的方式去模拟该实验，这是由于ckpt、lgwr进程已经打开了控制文件，内存中已经有了这个控制文件的镜像，而rm命令并不能把这些进程已经打开的控制文件的句柄删掉。所以你会发现实例并没有挂掉。b. 对数据库resetlogs之后，之前的备份就作废了，所以应该第一时间对数据库做一个全备。c. 可能大家也注意到了，该实验中只有一个controlfile，当controlfile被破坏了之后，实例就挂了。如果是controlfile的多路复用，其中一个controlfile坏了数据库又是什么影响？我这里先说下我的结论：controlfile只要有一个坏了，实例就会奔溃，同时在alert日志中会提示具体是哪个controlfile损坏，解决办法就是复制一份好的controlfile去替换损坏的controlfile，重新启库即可。实验就留给大家自己做吧。附一段我实验的alert日志（ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) ORA-00202: control file: '/u01/app/oracle/oradata/orcltest/control02.ctl'）总结：

　　1. 控制文件恢复不会丢失任何事务，但会要求数据库resetlogs，这将会导致之前的备份片无效，所以恢复控制文件后最好做一个全库备份。2. 对控制文件最好设置两个，一个坏了还能利用另一个恢复，对数据库的影响和恢复的时间都是最小的。

　　为了继续实验，请手工删除之前所有的归档日志和备份文件，并对现在的数据库做一个全备

　　模拟故障：将该文件清空echo '' > /u01/app/oracle/oradata/orcltest/tbs01.dbf // tbs01是一个普通表空间数据文件现象：查询该数据文件上的对象报错

　　修复：先对数据文件offline，然后使用rman还原恢复，最后online

　　模拟故障：将该文件清空

　　现象：查询数据字典报错

　　修复：先关库，然后使用rman还原恢复，最后启库

　　sysaux表空间的文件损坏处理手段与普通表空间数据文件损坏处理手段相同，undo表空间的文件损坏处理手段与system表空间数据文件损坏处理手段相同，因为undo表空间的数据文件也不能offline。限于篇幅省略实验步骤，仅贴出文件损坏的现象。sysaux表空间文件损坏现象：访问sysaux表空间的对象报错

　　undo表空间文件损坏现象：所有修改操作全部报错

　　查看当前日志状态：current-当前正在写入的日志组，active-还未归档的日志组，inactive-已归档的日志组

　　模拟故障：将inactive日志文件清空

　　现象：当数据库切换到该日志组时，数据库并不知道磁盘上的日志文件有问题，只是将内容写到日志文件在内存的拷贝中，等到切换的时候，日志文件落盘就会发现该日志是有问题的，然后alert日志出现报错，不过不影响数据库正常运行，只是以后数据库切换日志会跳过该日志组

　　观察alert日志

　　查看v$log，可以看到group 3一直没有被用到

　　修复：将该日志文件重新初始化

　　为了继续实验，请手工删除之前所有的归档日志和备份文件，并对现在的数据库做一个全备

　　查看当前日志状态

　　模拟故障：current日志文件清空

　　现象：前台正常的增删改查不受影响，但一旦出现切换日志数据库宕机

　　查看alert日志

　　恢复：使用不完全恢复打开

　　这个时候就需要加入隐含参数，再启动

　　说明：

　　a. 使用该方式恢复的库，可能会造成数据的丢失，而且也并不能保证一定成功。b. 恢复成功后，应将表全部使用expdp导出，重建库。c. 上面的实验每个日志组都只有一个member，如果每个日志组有两个member又是什么样子呢？

　　先说下我的结论：损坏其中任何一个member对数据库没什么影响，只是在切换到有member损坏的日志组时，会在alert日志中提示告警ORA-00313 ORA-00312 ORA-27048，解决办法就是删掉这个member，重新添加，不需要对数据库进行重启，实验过程我就不展示了。所以最好是每组日志中设置2个成员。这儿我有个疑问想不通：对inactive的日志进行破坏，数据库切换到这个被破坏的日志时，数据库正常写，只是在日志切换的时候报错，这个能理解，因为系统内存中有这个被破坏的日志之前的拷贝，所有的写可能都是在内存中。切换的时候该日志文件就必须要落盘，所以提示报错。而对current的日志进行破坏，数据库也正常写，但是在日志切换的时候数据库直接崩了。没弄懂这两个为什么会有这个区别。

　　1. 生产中应制定好备份策略2. 控制文件和日志文件最好是设置大于一个成员3. 当前日志组损坏最为致命，如果日志写很繁忙，可以只为日志文件配置一个成员，但同时需要配置一个dataguard，方便切换4. 此博客仅为个人理解，如有不对的地方，欢迎大家指出

　　作者：杨豹，东财基金DBA，modb.pro/db/22833

　　原文：https://www.cnblogs.com/ddzj01/p/12526100.html

　　⭐️更多阅读：误执行了 rm -rf /*删库之后，除了跑路还能怎么整？！一文带你解读 Redis分布式锁发展史和正确实现方式

　　80岁COBOL码农：「扶我起来，这个bug我会修。」

　　今日头条技术架构一览

　　中台的问题，是技术的问题，还是人的问题？

　　来，关于你对女程序员的好奇心，这里都告诉你为什么大部分人做不了架构师？这2点是关键

　　架构师为你详解：Nginx 架构我在外包公司做增删改查有前途么？10 款最佳的 MySQL GUI工具，DBA 必备神器！

　　再见，微服务

　　可能是全网最好的 MySQL 重要知识点

　　?资料下载DTCC中国数据库技术大会2020-2019SACC2019中国系统架构师大会PostgreSQL 2019中国技术大会点击上方文字可以直接进入小程序浏览，下载请在后台分别回复关键词⏬ DTCC、SACC、PG19即可直接收到完整版 PPT 下载链接