铁甲将军夜度关，朝臣戴露五更寒，山寺日高僧未起，看来名利不如闲。
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 ;
