ORA-600 [2662] "Block SCN is ahead of Current SCN

 

ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN大於当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了。这个错误一共有五个参数，分别代表不同的含义，

ORA-600 [2662] [a] [b] [c] [d] [e]

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE  (即是select checkpoint_change# from v$database)

Arg [c] dependent SCN WRAP

Arg [d] dependent SCN BASE （塊的SCN）

Arg [e] Where present this is the DBA where the dependent SCN came from.（dba,也就是這個塊的scn即Arg[d]）

我们分析错误中的提示，它的参数b=431267754,d=431272752,表明当前的SCN确实是小于dependent SCN，所以产生了这个600的错误。

通过查阅文档，发现这个错误的产生原因主要有以下几条：

1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库

2.硬件错误引起数据库没法写控制文件和重做日志文件

3.错误的部分恢复数据库

4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复

5.数据库crash后设置了_DISABLE_LOGGING隐含参数

6.在并行服务器环境中DLM存在问题

仔细对比了一下，发现问题可能是由于第一条产生的，由于设置了_ALLOW_RESETLOGS_CORRUPTION这个隐含参数后，虽然强制性的打开数据库，但是数据库本身存在了corruption，仍然存在严重的问题。

于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN，然后保证数据库可以全库的导出，然后重建数据库导入数据。

用internal用户登陆数据库后，连接别的用户，还是失败报错，执行：

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

如果是在數據庫開啟的時候出現該錯誤即開啟在mount狀態則：

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

但是在設置 events 之前必須設置參數_allow_error_simulation为true，這樣才能修改SCN

_minimum_giga_scn=1  (Minimum SCN to start with in 2^30 units

該參數在11g中默認為1，但在10g中為0)

在log中發現：

Current SCN is not changed: _minimum_giga_scn (scn 1073741824) is too small

這樣可以設置_minimun_giga_scn=10 推進SCN

通常我们对于ORA-600 [2662]错误的解决是通过10015 ADJUST_SCN事件来增进current SCN以达到比数据文件中最大的SCN还要大的目的，这样才可能启动数据库。

eygle的例子中报错信息如下：ITPUB个人空间­s"t"d5z4V Q2vp'F#^VY;\­r
ORA-00600: internal error code, arguments: [2662], [0], [547743994], [0], [898092653], [8388617], [], []

这个报错参数的含义在metalink中如此描述的：
&m‑fn
n0^+? }6[:V0Arg [a] Current SCN WRAP
.V?/~1J0A L‑m

---

E0Arg [b] Current SCN BASE
0_T^:fun0Arg [c] dependent SCN WRAP

MeW8Ao0为了存储更大的SCN值，当SCN BASE到足够大并开始重置的时候，SCN WRAP将加1。ITPUB个人空间*rtm_

---

`9u)l jY
Arg [d] dependent SCN BASE
d8C"Q.P zLEP C?)Q0Arg [e] Where present this is the DBA where the dependent SCN came from.ITPUB个人空间"pBEt;{­Z(\‑c C9_

---

\
也就是Arg [d] 的值是从哪个block中找到的，通常是一个data block address。

通过这几个参数根据一定的规则可以计算出我们需要的level。计算规则如下：ITPUB个人空间%D,dl9O,O‑ne$K"H6_
1.Arg [c] *4得出一个数值，假设为V_Wrap
6e'x*f9hNf02.如果Arg [d]=0，则V_Wrap值为需要的level
Bx1{N9cM
Cm0Arg [d] < 1073741824，V_Wrap+1为需要的levelITPUB个人空间!A"a"F2O3J^;M
Arg [d] < 2147483648，V_Wrap+2为需要的level
/^z
r {eTr0Arg [d] < 3221225472，V_Wrap+3为需要的level

仍旧看eygle的案例。ITPUB个人空间)K5@L@:db\!fZ
Arg [c] *4 = 0 * 4 = 0
'\$ybe9t |0Arg [d] = 898092653 < 1073741824ITPUB个人空间E6I P @hE G
所以level = 0+1 = 1ITPUB个人空间1TB

---

CH­l4W5kx"s8Z
因此其实eygle不需要增进level 10，level 1就应该足够了。

1. altersessionsetevents‘10015 trace name adjust_scn level 1‘;

看另外一个例子的报错信息，我们再来计算一次。

z2n+](_)[G q5Bc0ORA-00600: internal error code, arguments: [2662], [0], [2179133], [8656], [70114056], [33855201], [], []

Arg [c] *4 = 8656 * 4 = 34624ITPUB个人空间
]]%t,u‑m/O#a"Z
Arg [d] = 70114056 < 1073741824ITPUB个人空间 {"^"A/Q8?}
所以level = 34624 + 1 = 34625ITPUB个人空间S8] ?T VP/d&Nc
因此在这个例子中我们应该执行

Alter  session  set  events ‘IMMEDIATE trace name ADJUST_SCN level 34625‘;

使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库后,我们说很多时候你会遇到ORA-00600 2662号错误，这个错误的含义是:

A data block SCN is ahead of the current SCN.
;qH'J WD}m,b:A4Z't0The ORA-600 [2662] occurs when an SCN is compared to the dependent SCNITPUB个人空间T;b+D;hi;|
stored in a UGA variable.
bKeU4~0If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]ITPUB个人空间:g5@ ['U5G d3F
internal error.

在测试中,很容易模拟这个错误:

Thu Oct 20 10:38:27 2005
1],TY#R?1t z2y0SMON: enabling cache recovery
‑DfO_5W1j0Thu Oct 20 10:38:27 2005
)@i ]2A+eQ'~|0Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:
%W9C
Bv
J­I8y0ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []
_Yq6]$Hk T
R U0Thu Oct 20 10:38:28 2005

---

`9Z8?N&a+~%d0Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:ITPUB个人空间
z?M1W0q*D)p9d,wf
ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

如果SCN相差不多，可以通过多次重起数据库解决。

也可以通过内部事件:
3Y8~‑q#rt
VQ0alter session set events ‘IMMEDIATE trace name ADJUST_SCN level 1′;ITPUB个人空间$j I.y

---

d

---

V#l*r
来解决。

 

遇到ora-600和2662的问题，我们一般有2种方法解决：

一种是在open的状态下：用alter session set events 'IMMEDIATE trace name adjust_scn level n';
一种是在mount状态下：用alter session set events '10015 trace name adjust_scn level n';

 

除了上述方法推進SCN 還有一種方法利用bbed修改block的scn

案例

模擬出現ora-0600[2662]

SQL> shutdown immediate;

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 1653518336 bytes

Fixed Size                  2213896 bytes

Variable Size             956303352 bytes

Database Buffers          687865856 bytes

Redo Buffers                7135232 bytes

Database mounted.

SQL> recover database until  cancel;

ORA-00279: change 994481 generated at 12/22/2011 18:31:07 needed for thread 1

ORA-00289: suggestion : /archive/ora12/1_1_770581862.dbf

ORA-00280: change 994481 for thread 1 is in sequence #1

 

 

Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

ORA-10879: error signaled in parallel recovery slave

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

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

ORA-01110: data file 1: '/oradata/ora12/system01.dbf'

 

 

SQL> shutdown immediate;

SQL> startup mount;

ORACLE instance started.

 

然後設置隱含參數：

_allow_resetlogs_corruption=true

 

再startup mount

 

SQL> alter database open  resetlogs;

alter database open  resetlogs

*

ERROR at line 1:

ORA-00603: ORACLE server session terminated by fatal error

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

[995333], [12583040], [], [], [], [], [], []

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

[995333], [12583040], [], [], [], [], [], []

ORA-01092: ORACLE instance terminated. Disconnection forced

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

[995333], [12583040], [], [], [], [], [], []

Process ID: 25068

Session ID: 96 Serial number: 3

出現 ora-0600 [2662]

 

 

SQ.L>startup mount;

SQL> select checkpoint_change# from v$database;

 

CHECKPOINT_CHANGE#

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

   994485

 

然後增加隱含參數：

*._allow_error_simulation=TRUE

*._minimum_giga_scn=10  （推進了10億）

 

再

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 1653518336 bytes

Fixed Size                  2213896 bytes

Variable Size             956303352 bytes

Database Buffers          687865856 bytes

Redo Buffers                7135232 bytes

Database mounted.

SQL> alter session set events '10015 trace name adjust_scn level 1';

 

Session altered.

 

SQL> alter database open;

 

Database altered.

 

 

可是查看log發現

 

 

ORA-00600: internal error code, arguments: [2256], [0], [1073741824], [0], [1073741829], [], [], [], [], [], [], []

Incident details in: /ora101/diag/rdbms/ora12/ora12/incident/incdir_13361/ora12_ora_15232_i13361.trc

 

並且數據庫stop了

 

除了刚才的ORA-600 2662错误外，又新增了600的2256错误。根据METALINK文档Doc ID: Note:30681.1的描述，这时需要对ADJUST_SCN的LEVEL进行调整：

将参数c的值乘以4再根据SCN的范围确定LEVEL的值，根据需要将LEVEL设置为7，然后尝试尝试打开数据库：

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 1653518336 bytes

Fixed Size                  2213896 bytes

Variable Size             956303352 bytes

Database Buffers          687865856 bytes

Redo Buffers                7135232 bytes

Database mounted.

SQL> alter session set events '10015 trace name adjust_scn level 7';

 

Session altered.

 

SQL> alter database open;

 

Database altered.

 

數據庫開啟了，沒有再報錯

事後還是需要重新expdp/impdp數據庫的