暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片
首页 / 一次幸运的数据库文件大小变为0kb恢复经历

一次幸运的数据库文件大小变为0kb恢复经历

惜分飞 2026-01-14
89

“ 对于一个经常和数据库恢复打交道的人来说，大概率你遇到过文件文件0kb的情况，这次分享的案例客户由于硬件故障导致部分文件0kb，比较幸运的是客户只要19年升级之后的状态即可（其实主要就是要当时的配置数据，中间的业务数据可以不用），通过当前损坏的库和千辛万苦找到的一个备份文件完成本次恢复任务”


01

—

客户现状


客户一个比较久远系统,由于长期没有人维护,导致硬件故障,客户找人进行了硬件恢复之后,发现大量数据文件为0kb

这里可以看出来最关键的system01.dbf是0kb，这样的情况，基本上不可能完全恢复出来让业务运行正常，而且这个是硬件尝试恢复出来的情况（原始盘已经不存在了，想进一步底层恢复已经没有任何机会）


客户这个系统是17年上线,19年进行了一次升级,客户提出要求,只要能够恢复到19年升级之后的系统状态即可(因为是制造业系统,大量配置信息在里,至于后续产生的数据,无所谓),基于目前的数据文件情况,肯定无法恢复出来(因为字典数据在system01.dbf中)


基于这种情况,我这边在客户恢复的整个目录文件中,再三查找,发现了一个类似rman备份的文件(是21年的)


02

—

利用历史备份+USERS01.DBF解决问题


尝试对备份进行还原,但是在还原过程中发现大量坏块,没有办法,最后只能采用一些方法强制rman还原出来备份中的部分文件

    Corrupt block 653695 found during reading backup piece, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, corr_type=-2
    Reread of blocknum=653695, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=653695, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=653695, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=653695, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=653695, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Continuing reading piece H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, no other copies available.
    Fri Jun 06 14:23:26 2025
    Cannot read block 1 from S:\DBFILES\BACKUP\ORA_DF1080446471_S8590_S1 - 
       restore failover to read from H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1
    ORA-19505: 无法识别文件"S:\DBFILES\BACKUP\ORA_DF1080446471_S8590_S1"
    ORA-27041: 无法打开文件
    OSD-04002: 无法打开文件
    O/S-Error: (OS 2) 系统找不到指定的文件
    Full restore complete of datafile 2 to datafile copy H:\BAIDUNETDISK\BACKUP\BACKUP\2_SYSAUX01.DBF.Elapsed time: 0:00:04
      checkpoint is 16694678523790
    Full restore complete of datafile 1 to datafile copy H:\BAIDUNETDISK\BACKUP\BACKUP\1_SYSTEM01.DBF.Elapsed time: 0:00:05
      checkpoint is 16694678523790
      Undo Optimization current scn is 16694646809619
    Fri Jun 06 14:23:47 2025
    Datafile rdba reconstruction error, expected block greater than 3305201, got 3304960 for datafile 4
    Corrupt block 3746806 found during reading backup piece, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, corr_type=4
    Datafile tail reconstruction error, expected tail of 0, got -1601108480 for datafile 4
    ………………
    Corrupt block 4290319 found during reading backup piece, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, corr_type=-2
    Reread of blocknum=4290319, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=4290319, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=4290319, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=4290319, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Reread of blocknum=4290319, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found same corrupt data
    Continuing reading piece H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, no other copies available.
    Fri Jun 06 16:01:21 2025
    Hex dump of (file 4, block 1) in trace file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_ora_15808.trc
    Corrupt block relative dba: 0x01000001 (file 4, block 1)
    Bad check value found during deleting datafile copy
    Data in bad block:
     type: 0 format: 2 rdba: 0x01000001
     last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
     spare1: 0x0 spare2: 0x0 spare3: 0x0
     consistency value in tail: 0x00000001
     check value in block header: 0x0
     computed block checksum: 0xa601
    Reread of blocknum=1, file=H:\BAIDUNETDISK\BACKUP\BACKUP\4_USERS01.DBF. found valid data
    Switch of datafile 4 complete to datafile copy 
      checkpoint is 16126

    很明显还原出来的system/sysaux文件可能还可以使用,但是users01.dbf肯定不行(从checkpoint is SCN)可以判断出来(users01.dbf是初始化出来的),基于这种情况,利用当前的system和sysaux打开数据库

      Fri Jun 13 22:05:31 2025
      Media Recovery failed with error 1610
      Fri Jun 13 22:05:31 2025
      Signalling error 1152 for datafile 1!
      Signalling error 1152 for datafile 2!
      Signalling error 1152 for datafile 3!
      Signalling error 1152 for datafile 4!
      Checker run found 5 new persistent data failures
      Recovery Slave PR00 previously exited with exception 283
      ORA-283 signalled during: ALTER DATABASE RECOVER  database until cancel  ...
      ALTER DATABASE RECOVER    CANCEL  
      Media Recovery Canceled
      Completed: ALTER DATABASE RECOVER    CANCEL  
      Fri Jun 13 22:06:04 2025
      alter database open resetlogs
      RESETLOGS is being done without consistancy checks. This may result
      in a corrupted database. The database should be recreated.
      ………………
      Fri Jun 13 22:06:07 2025
      QMNC started with pid=25, OS id=20288 
      LOGSTDBY: Validating controlfile with logical metadata
      LOGSTDBY: Validation complete
      Completed: alter database open resetlogs

      导出需要的业务用户字典信息,然后把客户那边提供的users01.dbf文件(users02.dbf是客户在21年之后增加的,原则上客户要的数据都在users01.dbf中)中的数据恢复到导出的字典中,完成本次数据恢复,客户远程验证业务,运行正常,客户需要的配置信息都在其中.



      oracle
      文章转载自惜分飞，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

      评论