博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
[转]Oracle Hidden Parameter:_allow_resetlogs_corruption
阅读量:6342 次
发布时间:2019-06-22

本文共 4487 字,大约阅读时间需要 14 分钟。

本文转自eygle博客,原文地址:http://www.eygle.com/archives/2005/10/oracle_hidden_allow_resetlogs_corruption.html

 

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

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

1 SQL> startup 2 ORACLE instance started. 3  4 Total System Global Area   97588504 bytes 5 Fixed Size                   451864 bytes 6 Variable Size              33554432 bytes 7 Database Buffers           62914560 bytes 8 Redo Buffers                 667648 bytes 9 Database mounted.10 Database opened.11 SQL> select count(*) from t;12 select count(*) from t13                      *14 ERROR at line 1:15 ORA-00942: table or view does not exist16 17 18 SQL> create table t as select * from dba_users;19 20 Table created.21 22 SQL> select count(*) from t;23 24   COUNT(*)25 ----------26         12

 

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

1 SQL> alter system switch logfile; 2  3 System altered. 4  5  6 SQL> insert into t select * from t; 7  8 12 rows created. 9 10 SQL> commit;11 12 Commit complete.13 14 SQL> select count(*) from t;15 16   COUNT(*)17 ----------18         24

 

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

1 SQL> startup force; 2 ORACLE instance started. 3  4 Total System Global Area   97588504 bytes 5 Fixed Size                   451864 bytes 6 Variable Size              33554432 bytes 7 Database Buffers           62914560 bytes 8 Redo Buffers                 667648 bytes 9 Database mounted.10 ORA-00354: corrupt redo log block header11 ORA-00353: log corruption near block 3 change 897612314 time 10/19/2005 14:19:3412 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打开:

1 SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile; 2  3 System altered. 4  5 SQL> shutdown immediate; 6 ORA-01109: database not open 7  8 Database dismounted. 9 ORACLE instance shut down.10 SQL> startup mount;11 ORACLE instance started.12 13 Total System Global Area   97588504 bytes14 Fixed Size                   451864 bytes15 Variable Size              33554432 bytes16 Database Buffers           62914560 bytes17 Redo Buffers                 667648 bytes18 Database mounted.19 SQL> recover database using backup controlfile until cancel;20 ORA-00279: change 897612315 generated at 10/19/2005 16:54:18 needed for thread 121 ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_160.dbf22 ORA-00280: change 897612315 for thread 1 is in sequence #16023 24 25 Specify log: {=suggested | filename | AUTO | CANCEL}26 cancel27 ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below28 ORA-01194: file 1 needs more recovery to be consistent29 ORA-01110: data file 1: '/opt/oracle/oradata/conner/system01.dbf'30 31 32 ORA-01112: media recovery not started33 34 35 SQL> alter database open resetlogs;36 37 Database altered.38 39 SQL> shutdown immediate;40 Database closed.41 Database dismounted.42 ORACLE instance shut down.43 SQL> startup44 ORACLE instance started.45 46 Total System Global Area   97588504 bytes47 Fixed Size                   451864 bytes48 Variable Size              33554432 bytes49 Database Buffers           62914560 bytes50 Redo Buffers                 667648 bytes51 Database mounted.52 Database opened.

 

幸运的时候数据库就可以成功Open,如果不幸可能会遇到一系列的错误(最常见的是)此时就需要使用多种手段继续进行调整恢复。

如果注意观察alert日志,我们可能会发现类似以下日志:

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

 

Oracle告诉我们,强制resetlogs跳过了一致性检查,可能导致数据库损坏,数据库应当重建。

不一致恢复最后恢复到的Change号是:240677200
通常使用此方法Open数据库之后,应该立即通过导出、导入重建数据库。

 

转载于:https://www.cnblogs.com/myrunning/p/4702186.html

你可能感兴趣的文章
Spring Cloud Spring Boot mybatis分布式微服务云架构-hystrix参数详解
查看>>
真正的未来科技——人工智能
查看>>
View和Activity的生命周期
查看>>
解决PHP下载大文件失败,并限制下载速度
查看>>
从 MVC 到前后端分离
查看>>
(四)整合spring cloud云服务架构 - 企业分布式微服务云架构构建
查看>>
java B2B2C Springcloud电子商城系统—Feign实例
查看>>
java B2B2C Springcloud多租户电子商城系统 (五)springboot整合 beatlsql
查看>>
掌握 analyze API,搞定分词难题
查看>>
go 单元测试
查看>>
我的友情链接
查看>>
为什么很多公司的大数据相关业务都基于 Hadoop 方案?
查看>>
俱乐部活动:一步一步看数据持久化
查看>>
用SQL存储过程生成唯一单据号
查看>>
C语言-第七章、用指针实现程序的灵活设计
查看>>
nginx: [emerg] getpwnam("nginx") failed
查看>>
防火墙
查看>>
体育馆管理系统源代码
查看>>
十五道Hibernate面试题及答案
查看>>
Throwable是一个怎样的类?
查看>>