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

    数据库恢复的敏感性—重建控制文件使用不合适数据文件

    惜分飞发表于 2016-07-30 10:22:25
    love 0

    联系:手机(13429648788) QQ(107644445)QQ咨询惜分飞

    标题:数据库恢复的敏感性—重建控制文件使用不合适数据文件

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

    有客户数据库由于某种原因无法open,请求我们技术支持.通过检查alert日志发现数据库是由于ORA-600 kccpb_sanity_check_2错误.并且他们已经重建控制文件,通过我们的Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)
    datafile 6 异常
    wrong-file1
    wrong-file
    wrong-file-redo


    通过这里我们发现datafile 6 数据文件头是干净的,而且对应的redo seq为5270,而其他文件头都是fuzzy,而且对应的redo为295902613.这里怀疑datafile 6 可能是错误的.当然对于这样scn相距比较大的情况,我们可以通过隐含参数,修改scn等方法强制让该库起来(或者该文件online),但是从现在看到的情况,文件很可能异常,这样强制恢复,可能没有实际意义.
    分析alert日志
    alert-log

    这个里面可以发现是先删除了sde表空间,然后创建了同一个表空间,只是数据文件路径不一样了.而且正好在seq为5270的地方操作的.现在出现datafile 6异常的原因已经清楚,就是创建数据控制文件的时候,使用了错误的数据文件导致.

    完美恢复数据库

    D:\>sqlplus / as sysdba
    
    SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 7月 30 16:31:01 2016
    
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    
    
    连接到:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP and Data Mining options
    
    SQL> shutdown immediate;
    ORA-01109: 数据库未打开
    
    
    已经卸载数据库。
    ORACLE 例程已经关闭。
    SQL> STARTUP NOMOUNT
    ORACLE 例程已经启动。
    
    Total System Global Area 5133828096 bytes
    Fixed Size                  2011360 bytes
    Variable Size            2382368544 bytes
    Database Buffers         2734686208 bytes
    Redo Buffers               14761984 bytes
    SQL> CREATE CONTROLFILE REUSE DATABASE "LANDDB" NORESETLOGS  ARCHIVELOG
      2      MAXLOGFILES 16
      3      MAXLOGMEMBERS 3
      4      MAXDATAFILES 100
      5      MAXINSTANCES 8
      6      MAXLOGHISTORY 292
      7  LOGFILE
      8    GROUP 1 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_1_4JCM05KL_.LOG'  SIZE 50M,
      9    GROUP 2 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_2_4JCM064D_.LOG'  SIZE 50M,
     10    GROUP 3 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_3_4JCM06PG_.LOG'  SIZE 50M
     11  DATAFILE
     12    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSTEM_4JCLYY6T_.DBF',
     13    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_UNDOTBS1_4JCLYY8S_.DBF',
     14    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSAUX_4JCLYY7B_.DBF',
     15    'F:\ORADATA\LANDDB\DATAFILE\O1_MF_USERS_4JCLYY98_.DBF',
     16    'F:\ORADATA\LANDDB\DATAFILE\FUJIAN',
     17    ':\data\sde.dbf'
     18  CHARACTER SET ZHS16GBK
     19  ;
    
    控制文件已创建。
    
    SQL> recover database;
    完成介质恢复。
    SQL> alter database open;
    
    数据库已更改。
    
    SQL>
    

    这个库比较幸运,客户发现异常之后,里面停止了有风险性的操作(比如使用_allow_resetlogs_corruption参数,resetlogs库等),使得数据完美恢复0丢失.如果条件允许最好使用老的控制文件来重建新控制文件,而不要通过人工去系统中找数据文件来实现恢复,这样很可能有遗落或者使用错误的数据文件

    • VMware vSphere6.0 初试
    • 创建控制文件出现ORA-01565 ORA-27041 OSD-04002
    • ORACLE 12C安装预览
    • ORACLE 12C 控制文件异常恢复
    • ORACLE 7.3.4 截图欣赏
    • vSphere ssh登陆配置
    • system01.dbf文件被offline,导致数据库报ORA-01245 ORA-01110故障恢复
    • Oracle 8.0.5 安装过程截图
    • Oracle 8i安装过程截图
    • _OFFLINE_ROLLBACK_SEGMENTS/_CORRUPTED_ROLLBACK_SEGMENTS
    • ORA-01207/ORA-00338恢复
    • 12.1中出现大量Result Cache: RC Latch处理


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