正常关闭数据库的情况下（shutdown immediate或者shutdown nomal）,redo文件全部丢失。
此种情况下，由于是正常关闭数据库，数据文件，redo文件以及控制文件SCN是一直的，redo文件中的所有操作记录都已经归档，所以如果在这种情况下丢失所有redo的话，恢复是很简单的，一般思路是：
Startup mount
Recover database until cancel;
Alter database open resetlogs;(执行此命令后，oracle会重新建立redo文件)
执行完以上操作后，马上全备数据库。
具体恢复方法很多，主要有一下几种：
试验一：
用命令清空日志组方法
1、查看原来表中数据
SQL>; conn test/test
Connected.
SQL>; select * from test;
TEL
----------
1
2
3
2、插入新数据
SQL>; insert into test values(4);
1 row created.
SQL> commit;
Commit complete.
3、 正常关闭数据库
4、 利用os command删除所有redo文件。
5、 启动数据库
SQL>startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/T3/ORACLE/oradata/ORA9/redo01.log'
6、 查看当前日志状态
SQL>; select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 2 104857600 1 YES INACTIVE
487837 01-9月 -05
2 1 4 104857600 1 NO CURRENT
487955 01-9月 -05
3 1 3 104857600 1 YES INACTIVE
487839 01-9月 -05
看来redo01.log不是当前日志，对于这类非当前日志可以直接clear,系统会重新自动生成一个redo文件。
7、SQL>alter database clear logfile group 1;
Database altered.
7、 继续启动db
SQL>; alter database open;
alter database open
*
ERROR at line 1:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/T3/ORACLE/oradata/ORA9/redo02.log'
8、 看来redo也得恢复，但是redo02是当前redo,直接clear是不行的
SQL>; alter database clear logfile group 2;
alter database clear logfile group 2
*
ERROR at line 1:
ORA-00350: log 2 of thread 1 needs to be archived
ORA-00312: online log 2 thread 1: '/T3/ORACLE/oradata/ORA9/redo02.log'
尝试clear unarchived logfile group ,报错：
SQL> alter database clear unarchived logfile group 2;
alter database clear unarchived logfile group 2
*
ERROR at line 1:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/T3/ORACLE/oradata/ORA9/redo02.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
看来他是因为找不到这个文件，从有效的备份中cp一个过来看看
SQL>！ cp /T3/ORACLE/oradatabak/redo02* /T3/ORACLE/oradata/ORA9
SQL>alter database clear unarchived logfile group 2;
Database altered.
搞定……….
9、 按照oracle的某些做法也是可以的
SQL>alter database clear unarchived logfile group 1 unrecoverable datafile;
Database altered.
10、但是对于非当前日志就都可以，下面看看redo03
SQL>; alter database clear logfile group 3;
Database altered.
结论：
如果数据库是正常shutdown,非当前日志都可以直接clear来重新生成，而且不丢失数据，因为正常关闭db,数据已经写入dbf文件了。唯独当前日志不可以，当前日志必须首先从有效的备份中拷贝一个日志文件过来，然后用
alter database clear unarchived logfile group n 或alter database clear unarchived logfile group n,除此之外，还可以用下面的方法来做
试验方法二：
用cancel模式恢复数据库
前面的出错提示，步骤都一样，唯独恢复的方法不一样
SQL>startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/T3/ORACLE/oradata/ORA9/redo01.log'
看看丢失了哪些redo
SQL> host ls /T3/ORACLE/oradarta/ORA9/redo*
/T3/ORACLE/oradarta/ORA9/redo*: No such file or directory
看来redo都丢了
直接recover
SQL>recover database until cancel;
Media recovery complete.
这个时候redo还没有生成
SQL>; host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo*: No such file or directory
启动数据库
SQL>; alter database open ;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL>alter database open resetlogs;
Database altered.
（注意，这里必须用resetlogs,否则会错误的
SQL>alter database open noresetlogs;
alter database open noresetlogs
*
ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/T3/ORACLE/oradata/ORA9/redo01.log'
SQL>
Resetlogs其实就是根据控制文件让系统自动重新生成redo,如果noresetlog的话，就不会重新生成redo,缺少了文件，db自然无法启动）
SQL>host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo01.log /T3/ORACLE/oradata/ORA9/redo02.log /T3/ORACLE/oradata/ORA9/redo03.log
检验
SQL>select * from test.test;
TEL
----------
1
2
3
4
数据一点儿都没有丢失。
结论：
如果数据库是正常关闭的，用recover database until cancel可以轻松恢复或者说重新建立所有的redo，不再区分是否是当前日志，而且由于正常关闭，不会丢失任何数据，唯一可能丢失的情况就是如果日志还没有归档。
这种恢复方法由于要resetlogs,所以在恢复完成后，日志清零，以前的备份不再起作用，所以建议立即备份。
SQL>archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /T3/ORACLE/arch
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1
SQL>;
实验三：
通过重新生成控制文件来恢复redo
前面的都一样，只是处理方法不一样
SQL>; startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/T3/ORACLE/oradata/ORA9/redo01.log'
SQL>alter database backup controlfile to trace;
Database altered.
SQL>; shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
2、 修改一下刚才生成的那个文件
CREATE CONTROLFILE REUSE DATABASE "ORA9" RESETLOGS ARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/T3/ORACLE/oradata/ORA9/redo01.log' SIZE < XMLNAMESPACE PREFIX ="ST1" />100M,
GROUP 2 '/T3/ORACLE/oradata/ORA9/redo02.log' SIZE 100M,
GROUP 3 '/T3/ORACLE/oradata/ORA9/redo03.log' SIZE 100M
-- STANDBY LOGFILE
DATAFILE
'/T3/ORACLE/oradata/ORA9/system01.dbf',
'/T3/ORACLE/oradata/ORA9/undotbs01.dbf',
'/T3/ORACLE/oradata/ORA9/cwmlite01.dbf',
'/T3/ORACLE/oradata/ORA9/drsys01.dbf',
'/T3/ORACLE/oradata/ORA9/example01.dbf',
'/T3/ORACLE/oradata/ORA9/indx01.dbf',
'/T3/ORACLE/oradata/ORA9/odm01.dbf',
'/T3/ORACLE/oradata/ORA9/tools01.dbf',
'/T3/ORACLE/oradata/ORA9/users01.dbf',
'/T3/ORACLE/oradata/ORA9/xdb01.dbf',
'/T3/ORACLE/oradata/ORA9/test01.dbf'
CHARACTER SET ZHS16GBK
;
另存为一个脚本，运行
SQL>@clone.sql
Control file created.
SQL>alter database open resetlogs;
Database altered.
SQL>;
搞定……………
结论：这种方法的关键是重新创建控制文件，后面的步骤和前面的道理一样的。
前面的三种方法都是假设db是正常关闭的，数据已经写入数据库文件中，所以不会有数据存在于redo中，所以clear的话也不会有数据丢失。
试验五：丢失当前日志组的成员
1、SQL>; select * from v$logfile;
GROUP# STATUS TYPE MEMBER
---------- ------- ---------- ----------
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03.log
2 ONLINE
IXDBA.NET技术社区
/T3/ORACLE/oradata/ORA9/redo02.log
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01.log
GROUP# STATUS TYPE MEMBER
---------- ------- ------- -----------
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01a.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02a.log
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03a.log
SQL>; select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 2 104857600 2 YES INACTIVE
554599 02-9月 -05
2 1 3 104857600 2 YES INACTIVE
554601 02-9月 -05
3 1 4 104857600 2 NO CURRENT
554603 02-9月 -05
SQL>;
3、 模拟插入数据
SQL>; conn test/test
Connected.
SQL>; select * from test;
TEL
----------
1
2
3
4
SQL>; insert into test values(5);
1 row created.
SQL>; commit
2 ;
Commit complete.
4、 shutdown db,模拟删除一个当前日志成员
$ cd oradata/ORA9
$ ls redo03*
redo03.log redo03a.log
$ rm redo03a.log
5、 启动db,表面没有错误
SQL> startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
Database opened.
6、 查看日至成员
SQL>; select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03.log
2 ONLINE
IXDBA.NET社区论坛
/T3/ORACLE/oradata/ORA9/redo02.log
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01.log
GROUP# STATUS TYPE MEMBER
---------- ------- ------- ----------
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01a.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02a.log
3 INVALID ONLINE
/T3/ORACLE/oradata/ORA9/redo03a.log
7、 删除出问题的联机日志文件
SQL> alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log';
alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log'
*
ERROR at line 1:
ORA-01609: log 3 is the current log for thread 1 - cannot drop members
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03.log'
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03a.log'
看来当前日志成员是不允许删除的。
SQL>alter system switch logfile;
System altered.
SQL>; select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 5 104857600 2 NO CURRENT
557687 02-9月 -05
2 1 3 104857600 2 YES INACTIVE
554601 02-9月 -05
3 1 4 104857600 2 YES ACTIVE
554603 02-9月 -05
SQL> alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log';
Database altered.
SQL> alter database add logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log' to group 3;
Database altered.
SQL>; select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- ------
MEMBER
-----------------------------------------
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02.log
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01.log
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------------
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01a.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02a.log
3
/T3/ORACLE/oradata/ORA9/redo03a.log
看来还得切换一下日至
SQL>alter system switch logfile;
System altered.
SQL>select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------------
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02.log
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01.log
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
-----------------------------------------------
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01a.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02a.log
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03a.log
至此，大功告成…………….
结论：
只要日志组的member不是一个，出现前面的4种可能性是非常小的，即使出现了也有相应的恢复方法，所以不必惊慌；
如果memer多于1个，即使坏了其中的几个，也不会影响数据库的正常启动，启动后，再进行相应的操作即可，所以这个时候每天察看alert.log就显得非常重要了。
2：在数据库运行状态下损坏或者丢失全部redo，或者在数据库非法关闭后丢失redo文件，在此情况下又分两种情况：
（1）：数据库非法关闭后丢失全部redo
（2）：丢失的redo文件是非当前的，或者说是不活动的。
（3）：丢失或者损坏的redo文件是当前的。
下面分别说明如下：
（1）：数据库非法关闭后丢失全部redo
修改系统参数方法：
1、 插入数据
SQL>; select * from test;
TEL
----------
1
2
3
4
SQL>; insert into test values(5);
1 row created.
SQL>; commit;
Commit complete.
SQL>;
2、 强行关闭
SQL>; shutdown abort
ORACLE instance shut down.
SQL>;
3、 手工模拟删除全部redo
4、 启动db
SQL>; startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
5、 尝试使用前3中方法中最简单的
SQL>; recover database until cancel;
ORA-00279: change 550174 generated at 09/02/2005 16:00:19 needed for thread 1
ORA-00289: suggestion : /T3/ORACLE/arch/1_1.dbf
ORA-00280: change 550174 for thread 1 is in sequence #1
Specify log: {<RET>;=suggested | filename | AUTO | CANCEL}
看来不行
6、 修改initsid.ora，加入一行
_allow_resetlogs_corruption=true
7、 启动with pfile
SQL>; startup
ORACLE instance started.
Total System Global Area 320308312 bytes
Fixed Size 730200 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL>; host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo*: No such file or directory
SQL>; alter database open resetlogs;
Database altered.
SQL>; host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo01.log /T3/ORACLE/oradata/ORA9/redo02.log /T3/ORACLE/oradata/ORA9/redo03.log
8、 检验数据
SQL>; select * from test.test;
TEL
----------
1
2
3
4
SQL>;
看到了吧，我们前面由于执行了SHUTDOWN ABORT,这时候对数据的修改还没有保存到数据文件中，虽然执行了COMMIT,这个时候还在联机日志中，等待CKPT触发DBWR写入DATAFILE,但是这个时候执行了SHUTDOWN ABORT,redo被删除后，里面的信息也就丢了，造成数据丢失。
9、 备份，去掉那个隐含参数。
（2）：丢失的redo文件是非当前的，或者说是不活动的
大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。
1、启动数据库，遇到ORA-00312 or ORA-00313错误，如
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312:online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
从这里我们知道日志组1的数据文件损坏了
从报警文件可以看到更详细的信息
2、查看V$log视图
SQL>select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ---------- ------
1 1 YES INACTIVE
2 2 YES INACTIVE
3 3 NO CURRENT
可以知道，该组是非当前状态，而且已经归档。
3、用CLEAR命令重建该日志文件
SQL>alter database clear logfile group 1;
如果是该日志组还没有归档，则需要用
SQL>alter database clear unarchived logfile group 1;
4、打开数据库，重新备份数据库
SQL>alter database open;
说明：
1、如果损坏的是非当前的联机日志文件，一般只需要clear就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行clear。
2、建议clear，特别是强行clear后作一次数据库的全备份。
3、此方法适用于归档与非归档数据库。
（3）：损坏当前联机日志
归档模式下当前日志的损坏有两种情况，
一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损坏其实就是上文的实验1案例，首先从备份中恢复一个当前的redo文件，这也是冷备份时建议同时备份redo的原因。然后可以直接用alter database clear unarchived logfile group n来重建。最后open。
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法：
A. 最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份。
B. 通过强制性恢复，但是可能导致数据库不一致。（如果数据库没有备份，又不在归档模式下，之能采取这种方法）
下面分别用来说明这两种恢复方法
1．1通过备份来恢复
1、打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2)系统找不到指定的文件
2、查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE
3、发现clear不成功
SQL>alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
4、拷贝有效的数据库的全备份，并不完全恢复数据库
可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto，尽量恢复可以利用的归档日志，然后重新
recover database until cancel
这次输入cancel，完成不完全恢复，也就是说恢复两次。
如：
SQL> recover database until cancel;
Auto
……
SQL> recover database until cancel;
Cancel;
5、利用alter database open resetlogs打开数据库
说明：
1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据
2、这种方法适合于归档数据库并且有可用的数据库全备份。
3、恢复成功之后，记得再做一次数据库的全备份。
4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
1.2如果没有备份，进行强制性恢复
1、打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of loggroup 1 of thread 1
ORA-00312:online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2)系统找不到指定的文件
2、查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES INACTIVE
3 3 YES INACTIVE
3、发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
4、把数据库down掉
SQL>shutdown immediate
5、在init<sid>.ora中加入如下参数
_allow_resetlogs_corruption=TRUE
6、重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错，不再理会，发出
SQL>alter database open resetlogs;
7、如果幸运，数据库可以open，数据库被打开后，马上执行一个full export
8、shutdown数据库,去掉_all_resetlogs_corrupt参数
9、重建库
10、import并完成恢复
11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
说明：
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致数据库的不一致
2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据。
3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析
4、全部完成后做一次数据库的全备份
5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
问题：
上面的第7步，如果不能打开数据库，oracle此时可能会报ORA-00600:内部错误代码，参数: [2662],之类的错误，针对这个问题说明如下：
1：ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了.
2：于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN.
3：此时我们可以通过Oracle的内部事件来调整SCN:
出现ORA-00600:内部错误代码，参数: [2662],之类的错误可能会出现在打开数据库之前，也可能出现在通过用_allow_resetlogs_corruption=TRUE隐含参数打开数据库之后。
调整SCN有两种常用方法:
1.通过immediate trace name方式(在数据库Open状态下，即通过用_allow_resetlogs_corruption=TRUE隐含参数打开数据库之后报错600)
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已经足够。也可以根据实际情况适当调整。
2963
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
