数据恢复：ORA-600 2662 错误的SCN增进应对

2017年12月12日

盖国强

1896

在损失了日志，进行基于损坏的恢复时，可能会因为_allow_resetlogs_corruption参数的使用而收到ORA-600 2662的错误报告。

2662 错误是指: A data block SCN is ahead of the current SCN，也就是说数据块的SCN大于了系统的最大SCN，这意味着数据库出现了异常。

介绍一下SCN的基本知识：SCN可以说是Oracle中的很基础，但同时也是很重要的东西，它是一个单向增长的“时钟”，广泛应用于数据库的恢复、事务ACID、一致性读还有分布式事务中。那么除了这些，SCN还有以下一些知识点：

SCN的内部存储方式：在Oracle内部，SCN分为两部分存储，分别称之为scn wrap和scn base。实际上SCN长度为48位，即它其实就是一个48位的整数。只不过可能是由于在早些年通常只能处理32位甚至是16位的数据，所以人为地分成了低32位（scn base）和高16位（scn wrap）。为什么不设计成64位，这个或许是觉得48位已经足够长了并且为了节省两个字节的空间：）。那么SCN这个48位长的整数，最大就是2^48（2的48次方, 281万亿，281474976710656），很大的一个数字了。

从alert文件中，可以看到ora-00600 2662号错误的信息，这其中2662之后的参数分别是SCN Wrap，SCN Base，很明显，后面的SCN值898092653高于了547743994：

遇到这种情况，如果SCN相差不大，通过重启数据库的自动SCN增进可能可以解决这个问题，如果两个SCN差异过大，就需要手工增进SCN来消除这个差异。

增进SCN有三种方法:

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

altersession set events 'IMMEDIATE trace name ADJUST_SCN level x';

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

altersession set events '10015 trace name adjust_scn level x';

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

3.通过_minimum_giga_scn参数设置

该参数与10015事件等类似，1即为将SCN推进到1 billion.

本例由于数据库无法打开，只能使用第二种方法。

注意,由于我使用了10015事件，使得SCN增进到了10 billion，此时数据库可以打开，从alert文件中我们可以看到如下提示:

Sun Dec 11 18:27:04 2005
SMON: enabling cache recovery
Sun Dec 11 18:27:05 2005
Debugging event used to advance scn to 10737418240

SCN被增进到了10 billion,即 10 * (1024*1024*1024) = 10737418240,正好是日志里记录的数量。

我们从数据库内部看一下检查点的增进情况：

SQL> select open_mode from v$database;
OPEN_MODE
----------
READ WRITE

SQL> select file#,CHECKPOINT_CHANGE# from v$datafile;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1          547783998
         2          547783998
         3          547783998

SQL> shutdown immediate;
SQL> startup
SQL> col CHECKPOINT_CHANGE# for 99999999999999999
SQL> select file#,CHECKPOINT_CHANGE# from v$datafile;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1        10737418447
         2        10737418447
         3        10737418447