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

Oracle
Oracle数据库索引创建要做到三个适当
解析Oracle中的概念:同义词、序列与视图
讲解七种数据库中Select Top的使用方法
浅谈在Windows环境下Kill掉Oracle的线程
OracleDatabaseLinks的实现方法
合理创建Oracle数据库的索引
关于PGA的功能
Oracle教程:SecureFile的功能
Oraclesequence在Hibernate如何使用
找回消失的联机日志文件
控制文件对于Oracle的重要性
对于Oracle的错误印象
Oracle批量fetch的小技巧
如何彻底的删除Oracle表
Oracle数据库中创建合理的数据库索引
Oracle数据库中数据如何存储
解决Oracle性能优化中的问题
Oracle 基本知识轻松学
Oracle认证:利用bulkcollect实现cursor批量fetch
控制文件多路复用保证Oracle数据库正常运行

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


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-09-30   浏览: 110 ::
收藏到网摘: 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记住,为了缩短故障时间,最有效的方法就是——————备份!制定有效的备份策略,即便这个数据库仅仅用于测试和娱乐。