IT博客汇
  • 首页
  • 精华
  • 技术
  • 设计
  • 资讯
  • 扯淡
  • 权利声明
  • 登录 注册

    rm -rf误删Oracle数据库恢复

    惜分飞发表于 2024-05-16 11:47:38
    love 0

    联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

    标题:rm -rf误删Oracle数据库恢复

    作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

    有客户把虚拟化环境中装有oracle数据库的linux操作系统,由于操作失误在/下面执行了rm -rf *,导致所有文件被删除,系统无法启动.客户希望要求恢复出其中的Oracle数据库.由于是虚拟化环境,然后客户直接从虚拟化平台下载下来磁盘文件,通过工具加载和分析确认是一个xfs的文件系统
    20240516190746


    使用工具进一步扫描分析,找到部分数据文件
    20240516190505

    这里可以获取到两个信息:
    1. 尝试恢复oracle的control01.ctl文件,然后通过该文件尝试分析其他数据文件位置,运气不错该文件恢复出来是好的,直接加载到新库查询v$datafile,分析出来所有数据文件信息
    2. 这里有一个非常不幸的信息,oracle最核心的system01.dbf文件大小明显异常,进一步分析该文件信息,结论是该文件无法通过反删除方式进行恢复
    20240515223607

    先把可以os层面可以恢复的数据恢复出来,并且检查坏块情况
    20240516191836

    对于异常的system文件,有两个处理方法:
    1. 通过阅览被删除的文件,发现客户有5月14日1点左右的rman备份,通过恢复软件中完整度提示,大概率应该没有什么问题,但是分析发现部分归档日志损坏无法完整恢复
    2. 通过对磁盘做碎片,恢复出来该数据文件,参考以往文章:
    dbca删除库和rm删库恢复
    Oracle 数据文件大小为0kb或者文件丢失恢复
    通过这个方法运气不错,恢复出来该库的system01.dbf文件非常完整0丢失

    [oracle@localhost oradata]$ dbv file=system01.dbf
    
    DBVERIFY: Release 19.0.0.0.0 - Production on Thu May 15 23:26:57 2024
    
    Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
    
    DBVERIFY - Verification starting : FILE = /u01/oradata/system01.dbf
    
    
    DBVERIFY - Verification complete
    
    Total Pages Examined         : 199680
    Total Pages Processed (Data) : 113988
    Total Pages Failing   (Data) : 0
    Total Pages Processed (Index): 26869
    Total Pages Failing   (Index): 0
    Total Pages Processed (Other): 40253
    Total Pages Processed (Seg)  : 1
    Total Pages Failing   (Seg)  : 0
    Total Pages Empty            : 18570
    Total Pages Marked Corrupt   : 0
    Total Pages Influx           : 0
    Total Pages Encrypted        : 0
    Highest block SCN            : 658228557 (0.658228557)
    

    完成上述恢复工作之后,目前确认只有sysaux01.dbf有8026个block损坏,但是该表空间不涉及业务数据,尝试在新的系统中直接修改路径并open库

    SQL> recover database;
    ORA-00283: recovery session canceled due to errors
    ORA-38760: This database instance failed to turn on flashback database
    
    
    SQL> alter database flashback off;
    
    Database altered.
    
    SQL> recover database;
    Media recovery complete.
    SQL> alter database open;
    
    Database altered.
    

    运气不错,数据库直接open成功,现在处理sysaux01.dbf中的损坏文件:
    1. 确认该文件具体坏块开始位置:
    20240516193650


    2. 由于坏块在文件中比较靠后,分析实际存储数据最后的位置

    SQL> select max(block_id+blocks) from dba_extents where file_id=3;
    
    MAX(BLOCK_ID+BLOCKS)
    --------------------
                 3493120
    

    最后存储数据的位置小于坏块的位置,证明坏块部分是没有存储数据的,直接resize掉坏块部分

    SQL> alter database datafile '/u01/oradata/sysaux01.dbf' resize 27290m;
    
    Database altered.
    

    然后dbv该数据文件,确认没有任何问题

    [oracle@localhost trace]$ dbv file=/u01/oradata/sysaux01.dbf
    
    DBVERIFY: Release 19.0.0.0.0 - Production on Wed May 15 22:43:00 2024
    
    Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
    
    DBVERIFY - Verification starting : FILE = /u01/oradata/sysaux01.dbf
    
    
    DBVERIFY - Verification complete
    
    Total Pages Examined         : 3493120
    Total Pages Processed (Data) : 1516833
    Total Pages Failing   (Data) : 0
    Total Pages Processed (Index): 1868832
    Total Pages Failing   (Index): 0
    Total Pages Processed (Lob)  : 56577
    Total Pages Failing   (Lob)  : 0
    Total Pages Processed (Other): 32107
    Total Pages Processed (Seg)  : 0
    Total Pages Failing   (Seg)  : 0
    Total Pages Empty            : 18771
    Total Pages Marked Corrupt   : 0
    Total Pages Influx           : 0
    Total Pages Encrypted        : 0
    Highest block SCN            : 658223915 (0.658223915)
    

    使用rman检测全库,也确定没有任何问题

    [oracle@localhost trace]$ rman target /
    
    Recovery Manager: Release 19.0.0.0.0 - Production on Wed May 15 22:43:58 2024
    Version 19.15.0.0.0
    
    Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
    
    connected to target database: XIFENFEI (DBID=2912535091)
    
    RMAN> 
    
    RMAN> 
    
    RMAN> backup validate check logical database skip inaccessible;
    
    Starting backup at 15-MAY-24
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=43 device type=DISK
    allocated channel: ORA_DISK_2
    channel ORA_DISK_2: SID=278 device type=DISK
    channel ORA_DISK_1: starting full datafile backup set
    channel ORA_DISK_1: specifying datafile(s) in backup set
    ………………
    File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
    ---- ------ -------------- ------------ --------------- ----------
    32   OK     0              6273         6400            370625094 
      File Name: /u01/oradata/xff_com.dbf
      Block Type Blocks Failing Blocks Processed
      ---------- -------------- ----------------
      Data       0              0               
      Index      0              0               
      Other      0              127             
    
    File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
    ---- ------ -------------- ------------ --------------- ----------
    33   OK     0              163752       832000          627920639 
      File Name: /u01/oradata/XFF_DATA_202312231.dbf
      Block Type Blocks Failing Blocks Processed
      ---------- -------------- ----------------
      Data       0              374296          
      Index      0              285002          
      Other      0              8950            
    
    Finished backup at 15-MAY-24
    
    [oracle@localhost trace]$ sqlplus / as sysdba
    
    SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 15 22:47:44 2024
    Version 19.15.0.0.0
    
    Copyright (c) 1982, 2022, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
    Version 19.15.0.0.0
    
    SQL> select * from v$database_block_corruption ;
    
    no rows selected
    
    SQL> 
    

    至此对于这次rm -rf /*的故障实现了Oracle数据库完美恢复,数据0丢失.

    • ORA-01578坏块解决(2)
    • 假坏块引起恐慌
    • rman制造坏块,bbed修复坏块
    • ORA-01578坏块解决(1)
    • 使用dd复制asm中文件
    • undo坏块导致数据库异常终止案例
    • 密码保护:dul抽取异常asm文件
    • bbed解决ORA-01578
    • segment header异常对象删除处理
    • 记录一次ORA-00600[kdsgrp1]分析
    • ORA-01092 ORA-00704 ORA-00942
    • 关于blockrecover 解决坏块相关测试与总结


沪ICP备19023445号-2号
友情链接