SCN Headroom警報

項目巡檢時，發現了有關于SCN的headroom警報,這是我第一次在項目中遇到SCN相關的警報，遂記錄下來解決過程以及SCN相關知識。

SCN介紹

concept文檔中是這么介紹：
A system change number (SCN) is a logical, internal timestamp used by Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction. >
Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can stop.

SCN是Oracle數據庫的邏輯時間戳，用來保證Oracle中的事物和數據一致性。SCN在數據庫中是一個單一的不斷的隨著數據庫一致性狀態的改變而自增的序列。

查看SCN:
SELECT current_scn scn FROM v$database;

SCN兩個極限

SCN會有兩個極限，一個是hard limit,一個是soft limit,即headroom。

• Hard Limit

SCNs occur in a monotonically increasing sequence, and 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) 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.

最大值281萬億，oracle確保在不出現bug的時候不會達到，理論上最大值需要一兩百年才能達到，當到這個最大值時，數據庫將再也啟動不了，只能重新建庫解決。

• Headroom

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. 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.
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.

計算方法（sysdate-1988年的秒數）*（16*1024）。oracle認為合理的情況下每秒鐘SCN最大的增長數為16384。

SCN警報信息

SCN的警報信息會出現在告警日志中，通過相關MOS提供的腳本也能檢查出來。
當告警日志中出現了以下的信息，即代表出現了Headroom問題了。

• Warning信息
  

  Warning信息

• SCN跳躍信息
  

  SCN跳躍信息
  
  由圖中信息可知當前數據庫SCN存在跳躍信息，向前跳躍7862分鐘，到了0x0e1332b78159(轉化為十進制是 15475618054489)，遠端機器HAJC，登錄用戶EPOINTOA8_HA，主機名、程序等信息。

• scnhealthcheck.sql腳本

The "scnhealthcheck.sql" script can be downloaded here: Patch:13498243.
If you install the patch then it will create "scnhealthcheck.sql" in the $ORACLE_HOME/rdbms/admin directory.
Alternatively you can use the script directly from the unzipped patch without actually installing it in your $ORACLE_HOME.

需要打補丁[Patch:13498243](https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=1393363.1&patchId=13498243)，腳本自動創建到$ORACLE_HOME/rdbms/admin下。

• SQL語句檢查

  select version,
     date_time,
     dbms_flashback.get_system_change_number current_scn,
     indicator
  from (select version,
             to_char(SYSDATE, 'YYYY/MM/DD HH24:MI:SS') DATE_TIME,
             ((((((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)
  

  使用以上SQL檢查，根據INDICATOR列的值來判定Headroom還可以使用多久，這應該是一個趨于穩定的值，當小于10天的時候應該提高注意，系統可能出現問題，而這個項目上的INDICATOR值只有6.1。

解決辦法

在上一章警報信息中的SCN跳躍信息欄中已經解析了日志中的一些信息，可以用來解決問題。
我們下面應該找到HAJC這個庫和POINTOA8_HA用戶，既然是遠端信息連接到這臺HAOA數據庫上，那肯定是通過Dblink的方式。
所以，在HAJC庫中查找對應的Dblink信息，信息匹配，確實存在Dblink。

Dblink有可能會導致SCN爆炸增長，當兩個數據庫通過Dblink相互訪問時，他們會選用兩者中當前SCN最大的一個來同步SCN，譬如說數據庫A 的SCN 是10000，而數據庫B是20000，當2者發生DBLINK聯系時，將會用最大的SCN (20000)來同步，數據庫A的SCN將jump跳躍到20000。在一些環境中，往往不是本地數據庫觸發了SCN快速增長的bug，而是眾多數據庫中的某一個存在活躍的SCN BUG，而其他數據庫與該問題數據庫發生DBLINK聯系后，就會因為SCN同步而經歷 SCN headroom的的極速減少；異常高的SCN會通過DBLINK傳播給正常的數據庫，這種傳播往往呈爆炸式發展。

• 打2012年1月后發布的CPU或PSU補丁
  補丁增加了_external_scn_rejection_threshold_hours參數，通常設置該參數為24小時

• 源頭解決
  將對應的Dblink源頭找到并禁用

對于此項目的情況，分析Dblink的使用功能是做數據同步，和相關負責人討論后可以用數據交換平臺替代Dblink，于是決定禁用此Dblink，來解決問題。

看下刪掉Dblink同步后的效果。

5月27日檢查Headroom只剩下6.1天，5月31日drop掉此Dblink,6月1日檢查，Headroom增加到11天，接下來還會繼續釋放，SCN恢復使用正常，趨于穩定。