關於--Oracle DB SCN 生成率過高--的技術處理指南

前言 
由於oracle db SCN出現生成率過高的問題，我們在2012年4月25號曾向客戶發出《關於Oracle DB SCN 生成率過高的預警及處理建議》。
參考資料
NOTE:1376995.1 - Information on the System Change Number (SCN) and how it is used in the Oracle Database
NOTE:1393363.1 - Installing, Executing and Interpreting output from the "SCNhealthcheck.sql" script
NOTE:1388639.1 - Evidence to collect when reporting "high SCN rate" issues to Oracle Support
NOTE:1393360.1 - ORA-19706 and Related Alert Log Messages
診斷方法
在《關於Oracle DB SCN 生成率過高的預警及處理建議》的文章中，我們已經提出SCN生產率過高的原因。作為oracle db的一種重要預警，我們建議客戶對此作重點關注。在此，我們提出以下幾點處理建議：
1. 在全系統內做SCN生成率的普查，看看各系統的SCN生成情況是否牽涉生成率過高的現象；
2. 發現SCN生成率過高的相關資料庫，根據本指南及時進行修正處理；
3. 形成日常檢查機制，每半月或者每月執行scnhealthcheck.sql，例行檢查SCN的生成率情況；
4. 根據相關資料庫的dblink使用情況，形成dblink跟蹤列表，便於日後檢查SCN狀態。列表內容包括源資料庫名稱、目標資料庫名稱、dblink名稱、dblink用途，甚至包括關聯物件等資訊，如下表：
由於該SCN預警牽涉oracle 9i~11.2的版本，下面提供各版本的處理指引。根據Oracle MOS文件[ID 1393363.1]，
我們建議客戶下載並安裝各版本資料庫對應的Patch:13498243，安裝後執行其中的scnhealthcheck.sql指令碼（建議方式），下面介紹對應版本的指令碼（指令碼可以直接另存為文字檔案，可以在sqlplus中執行），以檢查資料庫SCN健康情況。

以上指令碼的執行結果，可能是以下三種之一：
? Result: A - SCN Headroom is good，資料庫處於正常狀態，建議短期內處理；
? Result: B - SCN Headroom is low，資料庫SCN生成率過高，需要儘快處理；
? Result: C - SCN Headroom is low，資料庫SCN生成率過高，需要緊急處理；

當結果是B或者C的時候，資料庫警告日誌（alert log）檔案中，可能出現以下的一種或者多種警告資訊：
1、Warning - High Database SCN: Current SCN value is 0x0b7b.0008e40b, threshold SCN value is 0x0b75.055dc000
If you have not previously reported this warning on this database, please notify Oracle Support so that additional diagnosis can be performed.
2、Warning: The SCN headroom for this database is only NN days!
3、Warning: The SCN headroom for this database is only N hours!
4、WARNING: This patch can not take full effect until this RAC database has been completely shutdown and restarted again.
Oracle recommends that it is done at the earliest convenience.
5、Rejected the attempt to advance SCN over limit by 9374 hours worth to 0x0c00.00000f66, by distributed transaction remote logon, remote DB: REMDB.XX.ORACLE.COM.
Client info : DB logon user ME, machine yy, program sqlplus@yy (TNS V1-V3), and OS user uuu
6、Rejected the attempt to advance SCN over limit by 9375 hours worth to 0x0c00.000003c6, by distributed transaction logon, remote DB: REMDB.XX.ORACLE.COM.
Client info : DB logon user TC, machine xx, program oracle@xx (TNS V1-V3), and OS user xxx 
7、Rejected the attempt to advance SCN over limit by 9374 hours worth to 0x0c00.00000f66, by XXXXX
Client info : DB logon user TC, machine mmm, program sqlplus@mmm (TNS V1-V3), and OS user uuu
Where XXXXX is a string such as:
 ? PL/SQL RPC (remote)
 ? sql exec with curSCN
 ? sql exec with outSCN

修正方案
處理流程
根據scnhealthcheck.sql指令碼和alert log的檢查情況，確認資料庫是否遇到SCN生產率過高的情況。以下為問題的處理流程：
1. 執行scnhealthcheck.sql指令碼
若執行結果為A，則形成日常管理機制，每半月或者每月執行一次該指令碼，保持跟蹤，並計劃實施修正方案（根據版本，選擇下述四種方案），短期內完成。
若執行結果為B或者C,則根據本指南儘快實施修正方案（根據版本，選擇下述四種方案）。
2. 修正方案實施完成後，保持跟蹤SCN的檢查情況，若一個月後SCN的檢查結果還沒恢復到結果A，則建議撥打聯通VIP服務熱線400-818-9989進行諮詢，或者登陸support.oracle.com網站，提交SR請求。根據SR的回覆進行修復動作，一直到SCN指令碼執行結果恢復正常狀態為止。
3. 在所有資料庫的SCN問題修正後，定期執行檢查指令碼進行跟蹤，建議每半月或者每月執行一次。
根據每個牽涉SCN預警的資料庫版本，我們建議進行相應的修正方案如下：
注意：本指南建議安裝的補丁，必須同時安裝於所有dblink相關操作的資料庫上。

方案一：安裝PSU/CPU補丁修復方案
本方案主要針對以下資料庫版本：
Oracle 10.2.0.5
Oracle 11.1.0.7
Oracle 11.2.0.2
Oracle 11.2.0.3
針對上述版本的資料庫，oracle建議給資料庫安裝2012年4月釋出的PSU，並在安裝該PSU的基礎上，安裝補丁13916709。如果是叢集架構，同時給叢集軟體最新安裝PSU。
? 10.2.0.5  資料庫
對於版本為10.2.0.5的資料庫， 建議安裝2012年4月釋出的PSU 13632743，並在安裝PSU 13632743的基礎上，安裝補丁13916709。引數_external_scn_rejection_threshold_hours在2012年4月（包含2012年4月）以後釋出的PSU/CPU中已經定義預設值為24，所以安裝最新PSU補丁以後，不需要再設該引數。如果是叢集架構，同時給叢集軟體安裝PSU 9952245。
? 11.1.0.7  資料庫
對於版本為11.1.0.7的資料庫，建議安裝2012年4月釋出的PSU 13621679，並在安裝PSU 13621679的基礎上，安裝補丁13916709。引數_external_SCN_rejection_threshold_hours在2012年4月（包含2012年4月）以後釋出的PSU/CPU中已經定義預設值為24，所以安裝最新PSU補丁以後，不需要再設該引數。如果是叢集架構，同時給叢集軟體安裝PSU 11724953。
? 11.2.0.2  資料庫
對於版本為11.2.0.2的資料庫，建議安裝2012年4月釋出的PSU 13696224，並在安裝PSU 13696224的基礎上，安裝補丁13916709。如果是叢集架構，同時給叢集軟體安裝PSU 13696242。
? 11.2.0.3  資料庫
對於版本為11.2.0.3的資料庫，建議安裝2012年4月釋出的PSU 13696216，並在安裝PSU 3696216的基礎上，安裝補丁13916709。如果是叢集架構，同時給叢集軟體安裝PSU 13696251。

方案二：10gR2無補丁的資料庫版本解決方案
本方案主要針對以下資料庫版本：
Oracle 10.2.0.1
Oracle 10.2.0.2
Oracle 10.2.0.3
針對上述版本的資料庫， oracle提供兩種修正方式：
? 方式一：資料庫版本升級修復
採用前提：資料庫系統已經有升級計劃，或是升級資料庫版本從管理、應用、時間上都比較適合。
方式建議程度：高
處理方式：將資料庫升級到11.2.0.3的版本，安裝2012年4月釋出的PSU 13696216，並在安裝PSU 13696216的基礎上，安裝補丁13916709。如果是叢集架構，同時給叢集軟體安裝PSU 13696251。
? 方式二：補丁集升級修復
採用前提：資料庫SCN問題急需解決，但升級資料庫版本從管理、業務應用、時間上都不適合。
方式建議程度：中
處理方式：安裝10gR2版本資料庫最近補丁集10.2.0.5，安裝2012年4月釋出的PSU 13632743，並在安裝PSU 13632743的基礎上，安裝補丁13916709。如果是叢集架構，同時給叢集軟體安裝PSU 9952245。
修復後續建議：請將10.2.0.5資料庫版本升級到11.2.0.3或以後，並參考方案一方法修復SCN異常。


方案三：10.2.0.4版本解決方案
本方案針對資料庫版本是Oracle 10.2.0.4。oracle為此提供兩種修正方式：
? 方式一：緊急修復方案
採用前提：資料庫SCN問題急需解決，但升級資料庫版本從管理、業務應用、時間上都不適合。
方式建議程度：中
處理方式：保持資料庫版本不變，安裝2012年4月釋出的PSU 12879933。在安裝12879933之前，必須先安裝9352164，這是安裝10.2.0.4.4之後PSU的前提條件。如果是叢集架構，同時給叢集軟體安裝PSU 9294403。引數_external_SCN_rejection_threshold_hours在2012年4月（包含2012年4月）以後釋出的PSU/CPU中已經定義預設值為24，所以安裝最新PSU補丁以後，不需要再設該引數。
修復後續建議：請將10.2.0.4資料庫版本升級到11.2.0.3或以後，並參考方案一方法修復SCN異常。

? 方式二：補丁集升級修復方案
採用前提：資料庫SCN問題急需解決，安裝最近補丁集，從管理、應用、時間上都比較適合，但資料庫版本升級計劃不能在短期內完成。
方式建議程度：中

處理方式：將資料庫升級到10.2.0.5的版本，安裝2012年4月釋出的PSU 13632743，並在安裝PSU 13632743的基礎上，安裝補丁13916709。如果是叢集架構，同時給叢集軟體安裝PSU 9952245。
修復後續建議：請將10.2.0.5資料庫版本升級到11.2.0.3或以後，並參考方案一修復SCN異常。


方案四： 資料庫版本升級解決方案
本方案主要針對以下資料庫版本：
Oracle 9.2.0.1～9.2.0.8
Oracle 10.1.0.3～10.1.0.5
Oracle 11.1.0.6
Oracle 11.2.0.1
針對上述版本的資料庫，oracle建議將資料庫升級到11.2.0.3的版本，安裝2012年4月釋出的PSU 13696216，同時安裝one-off補丁13916709。如果是叢集架構，同時給叢集軟體安裝PSU 13696251。升級到11.2.0.3版本後，也可以根據方案二進行SCN問題修復。
對於版本為10.1.0.5的資料庫，oracle提供另外一個方案(應急方式，不是長久解決之道)：安裝2012年1月釋出的CPU補丁13343482（該補丁為10.1版本的最後cpu補丁，oracle不再為此版本提供新補丁計劃），並在安裝該CPU後設引數_external_scn_rejection_threshold_hours=24。


重要建議
1. 如果資料庫版本早於11.2.0.1，請計劃考慮升級到最新版本。
2. 最佳化DB_link使用與管理:
3 嚴格控制dblink的建立
4 儘量減少dblink的使用
5 建議dblink只用於資料查詢



常見疑問與解答
在未安裝SCN相關補丁的資料庫上會出現什麼問題？出現問題後如何處理？
答：未安裝SCN問題相關補丁的資料庫，可能會出現資料庫不能正常服務或當機的故障，一旦故障出現，資料庫啟動會不正常，資料庫啟動後，也不能正常工作。問題出現，一定要確保得到及時處理。所以我們建議提前對系統時行診斷，並在資料庫上安裝最新PSU/CPU補丁，做到未雨綢繆。


"scnhealthcheck.sql"指令碼可以執行在9.2.0.8以前的資料庫嗎？
答：不行。無9.2.0.8版本前對應的檢查補丁，也就是說不能執行這個指令碼在9.2.0.8以前版本的資料庫上。


檢查指令碼判斷依據準確嗎？
答：準確，指令碼的檢查演算法與Oracle資料庫內部檢查程式碼演算法一致。


如何監控SCN增長異常？
答：將“scnhealthcheck.sql”使用crontab或是其它自動管理化監控軟體平臺中，定期執行。一般半月執行一次就可以。


如何確認SCN相關補丁已經安裝？
答：可以使用非SYS/SYSDBA使用者登入到資料庫，執行如下命令：
alter session set  "_external_scn_rejection_threshold_hours"=1;
透過報錯可知：
? ORA-02248: invalide option for ALTER SESSION
修正SCN問題補丁沒有安裝。
? ORA-02095:specified initialization parameter cannot be modified.
修正SCN問題補丁已經安裝。
同時，我們可以知道，只有安裝補丁才會有“_external_scn_rejection_threshold_hours”引數存在。


安裝SCN問題的相關補丁後，SCN不會再增長了嗎？
答：不是，還會增長，資料庫中的資料變化，引發的SCN增長本身是正常的，SCN本身最大極限值很大，按每秒16K增長速度，估計可以使用500年左右。SCN問題，本身是說由於多種原因導致SCN過快增長，這種增長是一種異常（可能遠超過16K/s），SCN補丁是解決這種異常增長的主要方法。但是透過db_link多資料庫連線互操作引發的“乒乓效應”/“滾雪球效應”無法透過補丁完全解決。