scn,headroom

参考文档：

Master Note: Overview for SCN issues (文档 ID 1503937.1)

System Change Number (SCN), Headroom, Security and Patch Information (文档 ID 1376995.1)

What is System Change Number (SCN)?

The system change number (SCN) is a database ordering primitive. The value of an SCN is the logical point in time at which changes are made to a database. The database uses these SCNs to query and track the changes. For example, if a transaction updates a row, then the database records the SCN at which this update occurred.

There is a very large upper limit to how many SCNs an Oracle Database can use. That limit is currently 281 trillion, or specifically 281,474,976,710,656 (is 2^48) where the Oracle Database should not run out of available ones.

 

What is SCN Headroom?

The difference between the current SCN the database is using, and the "not to exceed" upper limit, is known as the SCN headroom. For almost all Oracle Databases, this headroom is constantly increasing every second. However, Oracle has determined that some software bugs could cause the database to attempt to exceed the current maximum SCN value (or get closer to the limit than was warranted). Generally if the database does try to exceed the current maximum SCN value, the transaction that caused this event would be cancelled by the database, and the application would see an error. The next second the limit increases, so typically the application then continues with a slight hiccough in processing. However, in some very rare cases, the database does need to shutdown to preserve its integrity. In no cases is data lost or corrupted.

--------------------------

The system change number (SCN) is a logical, internal timestamp used by the Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction.

The database uses SCNs to query and track changes. For example, if a transaction updates a row, then the database records the SCN at which this update occurred. Other modifications in this transaction typically have the same SCN. When a transaction commits, the database records an SCN for this commit. Each transaction increments the SCN after commits.

SCNs occur in a monotonically increasing sequence, and there is a very large upper limit to how many SCNs an Oracle Database can use. Starting 12.2.0.1 with compatibility set to 12.2 the limit is 2^63 and for versions below 12.2.0.1 it is 2^48 or 281 trillion SCN values.

Given that there is an upper limit, it is important that any given Oracle Database does not run out of available SCNs. The Oracle Database uses a time based rationing system to ensure that this does not happen.

At any point in time, the Oracle Database calculates a "not to exceed" limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988, multiplied by 16,384 (16K/sec). This is known as the database's current maximum SCN limit. Doing this ensures that Oracle Databases will ration SCNs over time, allowing over 500 years of data processing for any Oracle Database using version 12.2.0.1 or lower. Starting 12.2.0.1 with compatibility set to 12.2, even if the SCNs are consumed at the rate of 96K/sec, the Oracle Database will allow close to 3 million years of data processing.

The difference between the current SCN the database is using, and the "not to exceed" upper limit, is known as the SCN headroom. For almost all Oracle Databases, this headroom is constantly increasing every second.

However, Oracle has determined that some software bugs could cause the database to attempt to exceed the current maximum SCN value (or get closer to the limit than was warranted).

Generally if the database does try to exceed the current maximum SCN value, the transaction that caused this event would be cancelled by the database, and the application would see an error. The next second the limit increases, so typically the application then continues with a slight hiccough in processing. However, in some very rare cases, the database does need to shut down to preserve its integrity. In no cases is data lost or corrupted.

Similar to how clocks are kept synchronized in a computer network, when two databases communicate with each other over a database link, they synchronize their SCNs by picking the largest SCN in use by the two. So in some cases, databases experienced rapidly decreasing SCN headroom not because of a bug in that specific database, but because the bug was active in one or more of the databases that database was connected to. Since the database always rejects SCNs that exceed the current maximum SCN, the provision of being able to run Oracle Databases for more than 500 years was not affected in any of the cases.

All the associated bugs have been fixed in the January 2012 CPU (and associated PSU). The same fixes are also available in the database Patchset Update (PSU) and the latest Oracle Exadata and Windows bundled patches.

Some customers expressed concerns that they may be getting closer to the current maximum SCN limit faster than the data processing they are doing would warrant. In all cases Oracle has found this to be a factor of one of the bugs fixed in the January 2012 CPU - and customers that have applied the fixes find that their SCN headroom starts to increase again, as it should.

To make sure they are not seeing these potential issues in their systems, customers can run a script that checks how far any particular database is away from the current maximum SCN limit for that database. The script is available in Document:1393363.1. The script will alert customers that they may be close to the maximum SCN limit, in which case Oracle recommends they should apply the CPU to the affected database (and interconnected databases) without delay. The expectation is then that these databases will start to grow their available SCN headroom, and for the affected customers that have applied the CPU, this has indeed been the case. The vast majority of customers will find their databases are not even close to the maximum SCN limit, in which case they can apply the CPU (or associated PSU) as part of their normal patching procedures. As always, Oracle recommends that CPUs be applied as soon as possible to address any additional security issues fixed in the CPU.

---------------- 谷歌翻译

scn headroom
数据库使用的当前SCN与“不超过”上限之间的差异称为SCN余量。

在任何时候，Oracle数据库都会计算数据库可以使用的SCN数量的“不超过”限制，根据自1988年以来的秒数，再乘以16,384（16K /秒）。这称为数据库当前的最大SCN限制。这样做可确保Oracle数据库随着时间推移对SCN进行排序，允许使用12.2.0.1或更低版本的任何Oracle数据库进行500多年的数据处理。在兼容性设置为12.2的情况下启动12.2.0.1，即使SCN以96K /秒的速率消耗，Oracle数据库也将允许接近300万年的数据处理。
数据库使用的当前SCN与“不超过”上限之间的差异称为SCN余量。对于几乎所有Oracle数据库而言，这个空间每秒都在不断增加。
但是，Oracle已确定某些软件错误可能导致数据库尝试超过当前的最大SCN值。
通常，如果数据库确实尝试超过当前最大SCN值，则导致此事件的事务将被数据库取消，并且应用程序将看到错误。下一秒限制增加，因此通常应用程序继续处理中的轻微打嗝。但是，在一些非常罕见的情况下，数据库确实需要关闭以保持其完整性。在任何情况下都不会丢失或损坏数据。
类似于计算机网络中时钟保持同步的方式，当两个数据库通过数据库链路相互通信时，它们通过选择两个使用的最大SCN来同步其SCN。
因此，在某些情况下，数据库经历了SCN扩展空间的快速减少，这不是因为该特定数据库中的错误，而是因为该错误在数据库连接到的一个或多个数据库中是活动的。由于数据库总是拒绝超过当前最大SCN的SCN，因此在任何情况下都不会影响能够运行Oracle数据库500多年的规定。
一些客户表示担心他们可能会比他们正在进行的数据处理更快地接近当前的最大SCN限制。在所有情况下，Oracle都发现这是2012年1月CPU中修复的错误之一 - 已经应用修复程序的客户发现他们的SCN空间开始再次增加，应该如此。

为了确保他们没有在系统中看到这些潜在问题，客户可以运行一个脚本来检查任何特定数据库距离该数据库的当前最大SCN限制的距离。该脚本可在文档：1393363.1中找到。该脚本将提醒客户他们可能接近最大SCN限制，在这种情况下，Oracle建议他们应该毫不拖延地将CPU应用于受影响的数据库（以及互连的数据库）。因此，期望这些数据库将开始增加其可用的SCN余量，对于已应用CPU的受影响客户，情况确实如此。绝大多数客户会发现他们的数据库甚至没有接近最大SCN限制，在这种情况下，他们可以将CPU（或相关的PSU）作为其正常修补程序的一部分。与往常一样，Oracle建议尽快应用CPU以解决CPU中修复的任何其他安全问题。

----

从上面的文章中，scn的最大值。

2的48次方 -- 版本低于12.2.0.1
2的63次方 --版本从12.0.1 ，兼容性设置为12.2 

END