適用于：

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

總結

以上是生活随笔為你收集整理的oracle最新scn补丁,Oracle 系统改变号(SCN), Headroom, 安全和补丁信息的全部內容，希望文章能夠幫你解決所遇到的問題。

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