前言
由于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多数据库连接互操作引发的“乒乓效应”/“滚雪球效应”无法通过补丁完全解决。
由于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多数据库连接互操作引发的“乒乓效应”/“滚雪球效应”无法通过补丁完全解决。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23732248/viewspace-1735076/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/23732248/viewspace-1735076/
670
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
