标签：非常规 数据文件 文件 恢复 数据库 归档 Oracle 日志
作者：唐小丹（浙江移动数据库管理员）
周 凯（上海新炬数据库工程师）
相信很多Oracle DBA在职业生涯中或多或少都遇到过这样的情况：数据文件被误删了，存储坏了无法识别数据文件，最糟糕的是，竟然rman备份也是坏的…… 遇到问题凌乱慌张是没用的，而贸然动手也是非常危险的，当遇到紧急问题，最重要的就是冷静分析，临危不乱。
下面我通过几个实战案例，给大家介绍几例数据文件异常可采用的非常规恢复方法。
一、数据文件被删除的恢复
实验场景：由于维护人员的误操作，导致数据库部分数据文件被删除，数据库报错。
>>>>故障模拟
10点59分，误操作删除文件。
11点20分数据库alert日志显示出现ora－01116等错误，根据后台日志显示此时ts_test01.dbf文件已经无法正常打开。
但是数据库没有因此关闭，还处于read write状态。
>>>>问题分析
数据文件被误删，数据库仍然处于open状态。对于此问题可以通过linux系统的“文件描述符”找回丢失的数据文件。在Linux系统中一切皆可以看成是文件，文件描述符（file descriptor）是内核为了高效管理已被打开的文件所创建的索引，所有执行I/O操作的系统调用都通过文件描述符。文件描述符打开的文件句柄以及i-node的关系如图：
在linux 系统中，数据文件被删除后，其文件句柄还被相关数据库进程所打开使用，可以通过该句柄信息直接复制将其恢复。需要注意的是，在此期间数据库不能关闭。否则相关句柄将被释放，文件就无法找回。
>>>>恢复步骤
尝试通过oracle dbwr进程找到被误删除的文件句柄。
当前的oracle dbwr进程的spid是3293 可以通过该进程找到丢失的ts_test01.dbf 文件句柄。
含一些数字命名的目录，它们是进程目录，其下的fd子目录包含进程相关的所有的文件描述符。子本例中oracle的dbwr 进程的fd目录下正有已经被删除的ts_test01.dbf文件的描述符（注：文件描述符为25，当前的状态是deleted）。
通过copy的方式恢复已删除的数据文件，并设置正确的属组权限。
通过将offline相关表空间并重置文件路径的方式完成文件重定向。
由于前期数据文件无法open的问题，部分已更改的数据无法写入数据文件，导致datafile header 上的checkpoint＃和controlfile文件的checkpoint_change#不一致，需要对数据文件进行介质恢复。
进行介质恢复之后，表空间可以正常online，故障处理也算完成。
>>>>总结感悟
作为系统维护人员rm，mv均属于高危操作，在执行之前一定要反复思考，确定影响，做到“宁停3分，不抢1秒”。当遇到数据库问题时，应维持故障现状，在没有清楚的了解问题原因以及解决方案之前，草率的行动将使问题复杂化，造成不可估量的损失。对于此案例，如果贸然的关闭数据库，只能使用rman备份进行恢复，如果备份失效，数据丢失将不可避免。总之做到，临危不乱！三思而行！
二、使用bbed跳过归档文件的完全恢复
实验场景：存储损坏导致部分数据文件损坏，需要使用备份进行还原，在数据库恢复阶段发现缺失部分归档，导致数据库无法恢复，正常启动。
>>>>实验环境准备
使用rman 为数据库做一个全备。
对test表执行insert操作，每三次insert后执行一次switch logfile，保证生成的34，35，36三个归档各包含3条insert的操作日志。
>>>>故障模拟
通过abort方式停库后，删除ts_test01.dbf 文件模拟存储故障。
人为删除sequence 35的归档日志。至此，故障已经重现。
当再次使用startup命令启动时，数据库在mount之后由于无法识别到datafile 6(ts_test01.dbf)，最终只能停留在mount阶段。
通过rman 的方式进行数据文件还原。在介质恢复阶段rman报错：no backup of archived log for thread 1 with sequence 35 and startingscn of…….。正是因为缺失了35号归档导致还原无法完成（35号归档已经被人为删除）。
归档日志按时间顺序记录着数据库上的各类操作（包括insert，delete，update，create 等等）。归档的丢失意味着部分操作的缺失，oracle将无法继续后续的归档文件的恢复。
在此情况下使用常规手段显然无法正常open数据库。需要通过bbed跳过缺失的归档使其继续完成介质恢复。
>>>>恢复步骤
通过rman的crosscheck archivelog all命令校验归档日志发现，缺少35号归档。
跳过缺失的归档需要将6号文件的scn向前推进至少大于等于36号归档的first change＃1243371
数据文件的scn被记录在文件1号block偏移量484字节开始的四个字节中。当前6号文件的scn经过大小端转换之后十进制的数值为1243327（dump的原值为bff81200经大小端转换后的十六进制为0012f8bf）。该值正好是35号归档的first change＃
使用bbed更改数据文件头的scn号，使其变为1243381（注意更改的scn需要大于36号归档的first change＃，在这次实验中使用36号归档的first change＃10作为新的scn号，经过十六进制以及大小端转换后数据为f5f812）, 并使用sum apply 命令重新计算校验和。
要想跳过归档还需要数据文件头块的rba。它由seq#、log block#、偏移量(固定为16)组成，决定了数据文件从哪个归档日志的哪个位置开始应用归档。Rba位于数据文件头块偏移量500处开始连续的12个字节(如图从23开始到0000ffff结束，前4个字节是日志的序列号，中间4个字节是日志块号，最后4个字节是偏移量)。
将rba修改为接下去的归档日志.log block#.offset#(这次试验rba被修改为24000000.02000000.10000000即36.2.16)
再次执行数据文件6的介质恢复后数据库可以正常打开。由于跳过了部分日志，免不了存在数据丢失或者不一致的问题。对于采用此方法恢复的数据库建议在合适的时候停机重建。
>>>>总结感悟
备份作为保障数据安全的最后一道防线，备份文件的有效性应该得到充分的验证。校验发现备份集异常，丢失等问题时，应该及时发起新的数据库备份。
Oracle数据库好比一个庞大而精密的机器，关键文件好比机器中的传动齿轮，任何的缺失都会导致整个系统的停滞崩溃。作为一个合格的DBA，我们既要会用机器，也要会修机器，更要胆大心细，临危不乱，为数据库的持久稳定运行保驾续航。
About Me
标签：非常规,数据文件,文件,恢复,数据库,归档,Oracle,日志 来源： https://blog.51cto.com/lhrbest/2692100
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。