适用于：

Oracle Database – Enterprise Edition – 版本 10.1.0.5到 11.2.0.3 [Release 10.1 to 11.2]

本文信息适用于任何平台。

目标

本文高度概括了一个逻辑时间戳，即系统改变号(SCN)，是如何用于排序数据库事件，以及这个逻辑时间戳的进展是如何被限制的。

范围

本文旨在用于Oracle DBA。

详细信息

系统改变号(SCN)是由Oracle数据库使用的一个逻辑的，内部的时间戳。SCN排序数据库内发生的事件，这是为了满足事务的ACID属性。

数据库使用SCN来查询和跟踪更改。例如，如果事务更新行，则数据库记录发生此更新处的SCN。在该事务中的其他修改通常具有相同的SCN。当一个事务提交时，数据库记录该提交的SCN。在同一时间提交的多个事务可以共享同一SCN。

SCN出现在单调递增序列中，且Oracle数据库可使用SCN的数有一个极大的上限–该限制目前为281万亿，具体是281,474,976,710,656(即2 ^ 48)SCN值。

鉴于有上限，任何给定的Oracle数据库不用完可用的SCN是很重要的。Oracle数据库使用基于时间的配给机制以确保这种情况不会发生。

在任何时间点，Oracle数据库计算数据库能使用的“不超过”限制的SCN数，基于自1988年以来经过的秒数，再乘以16,384。这被称为数据库当前最大SCN限制。这样做可以确保Oracle数据库将在各时间内配给SCN，使任何​​Oracle数据库能进行500多年的数据处理。

当前数据库使用的SCN和“不超过”上限的SCN之差，被称为SCN headroom。对于几乎所有Oracle数据库，这个headroom余量每秒在不断增加。

但是，Oracle现在确认了一些软件bug可能导致数据库试图超过目前最大的SCN值(或更接近保证的限制)。

一般来说，如果数据库尝试超过目前最大的SCN值，导致此事件的事务将被数据库取消，且应用程序会出现一个错误。下一秒限制增加，因此通常应用略微停顿就继续进行。然而，在一些非常罕见的情况下，数据库是需要被关闭来保护其完整性。在任何情况下，数据都不会丢失或损坏。

与时钟在计算机网络中如何保持同步类似，当两个数据库通过数据库链接相互通信时，它们选择在使用在中的最大SCN来同步它们的SCN。因此，在一些情况下，数据库经历快速下降的SCN headroom不是因为特定数据库中的bug，而是因为bug在数据库连接到的一个或多个数据库中是活跃的。由于数据库始终拒绝超过当前最高SCN的SCN，Oracle数据库能够运行500多年的规则在任何情况下不会受到影响。

所有相关的bug已经在2012年1月CPU(和相关PSU)中被修正。在数据库补丁集更新(PSU)和最新的Oracle Exadata和Windows捆绑补丁中也提供相同的修正。

一些客户担忧，他们可能会越来越接近当前最大SCN限制，比他们在做的数据处理的保证速度更快。在所有的情况下，Oracle发现这是由于2012年1月CPU中修正的bug之一–而应用了修正的客户发现，他们的SCN headroom开始再次如预期增加。

为了确保他们的系统中不再出现这些潜在问题，客户可以运行一个脚本来检查任何特定数据库离目前最高限额的SCN有多远。Document:1393363.1中提供该脚本。该脚本将提醒客户他们可能接近最大极限SCN，在这种情况下，Oracle建议他们应该立即应用CPU到受影响的数据库(和相互连接的数据库)。预期是这些数据库的可用SCN headroom将开始增加，而对于已应用CPU的受影响的客户来说，确实如此。绝大多数客户会发现他们的数据库甚至不再接近最大极限SCN，在这种情况下，他们可以应用CPU(或相关PSU)作为其正常补丁程序的一部分。Oracle始终建议应当尽快应用CPU来解决在CPU中修正的任何其他安全问题。

长期来看，Oracle将会提供281万亿的上限(即2 ^ 48)到更大数量。

参考

NOTE:1393363.1 – Installing, Executing and Interpreting output from the “scnhealthcheck.sql” script

NOTE:12371955.8 – Bug 12371955 – Hot Backup can cause increased SCN growth rate leading to ORA-600 [2252] errors