current redo损坏。两个半小时的艰苦奋战

铁甲将军夜度关，朝臣戴露五更寒，山寺日高僧未起，看来名利不如闲。

current redo损坏。两个半小时的艰苦奋战

太TM吓人了，吓死个人了，还在用的开发环境

环境：

一个oracle软件，4个sid

export ORACLE_SID=hadb

背景：

还原一个sid是bjdb的库，由于没有recover没有第一个归档导致，数据库起不来，我试了n种办法，最后重建控制文件，但是生成控制文件报错了，于是想到在hadb生成一个，改下路径，但是只想着改datafile的位置了，忘记改logfile的位置了。哎，细心啊，不适合做dba。适合做富二代，吃啥啥没够，干啥啥不行。手生了，好久不搞ORACLE。MySQL走起

问题及其恢复

hadb打电话说库挂了，一个没搞好又挂了一个真棒，我不得不夸一下我自己。于是登录启动

报错1：

尝试alter database open;

ORA-00305: log 9 of thread 1 inconsistent; belongs to another database

原因是我把bjdb的库的redo指定到了hadb，导致了hadb的current redo损坏，通过v$log查看确实损坏的9是current redo

于是尝试不完全恢复。警告：这里如果log 9不是curren状态就很简单了。就直接clear
recover database until cancel;

首先是在交互模式输入auto，让数据库自动恢复下。再输入恢复命令然后cancel一下。

或者使用（recover database  until time '2022-03-29 15:30:10';）----此时大概会丢数据

尝试开库：alter database open;

报错2：

此时报错system.dbf文件有问题

alter database open ;提示需要resetlogs

alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf'

使用隐藏参数alter system set "_allow_resetlogs_corruption"=true  scope=spfile;（跳过文件头的一致性检查,强制启动数据库）重启数据库到mount，使隐藏参数生效

尝试开库alter database open;试一试 万一成功了呢

报错3：

alter database open;

ERROR at line 1:

ORA-00600: internal error code, arguments: [2662], [0], [1135607], [0], [1136957], [0], [], [], [],

[], [], []

再上一个隐藏参数，alter system set "_allow_error_simulation"=true  scope=spfile;（允许10015推scn）重启数据库到mount，使隐藏参数生效

使用10015推进scn，由于数据库只能启动到mount，所以使用如下方法，x表示scn，x是1表示推进10亿

alter session set events '10015 trace name adjust_scn level x';   -计算方法百度

10015增进SCN有两种常用方法:

1.通过immediate trace name方式(在数据库Open状态下)

alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

2.通过10015事件(在数据库无法打开，mount状态下)

alter session set events '10015 trace name adjust_scn level x';

注:level 1为增进SCN 10亿 (1 billion) (1024*1024*1024),通常Level 1已经足够。也可以根据实际情况适当调整。

LEVEL的计算规则：

ORA-00600: internal error code, arguments: [2662], [0], [547743994], [0], [898092653], [8388617], [], []

ORA-00600: internal error code, arguments: [2662], [a], [b], [c], [d], [e], [], []

A CRUUENT SCN WRAP   B--CURRENT SCN BASE  C--DEPENDENT SCN WRAP  D--DEPENDENT SCN BASE E--where present this is the dba where the dependent scn came from.

d< 1024*1024*1024=1073741824 时，需要的LEVEL为：c*4+1

d< 1024*1024*1024*2=1073741824*2 时，需要的LEVEL为：c*4+2

 

还可以通过设置隐含参数_minimum_giga_scn 快速递增CURRENT SCN。2012年1月后的PSU中包含隐含参数_external_scnrejection_threshold_hours,此时隐含参数和10015事件会失效。

尝试开库：alter database open;

报错4：

alter database open;

此时报错ora-600 4193   与4000和4194都是undo损坏

查看损坏的undo段

select segment_name,status from dba_rollback_segs where status<>'OFFLINE';  

创建一个参数文件使用_corrupted_rollback_segments参数可以使数据库在启动的时候,忽略损坏的回滚段,使数据库正常启动.

*._corrupted_rollback_segments=(_SYSSMU1_3780397527$,_SYSSMU2_2232571081$,_SYSSMU3_2097677531$,_SYSSMU4_1152005954$,_SYSSMU5_1527469038$,_SYSSMU6_2443381498$,_SYSSMU7_3286610060$,_SYSSMU8_2012382730$,_SYSSMU9_1424341975$,_SYSSMU10_3550978943$)

另外: _offline_rollback_segments参数可以让指定的回滚段处于OFFLINE状态

把如上查询损坏的undo写到pfile里，使用pfile启动，成功启动。顺利

后续处理：

关闭所有的隐藏参数

查看undo大小

select FILE_NAME,sum(bytes)/1024/1024 undo_M from dba_data_files where tablespace_name = 'UNDOTBS1';

SQL> create undo tablespace undotbs2 datafile '/u01/app/oracle/oradata/orcl/undotbs02.dbf' size 10M;

Tablespace created.

切换到UNDOTBS2 

alter system set undo_tablespace=UNDOTBS2 scope=both;

删除UNDOTBS1

SQL> show parameter undo

NAME                                 TYPE

------------------------------------ ----------------------

VALUE

------------------------------

undo_management                      string

AUTO

undo_retention                       integer

900

undo_tablespace                      string

UNDOTBS2

SQL> alter tablespace UNDOTBS1 offline;

Tablespace altered.

SQL> drop tablespace UNDOTBS1 including contents and datafiles;

Tablespace dropped.

清理log 9

 

如果STATUS 是ACTIVE ，表示正在归档， 此时需要使用如下语句：

alter database clear unarchived logfile group 9 ;

如果STATUS是INACTIVE,则表示已经完成了归档，直接清除掉这个redo log即可。

 

alter database clear logfile group 9 ;