翻译mos文章 scn headroom ID 1376995.1

          System Change Number (SCN), Headroom, Security and PatchInformation

                                                             (文档 ID 1376995.1)

 

适用与10.1.0.5-11.2.0.3

目的：对scn这个时间戳有个大致的了解，它是怎样规定事务的顺序

详细信息：

Scn是一个逻辑的、内部的时间戳。Scn规定数据库中事务的顺序，这满足了事务的原子性。

数据库使用scn查询和跟踪改变。例如，一个事务更新一行，数据库会记录更新操作时的scn。这个事务中的其他更改拥有相同的scn，当一个事务提交，数据库会记录一个scn，多个事务同时提交可以共享同一个scn。

Scn是一个单调递增的序列，那么它可使用的最大值是多少，目前的最大值是2的48次方

假设scn有一个向上的最大值，使数据库不能使用完所有的可用scn是很重要的事情。Oracle数据库使用一个基于时间约束的体制来保证这种情况不出现。

在任何时候，oracle数据库评估数据库已经使用但未达到最大值的scn值，它是基于过去的时间从现在到1988年的秒数乘以16384的值。这是众所周知的scn的最大值。Oracle数据库通过时间约束scn，保证数据库可以运行500年。

从现在的scn 到scn所谓达到的scn峰值称为headroom，对于大多数oracle数据库来说headroom是每时每刻都在增长的。

某些情况下，oracle软件的某些bug会导致数据库尝试使用scn的当前最大值或者使用

接近被规定的值。

一般说来，如果数据库试着执行最大的scn，这个事务会被数据库取消，应用程序会出现错误。接下来，在应用端就会呈现一些轻微、不间断的停顿情况。因此，在大多是情况下，数据库需要关闭来保证其完整性，绝不丢失数据。

既然oracle通过时间确定scn值，那么两个数据库通过dblink的网络连接时如何确定时间，保持同步?他们通过使用两个数据库中最大的scn来保持同步。实际上就是将两个数据库的scn都改为最大的那个值。有些时候数据库scn快速增长减少scnheadroom不是因为数据库本身的bug，而是由于它所连接的其他数据库的bug造成的。由于数据库总是拒绝数据库规定的最大的scn，在一些情况下保证使用500年是不生效的。

相关的bug在2012年1月的cpu或者psu中被修复，同样的修复存在于oracle的psu和oracle的Exadata物理机以及windows的bundled补丁

一些客户担心他们目前的数据处理的速度产生的scn的增长使其很接近现在scn的最大值。这种情况被认为是一个bug在2012年1月的cpu补丁中已经被修复        ，客户应用这个补丁会发现scnheadroom再次增长。

为了发现系统中的潜在问题，客户可以运行一个脚本，来观察目前的scn离当前scn 最大值的距离。这个脚本会通知客户他们的数据库scn接近最大值，需要应用cpu补丁。

客户应用了相应的cpu，数据库的scn headroom就会开始增长，这是被确定了的。绝大多数客户发现他们的scn没有接近当前最大值，oracle也建议应用相应的cpu。Oracle总是建议客户应该尽快解决任何对于数据库安全的任何问题。