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

编辑手记：可能很多人在进行备份恢复的时候都遇到过2662的问题，由于日志丢失导致SCN不一致，本文给出最基本的解决方案。温故而知新，愿你的系统安然无恙。文章节选自《循序渐进Oracle》一书。

正文：

在损失了日志，进行基于损坏的恢复时，可能会因为_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

我们看到CHECKPOINT_CHANGE#最终被增进了10Billion.

在Oracle 10g以后，参数_minimum_giga_scn参数可以帮助我们进行SCN推进，以下是一个Oracle 10g数据库2662错误处理的案例：

这里我设置了_minimum_giga_scn参数来推进SCN

_minimum_giga_scn=6

增进这个参数后，启动数据库可以在ALERT文件中看到：

Advancing SCN to 6442450944 according to _minimum_giga_scn

Oracle将SCN增进到 6 * 1024 * 1024 * 1024 = 6442450944.

这里的SCN增进可以精确计算出来的，在这个案例中，通过如下方式就可以计算出来：

SQL> select (1*4294967296+1574541355)/(1024*1024*1024) from dual;

(1*4294967296+1574541355)/(102
------------------------------
5.46640590857714

SCN过度增进的后果？

虽然有多种方式可以增进SCN，但是如果SCN被过度增进，则会带来严重的后果，甚至导致数据库无法提供服务。

SCN又可以在DB Link连接的数据库之间传播同步，SCN跃迁问题因此又被称为『数据库的传染病』，在2012年和2016年，国内都大面积爆发过这个问题。

如果你遇到 ORA-19706: invalid SCN 错误，那么大致就是遇到了这类问题。

详细的文章参考：

SCN过度增进的防范

为了防范SCN的过度增进，Oracle限制了很多增进SCN的方法，包括前面提到的一些，那么如果我们遇到了SCN不一致，还有什么手段去调节呢？

请参考下文：

技术学习，不断前行！

如何加入"云和恩墨大讲堂"微信群

搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。

Oracle公众号推出全新检索功能，只要你记得题目，作者，或者关键字中的任何一个，都可以通过回复获取想要的文章！更多精彩，请关注Oracle公众号获取。