关于Oracle DB SCN 生成率过高的 预警及处理建议
关于Oracle DB SCN 生成率过高的预警及处理建议
Oracle SCN简介：
Oracle SCN（SystemChange Number），又名系统更改号，是Oracle数据库内部的一个逻辑时间戳，SCN对数据库事件进行排序，由此对事务进行跟踪和查询。举例来说，当某个事务更新了一行数据，数据库将会对这个动作记录一个SCN，同一事务内的其他更改动作将会拥有同一个SCN标识，当这些事务进行提交的时候，Oracle就会相应的记录这些SCN。由于并发量大，如果在同一时刻，数据库内部有多个事务同时进行更新或者提交，那么多个事务将共享一个SCN。随着数据库的运行，SCN将会有序的增长，从理论上讲，SCN总会有用尽的一天。为了避免这一幕的发生，Oracle为SCN设置了一个足够的增长空间，最大值为281万亿，也就是281,474,976,710,656。Oracle将SCN的生成率与时钟频率进行关联，确保SCN不会达到最大值。正常情况下，该SCN最大值能保证数据库运行500年。
问题的影响：
从以上描述可知，Oracle SCN的合理生成频率大约为16K/秒，但Oracle发现，由于某些应用程序的bug，有可能导致数据库生成的SCN超过该合理值的范围。通常情况下，如果该SCN超过合理值范围的话，数据库将会cancel该事务并伴随报错信息。当下一秒，应用再连接的时候，由于SCN的值已经处于合理范围内，业务可以继续执行，对前端应用来看，就好像有个短暂停顿。但是在极端情况下，数据库可能需要需要不得已关闭来保证数据的完整性，所以会引起宕机的情况。
在Oracle数据库里，数据库之间可以通过dblink来进行数据访问，当通过dblink进行业务提交的时候，由于数据库之间存在不同的SCN，因此，为了让事务一致，Oracle将会以两者之间较大的SCN来进行同步，更新dblink两端的数据库SCN。但是，如果源数据库出现SCN生成率过高的问题，随着业务的不断运行，SCN的异常就会通过dblink传染到其他相关的数据库，而dblink使用的频率越大，这种传染的速度也就越快。如果企业内部存在网状的dblink结构，那么这将很容易将SCN的问题扩大到全网，引起大范围的宕机，严重影响整个联通业务的运行。
根据Oracle MOS文档，该问题可能影响的数据库版本是Release: 10.1 to 11.2。
上述SCN问题已经在部分客户发生，对业务造成比较严重的影响。基于此问题的严重性，特发布产品预警及相应处理建议。
问题的检查和确认：
当数据库出现SCN生成率过高问题的时候，在告警日志文件（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
当发现以上告警信息之后，可以参考Oracle MOS文档[ID 1393363.1]，下载并安装Patch:13498243，该patch的安装不需要停止数据库服务，可以在线安装。Patch中包含一个scnhealthcheck.sql脚本，可以直接运行该脚本来检查数据库，根据运行结果来确认是否遇到该问题。Oracle为不同数据库版本提供了不同的patch版本，以下是针对10.2.0.5版本的脚本文件，仅作参考：
运行scnhealthcheck脚本之后，结果可能是以下的一个：
l Result: A - SCNHeadroom is good，数据库处于正常状态；l Result: B - SCNHeadroom is low，数据库SCN生成率过高，需要进一步处理；l Result: C- SCN Headroom is low，数据库SCN生成率过高，需要进一步处理；
问题的处理
由于该SCN事件的触发将极大的危害到整个网络上其它数据库系统的稳定性和持续性，因此，我们强烈建议中国联通对该事件引起重点关注，对内部所有相关版本的数据库系统进行彻底的检查并根据检查结果做出适当的处理措施。操作指引如下：
1. 登陆MOS网站，查询文档[ID1393363.1]，根据不同版本的数据库，下载对应的Patch:134982432. 安装patch，该patch将会在$ORACLE_HOME/rdbms/admin中生成scnheathcheck.sql脚本；3. 对所有版本在10.1到11.2的数据库，分别运行以上sql脚本进行检查；sqlplusSYSTEM/xxxxx
spool /tmp/scncheck_out
@scnhealthcheck
spool off
exit
4. 运行脚本后，output类似以下内容：------------------------------------------------------------
ScnHealthCheck
------------------------------------------------------------
CurrentDate: 2012/01/17 01:01:09
CurrentSCN: 384089
Version: 11.1.0.7.0
------------------------------------------------------------
Result:A - SCN Headroom is good
Applythe latest recommended patches
basedon your maintenance schedule
ANDset _external_scn_rejection_threshold_hours=24 after apply.
内容的输出可能是以下3种之一：
l Result: A - SCN Headroomis good，数据库处于正常状态；但仍建议安装最新psu并设置set_external_scn_rejection_threshold_hours=24；l Result: B - SCNHeadroom is low，数据库SCN生成率过高，建议尽快安装最新psu和patch 13527482，并设置set_external_scn_rejection_threshold_hours=24；l Result: C- SCN Headroom is low，数据库SCN生成率过高，且SCN最大值即将耗尽，必须立即安装最新psu和patch 13527482，并设置set_external_scn_rejection_threshold_hours=24；注：_external_scn_rejection_threshold_hours参数不能设置在11.2.0.x版本中。
patch 13527482包含了2个oracle SCN相关bug的修复，分别是bug 12748240和12780098，在安装最新PSU的基础上，需要再安装该patch来修复。
5. 关于最新PSU的信息，可以参考MOS文档和[ID 1406574.1]，以下简要列出各版本PSU的基本信息，仅供参考：
版本号 数据库PSU号 集群PSU号
11.2.0.3 Patch 13696216
Patch 13696251
11.2.0.2 Patch 13696224
Patch 13696242
11.2.0.1 Patch:12419378
Patch:9655006
11.1.0.7 Patch 13621679
Patch 11724953
10.2.0.5 Patch 13632743
Patch:9952245
10.2.0.4 Patch 12879933
Patch:9294403
10.2.0.3 Patch 13343479
Patch:7117233
6. 若scnheathcheck的结果显示为Result B或者Result C，下载并安装PSU以及patch 13527482，具体安装步骤可参考解压包里的readme文件；7. 设置参数：
Ininit.ora:
# Set threshold on dd/mon/yyyy - See MOS Document1393363.1
_external_scn_rejection_threshold_hours = 24
Inthe spfile:
alter system set"_external_scn_rejection_threshold_hours" = 24
comment='Set threshold on dd/mon/yyyy - SeeMOS Document 1393363.1'
scope=spfile ;
设置参数后，重新启动数据库
以上参数是oracle的隐含参数，一般情况下不建议客户自行修改或调整，根据SCN的情况，oracle建议将该参数值设为24是合适的，若需要对该参数做其他处理，请咨询oracle工程师。
8. 在安装补丁和设置参数后，SCN的生成情况需要再持续观察，scnheathcheck的结果从Result B\C到Result A可能需要几天或者几周的时间。
预警及建议总结：
在某些环境下，程序bug会引起Oracle数据库SCN的异常增长，超出Oracle设定的合理范围，该事件很可能导致宕机，并且由于企业内部存在众多的分布式事务，引起SCN的剧烈增长很容易出现扩散现象，导致更多的数据库宕机。强烈建议相关数据库安装2012年1月以后的PSU以及one-off补丁，设置参数来缓解。同时建议查找应用端分布式事务的并发源头，合理利用并发性等，减少SCN剧烈增长的原因。
谢谢~~~~~~~~ 谢谢~~~~~~~~
页:
[1]