共计 8339 个字符,预计需要花费 21 分钟才能阅读完成。
一、问题描述
1、数据库情况
1)Oracle 数据库版本:11.2.0.4;
2)未开启归档;
3)没有备份:无 RMAN 备份、无 DUMP 备份;
4)数据库 redo log 日志组,每组只有一个成员;
2、问题出现原因
因公司断电,导致生产数据库宕机,开启后,出现 ORA-00600[2662]问题:ORA-00600: internal error code, arguments: [2662], [2], [1424107441], [2], [1424142235], [8388617], [], []。
通过查看数据库状态,只能开启到 mount 状态,并且有一个日志组文件损坏,而且损坏的是 current redo log,并且这个组中,只有这一个日志组成员。
ORA-00600[2662]原因如下:
1)A data block SCN is ahead of the current SCN.(SCN 不一致)
2)Bug 14351566 ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back;
3、SCN 简介
SCN 即系统改变号(System Change Number),是在某个时间点定义数据库已提交版本的时间戳标记。Oracle 为每个已提交的事务分配一个唯一的 SCN。SCN 的值是对数据库进行更改的逻辑时间点。Oracle 使用此编号记录对数据库所做的更改。在数据库中,SCN 也可以说是无处不在,数据文件头,控制文件,数据块头,日志文件等等都标记着 SCN。也正是这样,数据库的一致性维护和 SCN 密切相关。不管是数据的备份,恢复都是离不开 SCN 的。
回到顶部
二、问题处理思路
排除了因为 Bug 导致 ORA-00600[2662]的错误,那么错误就定位在 SCN 不一致上面。
因为没有可用的日志、备份、归档等条件,只能采用重建控制文件,并通过设置 Oracle 内部隐含参数_allow_resetlogs_corruption=TRUE 跳过一致性检查,强制 open 数据库。
回到顶部
三、解决步骤
1、参数文件中加入_allow_resetlogs_corruption=TRUE
alter system set _allow_resetlogs_corruption=TRUE scope=spfile;
注意:
即便加上此参数,数据库在此时开启,仍然会爆出 ORA-00600[2662];
如果之前在无法 open 数据库的时候,加上此参数,仍然会爆出 ORA-00600[2662]。
2、重建控制文件
CREATE CONTROLFILE REUSE DATABASE “TRSDB” RESETLOGS NOARCHIVELOG – 注意:因为数据库本身就是非归档模式,所以也以非归档模式重建,在追加完 SCN 后,open 数据库,直接 open 就可。
— SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 ‘/home/oracle/app/oracle/oradata/trsdb/redo01.log’ SIZE 50M, — 等数据库恢复后,需要在日志组中在加上一个日志组成员(一个日志组至少两个成员)
GROUP 2 ‘/home/oracle/app/oracle/oradata/trsdb/redo02.log’ SIZE 50M,
GROUP 3 ‘/home/oracle/app/oracle/oradata/trsdb/redo03.log’ SIZE 50M
— STANDBY LOGFILE
DATAFILE
‘/home/oracle/app/oracle/oradata/trsdb/system01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sysaux01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb12_2.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/users01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/bigdb.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb03.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb04.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb05.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb06.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb07.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb08.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb09.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb10.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb11.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb12.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device03.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device04.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device05.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device06.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device07.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device08.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device09.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device10.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device11.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device12.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/bigdb-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb08-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb09-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb10-1.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb07-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb06-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb05-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device11_2.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device11_3.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device11_4.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device11_5.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb12_1.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb01a.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb01b.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb021.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb02-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb07-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb10-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb03-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb06-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb11-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb09-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb04-03.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb05-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb02-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/bigdb-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/bigdb-03.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/bigdb-04.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb01c.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb03-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb04-02.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB07_2018060817_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB08_2018061109_2.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB09_2018061917_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB10_2018062618_3.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB12_2018071420_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB02_2018072309_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB01_2018072409_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB01_2018072409_2.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE01_2018072409_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE02_2018072409_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE03_2018072717_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB06_2018072717_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE08_2018072717_2.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE09_2018072717_2.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB05_2018072717_2.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/SGDB03_2018072718_1.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE06_2018072718_2.dbf’,
‘/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/DEVICE07_2018072718_2.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/device04-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb04-01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb09-03.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/sgdb08-02.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/audit01.dbf’,
‘/home/oracle/app/oracle/oradata/trsdb/undotbs02.dbf’
;
3、使用 oradebug poke 推进 SCN
1)oradebug setmypid
2)oradebug dumpvar sga kcsgscn_
3)oradebug poke 0x060012658 8 10014077592
4)oradebug dumpvar sga kcsgscn_
5)alter database open;
至此数据库恢复完毕,后面还需要将数据导出,并重建这个非常规恢复的数据库。
oradebug 主要是给 oracle 支持人员使用的,尽管很早便有,但 oracle 官网很少有记载。他是个 sql*plus 命令行工具,有 sysdba 的权限就可以登入,无需特别设置。他可以被用于:
1)追踪进程,或者是你的,或者是外部的
2)确定进程往哪个 trc 文件写
3)转储:数据文件头、内部 oracle 结构等
4)挂起进程,暂时的
5)确定实例使用了哪些共享内存块和信号量
6)找出 RAC 实例使用了哪些互联地址和协议
7)修改 SGA 中的数据结构
To poke memory locations use
SQL>ORADEBUG
POKE address length value
where address and value can be decimal or hexadecimal and length is in bytes
补充实际计算推进 SCN 的方法
在实际这类工作中,我们实际应该是要认真计算好需要推进 SCN 的值,而不应图省事直接给一个很大的值。后者不但是技术水平不成熟的表现,而且是不负责任的行为。
ORA-00600: internal error code, arguments: [2662], [2], [1424107441], [2], [1424142235], [8388617], [], []
select 2*power(2,32)+1424142235 from dual;
10014076827
ORA-00600: internal error code, arguments: [2662], [2], [1424142249], [2], [1424142302], [8388649], [], []
select 2*power(2,32)+1424143000 from dual;
10014077592
2662 后面 5 个参数,用 A B C D E 表示
总结公式:c * power(2,32) + d {+ 可适当加一点,但不要太大!} ## 之前不知道这个算法,我将 SCN 推进了比较小,数据库还是无法恢复。使用这个算法后,数据库则恢复。
c 代表:Arg [c] dependent SCN WRAP
d 代表:Arg [d] dependent SCN BASE
oradebug setmypid
oradebug dumpvar sga kcsgscn_
oradebug poke 0x060012658 8 10014077592
oradebug dumpvar sga kcsgscn_
alter database open;
注意:
网上大量的恢复文章,步骤都不正确,混淆视听,经过确认,只要上面的三步即可恢复。
不需要如下:恢复数据库
1)recover database using backup controlfile until cancel;
2)alter database open resetlogs;
回到顶部
四、数据库导出
导出数据库的时候有个 ora-01552 的关于 undo 表空间的报错
解决方法:
1、表空间管理改为自动管理 auto(因为之前看文档,要将 undo 管理,改为手动)
2、新建表空间
3、将新的表空间切换为默认表空间,弄完后则可 expdp 导出
回到顶部
五、事后总结
1、在做这次数据库恢复时,从网上选取了多种恢复方法,最后得到只有 oradebug poke 推进 SCN 的方法适合 11.2.0.4 版本,其他方法已经不适用;
2、数据库处于整个系统的终端,对数据库做的各种安全保护手段都不为过
1)必须对数据库做定期备份(RMAN/DUMP)
2)必须对日志文件使用日志组的方式,这样可以保证,同一组内的一个 redo log 损坏,可以有后备的 redo log 继续工作;
3)必须开启归档日志。
更多 Oracle 相关信息见Oracle 专题页面 https://www.linuxidc.com/topicnews.aspx?tid=12
: