oracle中一次redolog丢失的恢复

接到同事的电话,某省的一个用于监控的siteview数据库启动不了了,登录后检查alertlog发现:

Completed first pass scan
 9868 redo blocks read, 655 data blocks need recovery
Thu Apr 19 16:52:42 2007
Started recovery at
 Thread 1: logseq 700, block 194931, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 3 Seq 700 Reading mem 0
  Mem# 0 errs 0: C:\ORACLE\ORADATA\IMALLSV\REDO03.LOG
Thu Apr 19 16:52:43 2007
Ended recovery at
 Thread 1: logseq 700, block 204799, scn 0.147914177
 655 data blocks read, 655 data blocks written, 9868 redo blocks read
Crash recovery completed successfully
Thu Apr 19 16:52:43 2007
Errors in file c:\oracle\admin\imallsv\bdump\imallsv_lgwr_4180.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\IMALLSV\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
 
Thu Apr 19 16:52:43 2007
Errors in file c:\oracle\admin\imallsv\bdump\imallsv_lgwr_4180.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\IMALLSV\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
 
ORA-313 signalled during: alter database open...
原来是redolog被干掉了,其实对于redolog的丢失,如果丢失的不是active或者current(这个在win中一般不会被删除,因为使用时被锁定),我们可以用以下的方式恢复:

C:\Documents and Settings\Administrator>sqlplus "/ as sysdba"
 
SQL*Plus: Release 9.2.0.1.0 - Production on 星期四 4月 19 17:05:03 2007
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
 
连接到:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
 
SQL> shutdown immediate
ORA-01109: 数据库未打开
 
 
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
 
Total System Global Area  487660924 bytes
Fixed Size                   454012 bytes
Variable Size             209715200 bytes
Database Buffers          276824064 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
SQL> select * from v$log;
 
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
         1          1        699  104857600          1 NO  INACTIVE
    147462354 17-4月 -07
 
         2          1          0  104857600          1 NO  UNUSED
            0 16-4月 -07
 
         3          1        700  104857600          1 NO  INVALIDATED
    147678398 17-4月 -07
 
 
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR 位于第 1 行:
ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效
 
 
SQL> recover database until cancel;
完成介质恢复。
SQL> alter database open resetlogs;
 
数据库已更改。
 
SQL>
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
 
Total System Global Area  487660924 bytes
Fixed Size                   454012 bytes
Variable Size             209715200 bytes
Database Buffers          276824064 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
数据库已经打开。
至此,恢复完成。^_^

时间: 2025-01-20 15:39:41

oracle中一次redolog丢失的恢复的相关文章

Oracle Inactive联机日志文件丢失的恢复方法

联机日志文件Inacitve状态表示这个日志包含的数据修改已经同步到数据文件中,实例恢 复时已不需要它,所以它的丢失不会造成任何的数据丢失,但是会造成数据库无法打开,解 决方法是把丢失的inactive删除掉,重新添加新的联机日志. 1)模拟灾难 首先查 看log的状态: SQL> select group#,sequence#,status from v$log; GROUP#  SEQUENCE# STATUS ---------- ---------- ----------------  

oracle中asm disk header 彻底损坏恢复的方法

测试准备 创建新表空间,创建T_XIFENFEI测试表  代码如下 复制代码 SQL> create tablespace xifenfei datafile '+XIFENFEI' SIZE 50m;   Tablespace created.   SQL> CREATE TABLE T_XIFENFEI TABLESPACE XIFENFEI   2  AS SELECT * FROM DBA_OBJECTS;   Table created.   SQL> SELECT COUNT

oracle中exp dmp文件损坏怎么恢复

创建exp dmp文件并使用dd破坏  代码如下 复制代码 SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> select count(*) from t_xifenfei;   COUNT(*) ----------      90915 [oracle@localhost ~]$ exp chf/xifenfei@pdb1 file=/tmp/t_xifenfei.dmp table

oracle中alter database create datafile 导致数据文件丢失恢复

alter database create datafile导致原始数据文件丢失 有客户一个小系统找我们恢复,通过Oracle Database Recovery Check 检测之后我们红框部分发现一奇怪现象 1.文件头fuzzy为NO,不符合数据库异常crash常识,也和其他文件该状态不匹配 2.文件的创建时间,scn均和checkpoint时间,scn一致(也就是说该文件是创建之后就checkpoint,然后就没有其他操作) 3.文件开始应用的归档为5,110和其他数据文件要求的3115相

HP-EVA4400故障导致的oracle数据库丢失的恢复过程

一.故障描述 整个EVA存储结构是由一台EVA4400控制器,三台EVA4400扩展柜和28块FC 300G硬盘构成的.由于两块磁盘掉线导致存储某些LUN不可用,某些LUN丢失.由于EVA4400是因为某些磁盘掉线,从而导致整个存储不可用.因此接收到磁盘以后北亚工程师先对所有磁盘做物理检测,检测完后发现没有物理故障.接着使用坏道检测工具检测磁盘坏道,发现也没有坏道.磁盘坏道检测日志如下: 图一: 二.备份数据 考虑到数据的安全性以及可还原性,在做数据恢复之前需要对所有源数据做备份,以防万一操作不

探索ORACLE之RMAN_07控制文件丢失恢复

探索ORACLE之RMAN_07控制文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com 1.     控制文件(controlfile)丢失恢复 基于控制文件的复合多路径性,它的丢失分为两种,一种是其中某个控制文件的损坏或丢失,另外一种是所有控制文件均丢失.基于第一种情况,只需把好的控制文件复制一份在损坏或丢失的那个控制文件路径下即可.第二种情况下则需要通过备份信息来对控制文件进行恢复或手工

oracle中dul无法加载bootstrap实现unload table/user恢复

最近有朋友误操作引起了非常大的事故,差点吃了官司.在做数据库迁移的时候,远程误操作删除了原库的system等几个数据库初始安装的文件,而且该磁盘空间使用率非常高,还有少量写入.最后结果比较悲剧,通过文件系统层面无法直接恢复出来数据文件,而且该库无任何有效备份,又没有表名,列名等信息,无奈之下只能通过底层io block重组来恢复数据文件,可是悲剧又一次发生,这个磁盘上以前也有一份system等文件,最后经过多方重组恢复出来一份相对理想的数据文件.但是第三方公司通过这样重组出来的数据文件和未被删除

探索ORACLE之RMAN_07 参数文件丢失恢复

探索ORACLE之RMAN_07 参数文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com   Oracle数据库的参数文件有两种一种是pfile(初始化参数文件),还有一种是spfile(服务器初始化参数文件):实际上spfile是pfile衍生过来的一新参数文件,应用9i以后的版本,在9i之前的版本都不支持,只支持pfile:而且pfile是不能通过oracle命令来进行备份的,只有spf

oracle中数据库恢复历史再次刷新到Oracle 7.3.2版本—redo异常恢复

有网友在QQ上找我,说Oracle 7.3的数据库,因为redo异常咨询我是否可以恢复     检查数据库得到以下信息  代码如下 复制代码 SVRMGR> select * from v$version; BANNER ---------------------------------------------------------------- Oracle7 Workgroup Server Release 7.3.2.2.1 - Production Release PL/SQL Rel