ORA-00600[2662]问题汇总

一、ORA-00600[2662]问题模拟及解决方法

这是2013年的一篇文章，也不知道数据库是什么版本，

我的数据库时11.2.0.4，使用下面方法模拟的时候，模拟不出来。。。。

参照eygle的相关技术blog，测试下_disable_logging将对数据库产生的影响，由于是隐含参数，所以我们通过如下方法获取对这个参数的描述：
SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%logging';

KSPPINM              KSPPDESC
------------------------------------
_disable_logging     Disable logging

将其改为ture，也就是启用了不记录日志的方式：
SQL> alter system set "_disable_logging"=true scope=both;

System altered.

创建一个，并模拟事务运行，生成大量的redo,
SQL> create table mm tablespace marvener as select * from dba_objects;

Table created.

SQL> insert into mm select * from dba_objects;

45167 rows created.

SQL> /

45167 rows created.
这个时候突然掉电了，也就是shutdown abort关闭数据库：
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 1610612736 bytes
Fixed Size                  2084296 bytes
Variable Size             385876536 bytes
Database Buffers         1207959552 bytes
Redo Buffers               14692352 bytes
Database mounted.
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 81435 change 856029 time 01/30/2012
15:50:39
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/marven/redo01.log'

如上。可以发现数据库无法正常打开，并提示重做日志块头损坏，在告警中可见大量的如下告警信息：
试图通过Resetlogs方式打开数据库：
alter system set "_allow_resetlogs_corruption"=true scope=spfile;
shutdown abort
startup
数据库仍然会显然如下告警，并强制关闭实例：

SMON: enabling cache recovery
Mon Jan 30 16:15:41 2012
Errors in file /u01/app/oracle/admin/marven/udump/marven_ora_2900.trc:
ORA-00600: internal error code, arguments: [2662], [0], [855728], [0], [855937], [8388649], [], []
Mon Jan 30 16:15:42 2012
Errors in file /u01/app/oracle/admin/marven/udump/marven_ora_2900.trc:
ORA-00600: internal error code, arguments: [2662], [0], [855728], [0], [855937], [8388649], [], []
Mon Jan 30 16:15:42 2012
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600
Instance terminated by USER, pid = 2900
ORA-1092 signalled during: alter database open resetlogs...
Mon Jan 30 16:16:34 2012

此时我们可以通过Oracle的内部事件来调整SCN:

增进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已经足够。也可以根据实际情况适当调整。
本次由于数据库并未打开，而处于mount状态，所以只能通过第二种方式：

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

SQL> alter database open;

Database altered.

摘自 marvelyu's notes

二、解决方法一 10015 trace name adjust_scn level

此方法对11.2.0.4已经不适用

一、错误现象（alert日志中）
Errors in file /opt/oracle/admin/conner/udump/conner_ora_31607.trc:
ORA-00600: internal error code, arguments: [2662], [0], [897694446], [0], [897695488], [8388697], [], []

二、错误解释
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
Arg {c} dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
注：897694446<897695488

三、错误原因
1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库
2.硬件错误引起数据库没法写控制文件和重做日志文件
3.错误的部分恢复数据库
4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复
5.数据库crash后设置了_DISABLE_LOGGING隐含参数
6.在并行服务器环境中DLM存在问题

四、解决办法
1、如果SCN相差不多，可以通过多次重起数据库解决（每次加1）

2、通过10015 ADJUST_SCN事件来增进current SCN
1）计算level
1.1) Arg {c}* 4得出一个数值，假设为V_Wrap
1.2) 如果Arg [d]=0，则V_Wrap值为需要的level
Arg [d] < 1073741824，V_Wrap+1为需要的level
Arg [d] < 2147483648，V_Wrap+2为需要的level
Arg [d] < 3221225472，V_Wrap+3为需要的level
1.3）SCN被增进了1024*1024*1024*level（level*10 billion）

2）执行内部事件
alter session set events ’10015 trace name adjust_scn level N’;
注：mount状态下执行（open下无效）
alert日志中会出现：
Sat Aug 20 15:41:07 2011
Debugging event used to advance scn to 107374182400

三、解决方法二使用bbed解决ORA-00600[2662]

此方法也是转载，但是内容很不详细，不予置评

一、数据库启动报ORA-00600[2662]

[oracle@node1 ora11g]$ sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 22 14:37:00 2011
 
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
 
Connected to an idle instance.
 
SQL> startup
ORACLE instance started.
 
Total System Global Area 2137886720 bytes
Fixed Size                  2230072 bytes
Variable Size            1493174472 bytes
Database Buffers          637534208 bytes
Redo Buffers                4947968 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2],
[2164287937], [4194432], [], [], [], [], [], []
Process ID: 16829
Session ID: 96 Serial number: 3

二.alert日志错误显示

Thu Dec 22 14:37:09 2011
ALTER DATABASE OPEN
LGWR: STARTING ARCH PROCESSES
Thu Dec 22 14:37:09 2011
ARC0 started with pid=20, OS id=16831 
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Dec 22 14:37:10 2011
ARC1 started with pid=21, OS id=16833 
Thu Dec 22 14:37:10 2011
ARC2 started with pid=22, OS id=16835 
Thu Dec 22 14:37:10 2011
ARC3 started with pid=23, OS id=16837 
ARC1: Archival started
ARC2: Archival started
ARC2: Becoming the 'no FAL' ARCH
ARC2: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Thread 1 opened at log sequence 17
  Current log# 2 seq# 17 mem# 0: /opt/oracle/oradata/ora11g/redo02.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829.trc  (incident=36156):
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/ora11g/ora11g/incident/incdir_36156/ora11g_ora_16829_i36156.trc
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829.trc  (incident=36157):
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/ora11g/ora11g/incident/incdir_36157/ora11g_ora_16829_i36157.trc
Dumping diagnostic data in directory=[cdmp_20111222143713], requested by (instance=1, osid=16829), summary=[incident=36156].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Undo initialization errored: err:600 serial:0 start:176607884 end:176611234 diff:3350 (33 seconds)
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829.trc:
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Errors in file /opt/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16829.trc:
ORA-00600: internal error code, arguments: [2662], [2], [2147510731], [2], [2164287937], [4194432], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 16829): terminating the instance due to error 600
Instance terminated by USER, pid = 16829
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (16829) as a result of ORA-1092
Thu Dec 22 14:37:15 2011
ORA-1092 : opitsk aborting process

三.分析日志
ORA-00600[2662]主要参数说明见:ORA-00600 [2662]
这里补充说明:e表示出现异常问题的数据块的DBA,这里的4194432就是一个数据块的DBA

--通过DBA地址查询数据块和文件号
SQL> select dbms_utility.data_block_address_block(4194432) "blick",
  2    dbms_utility.data_block_address_file(4194432) "file" from dual;
 
     blick       file
---------- ----------
       128          1
 
--当前数据库SCN
SQL> select to_char(2147510731,'xxxxxxxxxxx') from dual;
 
TO_CHAR(2147
------------
    800069cb
 
--当前数据块SCN
SQL> select to_char(2164287937,'xxxxxxxxxxx') from dual;
 
TO_CHAR(2164
------------
    810069c1

四.bbed查看相关SCN

[oracle@node1 ora11g]$ bbed
Password: 
BBED-00113: Invalid password. Please rerun utility with the correct password.
 
[oracle@node1 ora11g]$ bbed
Password: 
 
BBED: Release 2.0.0.0.0 - Limited Production on Thu Dec 22 14:49:24 2011
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
************* !!! For Oracle Internal Use only !!! ***************
 
BBED> set filename "/opt/oracle/oradata/ora11g/system01.dbf"
        FILENAME        /opt/oracle/oradata/ora11g/system01.dbf
 
BBED> set block 1
        BLOCK#          1
 
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484     
   struct kcvcpscn, 8 bytes                 @484     
      ub4 kscnbas                           @484      0x800069c8
      ub2 kscnwrp                           @488      0x0002
   ub4 kcvcptim                             @492      0x2dedee96
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500     
      struct kcvcprba, 12 bytes             @500     
         ub4 kcrbaseq                       @500      0x00000011
         ub4 kcrbabno                       @504      0x0000210f
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00
 
BBED> set block 128
        BLOCK#          128
 
BBED> p bas_kcbh
ub4 bas_kcbh                                @8        0x810069c1
 
BBED> p wrp_kcbh
ub2 wrp_kcbh                                @12       0x0002

这里看到的SCN(16进制)和我们在alert日志中看到的有一定的出入原因是在数据库启动的时候，当前SCN增加了，但是因为数据库直接abort，没有写入到数据文件中。导致数据文件头部的SCN比alert中显示的稍微小一点(还有可能，系统当前的scn比system01.dbf的scn大一点)。通过对比数据块和数据文件头部的SCN也可以说明当数据块的SCN>数据块当前SCN导致ORA-00600[2662]

五.bbed修改数据块的SCN

BBED> set offset 8
        OFFSET          8
 
BBED> m /x c8690080
BBED-00215: editing not allowed in BROWSE mode
 
 
BBED> set mode edit
        MODE            Edit
 
BBED> m /x c8690080
BBED-00209: invalid number (c8690080)
--分开修改，曲线救国策略
 
BBED> m /x c869
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /opt/oracle/oradata/ora11g/system01.dbf (0)
 Block: 128              Offsets:    8 to  519           Dba:0x00000000
------------------------------------------------------------------------
 c8690081 02000104 2f8f0000 00000000 00000000 00000000 00000000 06000000 
 2f000000 20100000 00000000 00000000 07000000 81004000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 06000000 00000000 00000000 
 00000040 81004000 07000000 88004000 08000000 10024000 08000000 18024000 
 08000000 20024000 08000000 28024000 08000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 
 <32 bytes per line>
 
BBED> set offset +2
        OFFSET          10
 
BBED> m /x 0080
 File: /opt/oracle/oradata/ora11g/system01.dbf (0)
 Block: 128              Offsets:   10 to  521           Dba:0x00000000
------------------------------------------------------------------------
 00800200 01042f8f 00000000 00000000 00000000 00000000 00000600 00002f00 
 00002010 00000000 00000000 00000700 00008100 40000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000600 00000000 00000000 00000000 
 00408100 40000700 00008800 40000800 00001002 40000800 00001802 40000800 
 00002002 40000800 00002802 40000800 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 
 <32 bytes per line>
 
BBED> p tailchk
ub4 tailchk                                 @8188     0x69c10e01
 
BBED> set offset 8188
        OFFSET          8188
 
BBED> m /x 010ec869
 File: /opt/oracle/oradata/ora11g/system01.dbf (0)
 Block: 128              Offsets: 8188 to 8191           Dba:0x00000000
------------------------------------------------------------------------
 010ec869 
 
 <32 bytes per line>
 
BBED> p tailchk
ub4 tailchk                                 @8188     0x69c80e01
 
BBED> p bas_kcbh
ub4 bas_kcbh                                @8        0x800069c8
 
BBED> sum apply
Check value for File 0, Block 128:
current = 0x8e2f, required = 0x8e2f
 
BBED> exit

六.启动数据库

[oracle@node1 ora11g]$ sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 22 14:58:10 2011
 
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
 
Connected to an idle instance.
 
SQL> startup
ORACLE instance started.
 
Total System Global Area 2137886720 bytes
Fixed Size                  2230072 bytes
Variable Size            1493174472 bytes
Database Buffers          637534208 bytes
Redo Buffers                4947968 bytes
Database mounted.
Database opened.

七.补充说明
一般遇到ORA-00600[2662]都是使用alter session set events ’10015 trace name adjust_scn level N’;方法处理，但是有时候会遇到ORA-01031错误，那就需要请bbed帮忙处理

OS Pid: 30268 executed alter session set events '10051 trace name adjust_scn level 2'
Thu Dec 22 12:04:07 2011
Errors in file /ora101/diag/rdbms/ora11/ora11/trace/ora11_ora_30268.trc:
ORA-01031: insufficient privileges
Thu Dec 22 12:04:43 2011
Errors in file /ora101/diag/rdbms/ora11/ora11/trace/ora11_ora_846.trc:
ORA-01031: insufficient privileges

此条目发表在 Oracle备份恢复, 非常规恢复分类目录，贴了 bbed, ORA-600 2662, ORA-600[2662] 标签。将固定链接加入收藏夹。

《使用bbed解决ORA-00600[2662]》有 1 条评论

惜分飞说：

2011 年 12 月 22 日15:52

通过dba查看file#,block总结

--10进制dba
select dbms_utility.data_block_address_block(4194432) "blick", 
 dbms_utility.data_block_address_file(4194432) "file" from dual;
 
--16进制
set serveroutput on
declare
   p_dba   VARCHAR2 (255) :='0x00800212';
   l_str   VARCHAR2 (255) DEFAULT NULL;
BEGIN
    l_str :=
         'datafile# is:'
      || DBMS_UTILITY.data_block_address_file (TO_NUMBER (LTRIM (p_dba, '0x'),'xxxxxxxx'))
      || chr(10)||'datablock is:'
      || DBMS_UTILITY.data_block_address_block (TO_NUMBER (LTRIM (p_dba, '0x'),'xxxxxxxx'));
   dbms_output.put_line(l_str);
END;

10/16进制互转

--10 to 16
select to_char(2147510731,'xxxxxxxxxxx') from dual;
--16 to 10
select to_number('800069c8','xxxxxxxxxxx') from dual;

四、解决方法三不同解决办法对应的数据库版本

数据库版本：Oracle 11.2.0.1.0

数据库服务器操作系统：Windows server 2008

事故原因：数据库服务器异常断电

影响：导致磁盘损坏，两个控制文件全部损坏，通过DBV工具检查发现，多个数据文件，产生多个坏块；

数据库备份情况：数据库非归档，之前没有任何物理或逻辑备份；

解决方案：手动创建控制文件，启动数据库到mount状态，通过隐含参数_allow_resetlogs_corruption=TRUE跳过一致性检查，强制open数据库，expdp导出全部数据，重建数据库；

问题：在设置隐含参数_allow_resetlogs_corruption=TRUE，尝试resetlogs Open数据库时，报错ORA-00600: internal error code, arguments: [2662],[0],[82522462],[0],[82530638],[12583040],[],[],[],[],[],[]

报错原因：

A data block SCN is ahead of the current SCN.(SCN不一致)

Bug 14351566 ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back；

解决方案：

调整(提升)SCN；

方法一：

数据库在open状态下执行

alter session set events 'IMMEDIATE trace name adjust_scn level n';(不适用本次案例)

方法二：

数据库在mount状态下执行

alter session set events '10015 trace name adjust_scn level n';(只适用11.2.0.2g之前的版本，不适用11g版本数据库)

方法三：

设置隐含参数_minimum_giga_scn=n，提升SCN(【11.2.0.2之前】适用此案例)

方法四：

oradebug工具，提升SCN(【支持11.2.0.2以后版本】)

其中MOS中查询有关ORA-00600[2662]问题相关信息；

ORA-600/ORA-7445/ORA-700 Error Look-up Tool (文档 ID 153788.1)

ORA-600 [2662] "Block SCN is ahead of Current SCN" (文档 ID 28929.1)

Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:

This article discusses the internal error "ORA-600 [2662]", what

it means and possible actions. The information here is only applicable

to the versions listed and is provided only for guidance.

ERROR:

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

VERSIONS:

versions 6.0 to 12.1

DESCRIPTION:

A data block SCN is ahead of the current SCN.

The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN

stored in a UGA variable.

If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]

internal error.

ARGUMENTS:

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCN WRAP

Arg [d] dependent SCN BASE

Arg [e] Where present this is the DBA where the dependent SCN came from.

FUNCTIONALITY:

File and IO buffer management for redo logs

IMPACT:

INSTANCE FAILURE

POSSIBLE PHYSICAL CORRUPTION

SUGGESTIONS:

There are different situations where ORA-600 [2662] can be raised.

It can be raised on startup or during database operation.

If not using Parallel Server, check that 2 instances have not mounted

the same database.

Check for SMON traces and have the alert.log and trace files ready

to send to support.

Check the SCN difference [argument d]-[argument b].

If the SCNs in the error are very close, then try to shutdown and startup

the instance several times.

In some situations, the SCN increment during startup may permit the

database to open. Keep track of the number of times you attempted a

startup.

If the Known Issues section below does not help in terms of identifying

a solution, please submit the trace files and alert.log to Oracle

Support Services for further analysis.

Known Issues:

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button:

The list below is restricted to show only bugs believed to affect version 11.2.0.1.
Other bugs may affect this version but have not been confirmed as being relevant yet.

There is 1 bug listed.

NB	Prob	Bug	Fixed	Description
	III	14351566	11.2.0.3.8, 11.2.0.3.BP21, 11.2.0.4, 12.1.0.1	ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back

· '*' indicates that an alert exists for that issue.

· '+' indicates a particularly notable issue / bug.

· See Note:1944526.1 for details of other symbols used

Bug 14351566 - ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back (文档 ID 14351566.8)

转到底部

修改时间:

2015-9-23

类型:

PATCH

Bug 14351566 ORA-600 [kclchkblk_4] ORA-600 [2662] when doing flash back

This note gives a brief overview of bug 14351566.
The content was last updated on: 21-SEP-2015
Click here for details of each of the sections below.

Affects:

Product (Component) Oracle Server (Rdbms)

Range of versions believed to be affected (Not specified)

Versions confirmed as being affected

11.2.0.3

11.2.0.2

Platforms affected Generic (all / most platforms affected)

Fixed:

The fix for 14351566 is first included in

12.1.0.1 (Base Release)

11.2.0.4 (Server Patch Set)

11.2.0.3.8 Database Patch Set Update

11.2.0.3 Bundle Patch 21 for Exadata Database

11.2.0.3 Patch 25 on Windows Platforms

Interim patches may be available for earlier versions - click here to check.

Symptoms:	Related To:
Internal Error May Occur (ORA-600) Corruption (Physical) ORA-600 [kclchkblk_4] ORA-600 [2662] ORA-600 [kdBlkCheckError]	Flashback Transportable Tablespaces FLASHBACK DATABASE

Description

This fix prevents various ORA-600 internal errors relating to 
the database having the wrong versions of some blocks following 
a "flashback database" operation. Rediscovery Notes Look for all the following:
 - the DB Admin performs a "flashback database" on a database containing
   writable plugged-in datafiles (from transportable tablespaces), then
   some time after that, there are various ORA-600 errors, for example:
    ORA-600 [kclchkblk_4] and/or ORA-600 [2662] involving block types
    "KTFB Bitmapped File Space Header" or "PAGETABLE MANAGED LOB BLOCK"
 - "select file#,foreign_dbid from v$datafile" shows some non-zero
   foreign_dbid's (and BEFORE the "flashback database", these datafiles
   also had a non-zero value for v$datafile.unrecoverable_change#).
 - alter session set events 'immediate trace name controlf level 9'
   MAY show some non-zero Plugin scns (depends on compatibility history)

Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.

References

Bug:14351566 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article

五、oradebug在mount状态下推进SCN

环境：RHEL 6.5(x86-64) + Oracle 11.2.0.4
声明：推进SCN属于非常规恢复范畴，不建议非专业人员操作，否则后果自负。
需求：我这里演示下推进SCN 10W数量级，实际需求推进多少可以根据ORA-600 [2662] [a] [b] [c] [d] [e]具体值来确认。
ARGUMENTS:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
更多详情可参考： ORA-600 [2662] "Block SCN is ahead of Current SCN" (文档 ID 28929.1)
1.查看当前数据库的Current SCN
2.重新启动数据库到mount阶段
3.使用oradebug poke推进SCN
4.补充实际计算推进SCN的方法
1.查看当前数据库的Current SCN
SYS@orcl> select current_scn||'' from v$database;

CURRENT_SCN||''
--------------------------------------------------------------------------------
4563483988
可以看到当前SCN是4563483988，我现在想推进SCN，在10w级别，也就是4563483988标红数字修改为指定值。
2.重新启动数据库到mount阶段
重新启动数据库到mount阶段:
SYS@orcl> shutdown abort
ORACLE instance shut down.
SYS@orcl> startup mount
ORACLE instance started.

Total System Global Area 1235959808 bytes
Fixed Size                  2252784 bytes
Variable Size             788529168 bytes
Database Buffers          436207616 bytes
Redo Buffers                8970240 bytes
Database mounted.
3.使用oradebug poke推进SCN
我这里直接把十万位的"4"改为"9"了，相当于推进了50w左右：
说明：实验发现oradebug poke 推进的SCN值，既可以指定十六进制的0x11008DE74，也可以直接指定十进制的4563983988。
SYS@orcl> oradebug setmypid
Statement processed.
SYS@orcl> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SYS@orcl> select to_char(checkpoint_change#, 'XXXXXXXXXXXXXXXX') from v$database;

TO_CHAR(CHECKPOINT_CHANGE#,'XXXXXX
----------------------------------
110013C41

SYS@orcl> oradebug poke 0x06001AE70 8 4563983988
BEFORE: [06001AE70, 06001AE78) = 00000000 00000000
AFTER: [06001AE70, 06001AE78) = 1008DE74 00000001

SYS@orcl> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 1008DE74 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000

SYS@orcl> alter database open;

Database altered.

SYS@orcl> select current_scn||'' from v$database;

CURRENT_SCN||''
--------------------------------------------------------------------------------
4563984271
可以看到已经成功将SCN推进到4563983988，SCN不断增长，所以这里查到的值略大一些。
4.补充实际计算推进SCN的方法
本文在 2018-12-16 进一步补充说明：
在实际这类工作中，我们实际应该是要认真计算好需要推进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
总结公式：c * power(2,32) + d {+ 可适当加一点，但不要太大！}
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;
最后要说的是，做事情还是多考虑些，在非常规恢复中也能温柔的去推进SCN，高级DBA的价值从细节上体现。

转载自：

http://blog.itpub.net/29785807/viewspace-2104794

https://www.2cto.com/database/201201/117895.html

https://www.linuxidc.com/Linux/2012-01/52851.htm

https://www.cnblogs.com/jyzhao/p/9242352.html

相关阅读:
求子数组最大和
 <转>Android APP字体大小，不随系统的字体大小变化而变化的方法
 模块25 pageobject改造【进阶】
第5阶段直播
 web测试-赠送课程
 模块四 -使用postman发送请求
 模块三使用tcpdump抓包分析tcp三次握手四次挥手
 模块二常见接口协议解析
 20200611_19元素操作
 20200609_18八大元素定位
原文地址：https://www.cnblogs.com/xibuhaohao/p/11239312.html

ORA-00600[2662]问题 汇总