一、故障描述
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取数工具。