? ? ? ? ? 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總是建議客戶應該盡快解決任何對于數據庫安全的任何問題。

?

?

?

?

總結

以上是生活随笔為你收集整理的翻译mos文章 scn headroom ID 1376995.1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。