UDN-企业互联网技术人气社区

板块导航

浏览  : 1000
回复  : 0

[讨论交流] 非常规方法,轻松应对Oracle数据库危急异常

[复制链接]
爱飞的火车的头像 楼主
发表于 2016-5-20 18:13:10 | 显示全部楼层 |阅读模式
  非常规方法,轻松应对Oracle数据库危急异常


  相信很多Oracle DBA在职业生涯中或多或少都遇到过这样的情况:数据文件被误删了,存储坏了无法识别数据文件,最糟糕的是,竟然rman备份也是坏的…… 遇到问题凌乱慌张是没用的,而贸然动手也是非常危险的,当遇到紧急问题,最重要的就是冷静分析,临危不乱。

  下面我通过几个实战案例,给大家介绍几例数据文件异常可采用的非常规恢复方法。

  一、数据文件被删除的恢复

  实验场景:由于维护人员的误操作,导致数据库部分数据文件被删除,数据库报错。

  >>>>故障模拟

  10点59分,误操作删除文件。
1604081127396124.png


  11点20分数据库alert日志显示出现ora-01116等错误,根据后台日志显示此时ts_test01.dbf文件已经无法正常打开。
1604081127396120.jpg

  但是数据库没有因此关闭,还处于read write状态。
1604081127396113.png


  >>>>问题分析

  数据文件被误删,数据库仍然处于open状态。对于此问题可以通过linux系统的“文件描述符”找回丢失的数据文件。在Linux系统中一切皆可以看成是文件,文件描述符(file descriptor)是内核为了高效管理已被打开的文件所创建的索引,所有执行I/O操作的系统调用都通过文件描述符。文件描述符打开的文件句柄以及i-node的关系如图:
1604081127396116.png

  在linux 系统中,数据文件被删除后,其文件句柄还被相关数据库进程所打开使用,可以通过该句柄信息直接复制将其恢复。需要注意的是,在此期间数据库不能关闭。否则相关句柄将被释放,文件就无法找回。

  >>>>恢复步骤

  尝试通过oracle dbwr进程找到被误删除的文件句柄。
160408112739618.jpg


  当前的oracle dbwr进程的spid是3293 可以通过该进程找到丢失的ts_test01.dbf 文件句柄。
1604081127396110.png

  含一些数字命名的目录,它们是进程目录,其下的fd子目录包含进程相关的所有的文件描述符。子本例中oracle的dbwr 进程的fd目录下正有已经被删除的ts_test01.dbf文件的描述符(注:文件描述符为25,当前的状态是deleted)。
160408112739614.png

  通过copy的方式恢复已删除的数据文件,并设置正确的属组权限。
1604081127396118.png
1604081127396122.png

  通过将offline相关表空间并重置文件路径的方式完成文件重定向。
160408112739617.png

  由于前期数据文件无法open的问题,部分已更改的数据无法写入数据文件,导致datafile header 上的checkpoint#和controlfile文件的checkpoint_change#不一致,需要对数据文件进行介质恢复。
160408112739612.png

  进行介质恢复之后,表空间可以正常online,故障处理也算完成。

  >>>>总结感悟

  作为系统维护人员rm,mv均属于高危操作,在执行之前一定要反复思考,确定影响,做到“宁停3分,不抢1秒”。当遇到数据库问题时,应维持故障现状,在没有清楚的了解问题原因以及解决方案之前,草率的行动将使问题复杂化,造成不可估量的损失。对于此案例,如果贸然的关闭数据库,只能使用rman备份进行恢复,如果备份失效,数据丢失将不可避免。总之做到,临危不乱!三思而行!

  二、使用bbed跳过归档文件的完全恢复

  实验场景:存储损坏导致部分数据文件损坏,需要使用备份进行还原,在数据库恢复阶段发现缺失部分归档,导致数据库无法恢复,正常启动。

  >>>>实验环境准备

  使用rman 为数据库做一个全备。
160408112739615.png

  对test表执行insert操作,每三次insert后执行一次switch logfile,保证生成的34,35,36三个归档各包含3条insert的操作日志。
160408112739613.jpg
1604081127396112.jpg


  >>>>故障模拟

  通过abort方式停库后,删除ts_test01.dbf 文件模拟存储故障。

  

  人为删除sequence 35的归档日志。至此,故障已经重现。
1604081127396121.jpg


  当再次使用startup命令启动时,数据库在mount之后由于无法识别到datafile 6(ts_test01.dbf),最终只能停留在mount阶段。
1604081127396119.jpg

  通过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号归档。
1604081127396115.jpg

  跳过缺失的归档需要将6号文件的scn向前推进至少大于等于36号归档的first change#1243371
1604081127396114.jpg


  数据文件的scn被记录在文件1号block偏移量484字节开始的四个字节中。当前6号文件的scn经过大小端转换之后十进制的数值为1243327(dump的原值为bff81200经大小端转换后的十六进制为0012f8bf)。该值正好是35号归档的first change#

  
160408112739616.jpg

  使用bbed更改数据文件头的scn号,使其变为1243381(注意更改的scn需要大于36号归档的first change#,在这次实验中使用36号归档的first change#10作为新的scn号,经过十六进制以及大小端转换后数据为f5f812), 并使用sum apply 命令重新计算校验和。
160408112739619.png

  要想跳过归档还需要数据文件头块的rba。它由seq#、log block#、偏移量(固定为16)组成,决定了数据文件从哪个归档日志的哪个位置开始应用归档。Rba位于数据文件头块偏移量500处开始连续的12个字节(如图从23开始到0000ffff结束,前4个字节是日志的序列号,中间4个字节是日志块号,最后4个字节是偏移量)。
160408112739611.jpg

  将rba修改为接下去的归档日志.log block#.offset#(这次试验rba被修改为24000000.02000000.10000000即36.2.16)
1604081127396117.jpg

  再次执行数据文件6的介质恢复后数据库可以正常打开。由于跳过了部分日志,免不了存在数据丢失或者不一致的问题。对于采用此方法恢复的数据库建议在合适的时候停机重建。
1604081127396123.jpg

  >>>>总结感悟

  备份作为保障数据安全的最后一道防线,备份文件的有效性应该得到充分的验证。校验发现备份集异常,丢失等问题时,应该及时发起新的数据库备份。

  Oracle数据库好比一个庞大而精密的机器,关键文件好比机器中的传动齿轮,任何的缺失都会导致整个系统的停滞崩溃。作为一个合格的DBA,我们既要会用机器,也要会修机器,更要胆大心细,临危不乱,为数据库的持久稳定运行保驾续航。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部