為什么要檢查SCN Headroom

Oracle對于SCN的增長有個小小的限制，即當前HeadRoom，注意，用了 當前 兩個字，表示這個HeadRoom是實時計算出來的，計算方式為：1988年距當前時間的秒數 * 16k，所以HeadRoom是按照秒，每秒16K的漲幅在增加，每個時刻，Oracle會將SCN與HeadRoom進行比較，如果事務SCN超過HeadRoom，當前事務可能失敗，但隨著時間的流逝，HeadRoom也在不斷增長，只要你的后續SCN增長不觸碰到HeadRoom，就沒問題。另外觸碰到HeadRoom與用盡SCN是兩碼事，按照16K/秒的速度，SCN需要500年才能用盡。Oracle對于SCN的增長有個小小的限制，即當前HeadRoom，注意，用了 當前 兩個字，表示這個HeadRoom是實時計算出來的，計算方式為：1988年距當前時間的秒數 * 16k，所以HeadRoom是按照秒，每秒16K的漲幅在增加，每個時刻，Oracle會將SCN與HeadRoom進行比較，如果事務SCN超過HeadRoom，當前事務可能失敗，但隨著時間的流逝，HeadRoom也在不斷增長，只要你的后續SCN增長不觸碰到HeadRoom，就沒問題。另外觸碰到HeadRoom與用盡SCN是兩碼事，按照16K/秒的速度，SCN需要500年才能用盡。

那么哪些原因會導致數據庫觸碰到HeadRoom呢？

1.Oracle Bug，導致自身SCN異常增長
2.DBlink傳染
對于1，好理解，Bug出來，豬飛上天都不足為奇；對于2，就是受限于Oracle DBLink的工作機制，每一次跨庫查詢，都算一個分布式事務，他們需要一個統一的SCN，兩個庫的SCN不一樣，就同步成一樣。如果一個SCN異常增長的庫放在你的生產環境里，又有DBlink查詢的話，這片數據庫的SCN增長基本都會異常。所以當DBLink觸發的SCN增長超過限定值時，對端數據庫可能會拒絕這次事務。

在出現異常時，尤其是當使用DB Link跨數據庫查詢時，SCN會被同步，數據庫之間可以通過dblink來進行數據訪問，當通過dblink進行業務提交的時候，由于數據庫之間存在不同的SCN，因此，為了讓事務一致，Oracle將會以兩者之間較大的SCN來進行同步，更新dblink兩端的數據庫SCN。但是，如果源數據庫出現SCN生成率過高的問題，隨著業務的不斷運行，SCN的異常就會通過dblink傳染到其他相關的數據庫，而dblink使用的頻率越大，這種傳染的速度也就越快。如果企業內部存在網狀的dblink結構，那么這將很容易將SCN的問題擴大到全網，極端情況下會引起大范圍的宕機。

巡檢語句
SELECT
((((((TO_NUMBER(TO_CHAR(SYSDATE, ‘YYYY’)) - 1988) * 12 * 31 * 24 * 60 * 60) +
((TO_NUMBER(TO_CHAR(SYSDATE, ‘MM’)) - 1) * 31 * 24 * 60 * 60) +
(((TO_NUMBER(TO_CHAR(SYSDATE, ‘DD’)) - 1)) * 24 * 60 * 60) +
(TO_NUMBER(TO_CHAR(SYSDATE, ‘HH24’)) * 60 * 60) +
(TO_NUMBER(TO_CHAR(SYSDATE, ‘MI’)) * 60) +
(TO_NUMBER(TO_CHAR(SYSDATE, ‘SS’)))) * (16 * 1024)) -DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER) /(16 * 1024 * 60 * 60 * 24)) INDICATOR
FROM V$INSTANCE;

語句分析
前面是計算當前時間到1988年1月1日的時間值（換算成秒），16*1024是每秒產生的SCN,DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER是當前的SCN，兩者相減得出剩余可用SCN數，最后得出結果為SCN可用天數。

總結

以上是生活随笔為你收集整理的SCN Headroom的全部內容，希望文章能夠幫你解決所遇到的問題。

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