本文主要是介绍Rejected the attempt to advance SCN问题的分析处理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、故障描述
5月8日下午12点30分左右，应用厂家反馈，IP是130.XXXXX(jyfx)的数据库无法连接，检查数据库告警日志，提示内容如下：
Rejected the attempt to advance SCN over limit by 124166 hours worth to 0x15cb.a9a21069, by distributed transaction remote end, remote DB: GZJYFX.
Client info : DB logon user GP_USER, machine jt6, program sqlplus@jt6 (TNS V1-V3), and OS user root
由此得知，该数据库已被41(GZJYFX)感染，接着排查41被(13XXXXX17)WYGDB数据库感染，而此库是被ITFCDB库的SCN感染，如下图所示:
和应用沟通后发现其在11：:47分，在数据库上创建了一个到总部的dblink。和局方沟通后我们针对信息化部当前所有使用的数据库进行排查，经分测数据库11g已经全感染，和局方沟通后我们最初方案是先断掉和B域的dblink。但数据库dblink每个库均有，网状连接。于14:30左右，发现B域CRM也被传染，多个Oracle10g的多个数据库被感染，其中，核心的计费系统因为SCN的感染，数据库异常宕机。
二、故障定位
在接到应用厂家的反馈并找到数据库异常关闭的原因后，我发迅速与局方负责人进行沟通，定位到本次故障的原因：应用人员在沃易管的数据库创建了一个新dblink，该dblink是连接总部的数据库，由此导致该库被感染，因该库与本地多个库也存在dblink连接，导致本地多个库被感染。
三、处理和结果
1.定位故障原因，迅速与局方负责人确定数据库恢复方案；
2.将受影响的数据库按照重要性进行故障排除，在短时间内迅速恢复核心数据库的运行，保证了前端应用的正常运行，将影响减轻到最小化；
3.针对数据库的重要程度，逐一打上最新的扩展补丁（因此次补丁需要扩展服务权限下载，经过局方协调后，花费了一些时间均获取到了需要的补丁）。实施较顺利，最终受感染数据库在补丁实施后均正常运行；
4.根据不同的版本进行了不同的实施方案，贵州联通信息化的数据库10g主要为10.2.0.4.12和10.2.0.5，实施的方案如下:
安装补丁名称 补丁编号 验证补丁是否安装
DATABASE PATCH SET UPDATE 10.2.0.4.12 Patch 14121009 $ORACLE_HOME/OPatch/opatch lsinv | grep 14121009
DATABASE PATCH SET UPDATE?10.2.0.5.171017 and Patch 14121009
[**requires extended support] Patch? 26493118 and?Patch?14121009?[WIP]
**?requires extended support $ORACLE_HOME/OPatch/opatch lsinv | grep 26493118
5.目前，系统已完全恢复，并运行正常。
四、结果跟踪
为预防此次SCN导致的数据库其他异常情况，我方针对本次实施补丁的结果进行实时跟踪，确保数据库的健康运行，根据目前的运行情况来看，数据库运行正常，并无其他异常。
6)总结和建议
本次SCN故障导致多个数据库异常关闭，其中，核心的计费系统也受到影响。我方与局方负责人迅速定位问题，准确地判断问题原因，采取及时的措施防止SCN进一步的污染其他数据库，并在短时间内恢复核心系统的正常运行，事后也对系统的运行情况进行了跟踪。
本次事故较为严重，因此我方建议如下：
1、严格控制权限
一般只授予查询权限，其他权限应实行按需赋权，重要操作必须上报局方进行风险评估。
2、规范数据库使用流程
需要使用数据库的厂家或应用人员，应该将自己的使用要求，涉及到的使用内容上报局方，局方与数据库的维护方对该使用要求，涉及内容进行风险评估，在进行合理的评估后，再将结果反馈给各个使用数据库的厂家或应用人员。
3、梳理dblink，更换取数方式
建议对当前使用的数据库中的dblink进行梳理，将不在使用的dblink进行清理，减少或禁止在针对核心数据库的dblink，更改取数工具，如ETL取数工具。
这篇关于Rejected the attempt to advance SCN问题的分析处理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
