当前位置: 首页 > 图文教程 > 数据库 > Oracle > 找回消失的联机日志文件

Oracle
Excel VBA连接并操作Oracle
Oracle 外连接实现代码
oracle 存储过程和函数例子
Oracle 数据库操作类
ORACLE 分区表的设计
Oracle 用户权限管理方法
Oracle In和exists not in和not exists的比较分析
利用windows任务计划实现oracle的定期备份
ORACLE11g随RHEL5系统自动启动与关闭的设置方法
在oracle 数据库查询的select 查询字段中关联其他表的方法
plsql和tsql常用函数比对
plsql与tsql的语法不同
ASP.NET调用oracle存储过程实现快速分页
执行drop表操作后数据库无法起动
分析Oracle有时会用索引来查找数据的原因
数据从MySQL迁移到 Oracle的注意事项
快速理解Oracle归档模式的命令及参数
在Oracle里加快SQL执行的三种方法
几条常见的数据库分页 SQL 语句
Oracle9I OCP认证过程

Oracle 中的 找回消失的联机日志文件


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-09-30   浏览: 119 ::
收藏到网摘: n/a

数据库环境简介:

  操作系统: Windows XP

  数据库版本: Oracle 10.2.0.1

  归档模式: 非归档

  备份策略: 没有任何的备份策略,无备份可用

  用途: 测试数据库

  【故障描述】

  今天在启动本机测试用数据库时惊现数据库无法启动,提示如下:


  C:\>sqlplus / as sysdba
  SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 16 18:25:43 2009
  Copyright (c) 1982, 2005, Oracle. All rights reserved.
  Connected to an idle instance.
  SQL> startup;
  ORACLE instance started.
  Total System Global Area 167772160 bytes
  Fixed Size 1247876 bytes
  Variable Size 75498876 bytes
  Database Buffers 83886080 bytes
  Redo Buffers 7139328 bytes
  Database mounted.
  ORA-00313: open failed for members of log group 1 of thread 1
  ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'
  SQL>

  如上提示,系统找不到联机日志文件,一身冷汗,就算是测试数据库也不能就这样“挂”了啊!

  顺着错误提示的目录,进入到日志文件所在的目录,哇塞,全部的日志文件都不见了!(现在想想,可能是因为这个测试数据库我好久没有问津了,也许在某一次的C盘文件批量整理的过程中连带这些重要的文件一同“整理”掉了),心中不免有些紧张,转念一想幸好是测试数据库,释然一下下,于是……我决定————恢复之,现把整个的恢复过程记录如下,希望屏幕前的您不要再犯我这样的错误了,作为一位DBA是绝对不应该允许自己犯这样的错误,即使是纯纯的测试数据库

  【故障分析】

  因为是全部的日志文件都被删除了,所以既包含当前联机日志,也包含非当前联机日志,我恢复的顺序是:先通过Clear的方式恢复非当前联机日志,再通过设置隐含参数_allow_resetlogs_corruption=TRUE的方式恢复当前联机日志(使用这种极端的恢复方式是我不想看到的,没有办法,谁叫我没有备份呢,找了半天连冷备都没做过。如果您有备份,记住要优先考虑使用备份进行恢复)。

 【故障处理】

  1.通过v$log视图确定哪些是当前联机日志和非当前联机日志


  SQL> select * from v$log;
  GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
  ------- ------- ---------- -------- ------- --- -------- ------------- ---------
  1 1 2 52428800 1 NO CURRENT 272945 16-JUN-09
  3 1 1 52428800 1 NO INACTIVE 252940 16-JUN-09
  2 1 0 52428800 1 YES UNUSED 0

  确定如下:

  group 1是当前联机日志

  group 2 和group 3是非当前联机日志

  2.通过Clear方式恢复非当前联机日志group 2 和group 3


  SQL> alter database clear logfile group 2;
  Database altered.
  SQL> alter database clear logfile group 3;
  Database altered.

  此时查看日志文件所在的目录会依次恢复出两个50M的日志文件REDO02.LOG和REDO03.LOG

  (注释:如果是该日志组还没有归档,则需要用如下的SQL命令进行操作

  alter database clear unarchived logfile group 2;)

  3.恢复当前联机日志 group 1,先演示确认一下通过clear的方式无法恢复当前联机日志


  SQL> alter database clear logfile group 1;
  alter database clear logfile group 1
  *
  ERROR at line 1:
  ORA-00313: open failed for members of log group 1 of thread 1
  ORA-00312: online log 1 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\REDO01.LOG'
  ORA-27041: unable to open file
  OSD-04002: unable to open file
  O/S-Error: (OS 2) The system cannot find the file specified.

4.设置隐含参数_allow_resetlogs_corruption为“TRUE”

  生成pfile


  SQL> create pfile from spfile;
  File created.

  停掉数据库


  SQL> shutdown immediate;
  ORA-01109: database not open
  Database dismounted.
  ORACLE instance shut down.

  在生成的pfile(对应文件是C:\oracle\product\10.2.0\db_1\database\INITsec.ORA)最后一行添加如下内容,保存退出

  _allow_resetlogs_corruption=TRUE

  5.使用pfile启动数据库到mount状态


  SQL> startup mount pfile=C:\oracle\product\10.2.0\db_1\database\INITsec.ORA;
  ORACLE instance started.
  Total System Global Area 167772160 bytes
  Fixed Size 1247876 bytes
  Variable Size 75498876 bytes
  Database Buffers 83886080 bytes
  Redo Buffers 7139328 bytes
  Database mounted.

  6.利用until cancel进行恢复


  SQL> recover database until cancel;
  ORA-00279: change 274548 generated at 06/16/2009 19:15:54 needed for thread 1
  ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\SEC\ARCHIVELOG\2009_06_16\O1_MF_1_1_%U_.ARC
  ORA-00280: change 274548 for thread 1 is in sequence #1
  Specify log: {=suggested | filename | AUTO | CANCEL}
  cancel
  ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
  ORA-01194: file 1 needs more recovery to be consistent
  ORA-01110: data file 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SEC\SYSTEM01.DBF'
  ORA-01112: media recovery not started

 7.resetlogs方式打开数据库


  SQL> alter database open resetlogs;
  Database altered.

  这时在日志文件所在的目录中就可以看到被恢复出来的当前联机日志REDO01.LOG

  8.到此,恢复过程完成,后续任务一:进行全库的EXP备份

  C:\>exp system/system file=exp_full_backup.dmf log=exp_full_backup.log full=y

  9.后续任务二:取消隐含参数_all_resetlogs_corrupt

  10.后续任务三:重建数据库

  11.后续任务四:使用IMP将刚刚备份的文件导入到数据库

  12.检查一下是否有无效的对象,处理之

  13.搞定!

  【总结】

  针对这个测试库,如果我有备份,恢复过程将大大简化,也许之需要这个过程1/10的时间。

  所以,

  请每一位亲爱的DBA记住,为了缩短故障时间,最有效的方法就是——————备份!制定有效的备份策略,即便这个数据库仅仅用于测试和娱乐。