`

oracle日志文件损坏时,用隐含参数启动:_allow_resetlogs_corruption

 
阅读更多

Oracle隐含参数:_allow_resetlogs_corruption

提示:Oracle的隐含参数只应该在测试环境或者在Oracle Support的支持下使用。

 

在使用_disable_logging进一步的测试中,试图通过switch logfile进行日志切换,结果重起居然报出日志文件损坏。

 

SQL> startup
ORACLE instance started.

Total System Global Area   97588504 bytes
Fixed Size                   451864 bytes
Variable Size              33554432 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> select count(*) from t;
select count(*) from t
                     *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> create table t as select * from dba_users;

Table created.

SQL> select count(*) from t;

  COUNT(*)
----------
        12

 

试图通过switch logfile触发检查点:

 

SQL> alter system switch logfile;

System altered.


SQL> insert into t select * from t;

12 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from t;

  COUNT(*)
----------
        24

 

日志文件损坏(未测试是否可以重复出现):

 

SQL> startup force;
ORACLE instance started.

Total System Global Area   97588504 bytes
Fixed Size                   451864 bytes
Variable Size              33554432 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 3 change 897612314 time 10/19/2005 14:19:34
ORA-00312: online log 3 thread 1: '/opt/oracle/oradata/conner/redo03.log'

 

损坏的是active的日志文件:

 

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1        159   10485760          1 NO  INACTIVE             897592312 19-OCT-05
         2          1        158   10485760          1 NO  INACTIVE             897572310 19-OCT-05
         3          1        160   10485760          1 NO  ACTIVE               897612314 19-OCT-05
         4          1        161    1048576          1 NO  CURRENT              897612440 19-OCT-05

 

只好使用另外一个隐含参数_allow_resetlogs_corruption强制启动数据库,设置此参数之后,在数据库Open过程中,Oracle会跳过某些一致性检查,从而使数据库可能跳过不一致状态,Open打开:

 

SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;

System altered.

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area   97588504 bytes
Fixed Size                   451864 bytes
Variable Size              33554432 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 897612315 generated at 10/19/2005 16:54:18 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_160.dbf
ORA-00280: change 897612315 for thread 1 is in sequence #160


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: '/opt/oracle/oradata/conner/system01.dbf'


ORA-01112: media recovery not started


SQL> alter database open resetlogs;

Database altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area   97588504 bytes
Fixed Size                   451864 bytes
Variable Size              33554432 bytes
Database Buffers           62914560 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.

 

 

幸运的时候数据库就可以成功Open,如果不幸可能会遇到一系列的Ora-600错误(最常见的是2662错误)此时就需要使用多种手段继续进行调整恢复。 
如果注意观察alert日志,我们可能会发现类似以下日志:

 

 

Fri Jun 10 16:30:25 2005
alter database open resetlogs
Fri Jun 10 16:30:25 2005
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 240677200
Resetting resetlogs activation ID 3171937922 (0xbd0fee82)

 

 

Oracle告诉我们,强制resetlogs跳过了一致性检查,可能导致数据库损坏,数据库应当重建。
不一致恢复最后恢复到的Change号是:240677200

通常使用此方法Open数据库之后,应该立即通过导出、导入重建数据库

分享到:
评论

相关推荐

    oracle非归档模式丢失全部联机日志后的处理方法

    * 在使用隐含参数进行处理时,需要添加 _allow_resetlogs_corruption=TRUE 参数。 * 在打开数据库时,可能出现 ORA-00603 错误,可以通过多次重起数据库解决。 * 在处理过程中,需要多次重起数据库以解决错误。 ...

    oracle日志文件大全

    ALTER SYSTEM SET "_allow_resetlogs_corruption" = TRUE SCOPE = spfile; -- 恢复数据库 SQL> recover database until cancel; Cancel -- 重新打开数据库并重置日志 SQL> alter database open resetlogs ...

    解决ORACLE联机日志文件无故全部消失问题

    因此,我们需要设置隐含参数 `_allow_resetlogs_corruption=TRUE` 来恢复当前联机日志: ``` SQL> alter system set "_allow_resetlogs_corruption"=TRUE; ``` 然后,我们可以执行以下 SQL 命令来恢复当前联机日志...

    oracle备份恢复五个案例

    Oracle提供了一个隐含参数`_allow_resetlogs_corruption`,在启用后,允许在重置日志时忽略潜在的数据损坏。然而,这应作为最后手段,因为可能会永久丢失数据。在使用此参数前,应先尝试其他恢复策略,并充分理解其...

    REDO文件block损坏的解决方法

    首先,需在Oracle参数文件中设置`_allow_resetlogs_corruption=true`,这一设置允许数据库在redo日志块损坏的情况下进行resetlogs操作。注意,此参数仅在特殊情况下使用,应谨慎操作。 #### 步骤2:数据库实例重启 ...

    ORA-00600【4194】.pdf

    在本文中,我们使用了两个隐含参数:*_allow_resetlogs_corruption=TRUE 和 *.undo_management='manual'。第一个参数允许数据库在启库时恢复日志文件,第二个参数设置Undo 表空间的管理方式为手动。 知识点2: Undo...

    ORACLE联机日志文件丢失或损坏的处理方法

    当联机重做日志文件丢失或损坏时,可能会导致数据库无法正常启动甚至数据丢失的情况发生。本文将详细介绍当遇到联机重做日志文件丢失或损坏时的处理方法,以及如何根据具体情况选择合适的解决方案。 #### 联机重做...

    Oracle日志文件丢失的解决方法

    当Oracle的日志文件丢失时,数据库可能无法正常启动,需要采取一些紧急措施来恢复。 首先,当发现Oracle日志文件丢失时,我们需要通过SQL命令行连接到数据库,以SYSDBA身份登录,执行`conn / as sysdba`。然后尝试...

    ORACLE日志丢失的恢复

    3. **设置参数**:在启动数据库之前,需要设置一个特殊的初始化参数`_ALLOW_RESETLOGS_CORRUPTION`为`TRUE`。 4. **启动数据库**:使用`STARTUP`命令启动数据库。 5. **打开数据库**: ```sql ALTER DATABASE OPEN...

    oracle恢复

    1. 设置隐含参数`_allow_resetlogs_corruption`:此参数主要用于在因redo日志异常而导致的数据库无法启动时,屏蔽redo前滚,强制打开数据库。但是这种方法可能会导致redo中的数据丢失,使用时需要非常慎重。 2. ...

    联机日志文件损坏后的恢复方法

    在Windows环境下使用Oracle数据库时,可能会遇到因联机重做日志文件损坏导致无法正常启动的情况。例如,在Windows系统重启之后尝试使用`startup`命令启动Oracle数据库时,可能遇到ORA-00333错误,提示为:“redolog ...

    oracle控制文件的建立

    控制文件对于数据库来说至关重要,没有控制文件,Oracle将无法启动数据库。 #### 二、创建控制文件 1. **创建新数据库时自动创建控制文件**: - 当通过`CREATE DATABASE`命令创建一个新的数据库时,Oracle会自动...

    Open resetlogs操作对Oracle数据库恢复的影响.pdf

    在这个过程中,数据库的运行会从“日志序列号4000”时发生的介质损坏情况,恢复到“日志序列号1000”时的备份点,然后继续运行到“日志序列号2500”,并用resetlogs选项打开数据库,重新开始日志记录,形成一个新的...

    Oracle 12c实战归档日志文件

    ### Oracle 12c实战归档日志文件详解 #### 一、归档日志文件概念及作用 **归档日志文件**是联机重做日志文件组的副本,它包含了重做记录(redo records)以及一个唯一的日志序列号(log sequence number)。这些文件...

    Oracle11g 崩溃后-dbf数据库文件恢复

    6. **打开数据库**:最后,使用`ALTER DATABASE OPEN RESETLOGS`命令打开数据库,这将创建新的重做日志组并更新控制文件。 7. **验证数据**:打开数据库后,进行全面的数据验证,确保所有表和索引都处于一致状态。 ...

    如何恢复只有完好数据文件的oracle数据库

    对于Oracle数据库来说,当遭遇数据文件损坏时,如果仅保留有完好的数据文件,那么恢复过程将更加复杂。本文将详细介绍在这种情况下如何恢复Oracle数据库,并提供具体的操作步骤和注意事项。 #### 二、准备工作 恢复...

    Oracle只有数据文件时的恢复

    Oracle数据库在遇到问题时,尤其是控制文件丢失或损坏的情况下,数据恢复是一项关键任务。本文将详细阐述如何在只有数据文件的条件下恢复Oracle数据库。 首先,当Oracle数据库的控制文件不可用,但数据文件完整时,...

    直接拷贝数据文件实现Oracle数据迁移

    控制文件、redo log文件、数据文件和临时文件应放入新服务器相应的Oracle数据和日志目录。参数文件(PFILE)应放在新数据库的PFILE路径下。 在新服务器上,启动数据库并检查所有文件是否正确加载。如果一切正常,你...

    Oracle控制文件的备份和恢复

    根据提供的文档信息,本文将重点围绕“Oracle控制文件的备份和恢复”这一核心主题展开,深入探讨控制文件的重要性、备份方法及其恢复过程。 ### Oracle控制文件的重要性和作用 Oracle数据库控制文件是数据库的一个...

Global site tag (gtag.js) - Google Analytics