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的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 发生身份验证错误远程计算机,远程桌面发生
- 下一篇: Tomcat9启动闪退