參考文檔：

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
數(shù)據(jù)庫(kù)使用的當(dāng)前SCN與“不超過(guò)”上限之間的差異稱(chēng)為SCN余量。

在任何時(shí)候，Oracle數(shù)據(jù)庫(kù)都會(huì)計(jì)算數(shù)據(jù)庫(kù)可以使用的SCN數(shù)量的“不超過(guò)”限制，根據(jù)自1988年以來(lái)的秒數(shù)，再乘以16,384（16K /秒）。這稱(chēng)為數(shù)據(jù)庫(kù)當(dāng)前的最大SCN限制。這樣做可確保Oracle數(shù)據(jù)庫(kù)隨著時(shí)間推移對(duì)SCN進(jìn)行排序，允許使用12.2.0.1或更低版本的任何Oracle數(shù)據(jù)庫(kù)進(jìn)行500多年的數(shù)據(jù)處理。在兼容性設(shè)置為12.2的情況下啟動(dòng)12.2.0.1，即使SCN以96K /秒的速率消耗，Oracle數(shù)據(jù)庫(kù)也將允許接近300萬(wàn)年的數(shù)據(jù)處理。
數(shù)據(jù)庫(kù)使用的當(dāng)前SCN與“不超過(guò)”上限之間的差異稱(chēng)為SCN余量。對(duì)于幾乎所有Oracle數(shù)據(jù)庫(kù)而言，這個(gè)空間每秒都在不斷增加。
但是，Oracle已確定某些軟件錯(cuò)誤可能導(dǎo)致數(shù)據(jù)庫(kù)嘗試超過(guò)當(dāng)前的最大SCN值。
通常，如果數(shù)據(jù)庫(kù)確實(shí)嘗試超過(guò)當(dāng)前最大SCN值，則導(dǎo)致此事件的事務(wù)將被數(shù)據(jù)庫(kù)取消，并且應(yīng)用程序?qū)⒖吹藉e(cuò)誤。下一秒限制增加，因此通常應(yīng)用程序繼續(xù)處理中的輕微打嗝。但是，在一些非常罕見(jiàn)的情況下，數(shù)據(jù)庫(kù)確實(shí)需要關(guān)閉以保持其完整性。在任何情況下都不會(huì)丟失或損壞數(shù)據(jù)。
類(lèi)似于計(jì)算機(jī)網(wǎng)絡(luò)中時(shí)鐘保持同步的方式，當(dāng)兩個(gè)數(shù)據(jù)庫(kù)通過(guò)數(shù)據(jù)庫(kù)鏈路相互通信時(shí)，它們通過(guò)選擇兩個(gè)使用的最大SCN來(lái)同步其SCN。
因此，在某些情況下，數(shù)據(jù)庫(kù)經(jīng)歷了SCN擴(kuò)展空間的快速減少，這不是因?yàn)樵撎囟〝?shù)據(jù)庫(kù)中的錯(cuò)誤，而是因?yàn)樵撳e(cuò)誤在數(shù)據(jù)庫(kù)連接到的一個(gè)或多個(gè)數(shù)據(jù)庫(kù)中是活動(dòng)的。由于數(shù)據(jù)庫(kù)總是拒絕超過(guò)當(dāng)前最大SCN的SCN，因此在任何情況下都不會(huì)影響能夠運(yùn)行Oracle數(shù)據(jù)庫(kù)500多年的規(guī)定。
一些客戶(hù)表示擔(dān)心他們可能會(huì)比他們正在進(jìn)行的數(shù)據(jù)處理更快地接近當(dāng)前的最大SCN限制。在所有情況下，Oracle都發(fā)現(xiàn)這是2012年1月CPU中修復(fù)的錯(cuò)誤之一 - 已經(jīng)應(yīng)用修復(fù)程序的客戶(hù)發(fā)現(xiàn)他們的SCN空間開(kāi)始再次增加，應(yīng)該如此。

為了確保他們沒(méi)有在系統(tǒng)中看到這些潛在問(wèn)題，客戶(hù)可以運(yùn)行一個(gè)腳本來(lái)檢查任何特定數(shù)據(jù)庫(kù)距離該數(shù)據(jù)庫(kù)的當(dāng)前最大SCN限制的距離。該腳本可在文檔：1393363.1中找到。該腳本將提醒客戶(hù)他們可能接近最大SCN限制，在這種情況下，Oracle建議他們應(yīng)該毫不拖延地將CPU應(yīng)用于受影響的數(shù)據(jù)庫(kù)（以及互連的數(shù)據(jù)庫(kù)）。因此，期望這些數(shù)據(jù)庫(kù)將開(kāi)始增加其可用的SCN余量，對(duì)于已應(yīng)用CPU的受影響客戶(hù)，情況確實(shí)如此。絕大多數(shù)客戶(hù)會(huì)發(fā)現(xiàn)他們的數(shù)據(jù)庫(kù)甚至沒(méi)有接近最大SCN限制，在這種情況下，他們可以將CPU（或相關(guān)的PSU）作為其正常修補(bǔ)程序的一部分。與往常一樣，Oracle建議盡快應(yīng)用CPU以解決CPU中修復(fù)的任何其他安全問(wèn)題。

----

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

2的48次方 -- 版本低于12.2.0.1
2的63次方 --版本從12.0.1 ，兼容性設(shè)置為12.2?

END

總結(jié)

以上是生活随笔為你收集整理的scn,headroom的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。