APP下载

一次数据库实例随机性宕机

2020-09-19

网络安全和信息化 2020年9期
关键词:随机性开发人员实例

编者按: 笔者单位所使用的Oracle 数据库近期出现连接卡顿的问题,会不定时出现宕机。笔者对此进行排查后发现是前端应用服务器修改了部分软件功能所致。

笔者单位生产系统使用的Oracle 11G RAC数据库自上线运行有近3年,一直稳定良好,近期在日常监控和用户反映均发现对该RAC 数据库的连接某些时候会出现卡顿。

先介绍一下笔者单位的系统,如图1 所示。软件环境如下:

单位所使用的操作系统为AIX 7.1,数据库系统为Oracle 11.2.0.4 RAC。数据库集群Grid的补丁已安装列表:

22 502505;ACFS Patch Set Update:11.2.0.4.160419 (22502505)

23 054319;OCW Patch Set Update:11.2.0.4.160719 (23054319)

24 732075;Database Patch Set Update:11.2.0.4.170418 (24732075)

Oracle 数据库补丁已安装列表:

图1 单位系统简图

23 054319;OCW Patch Set Update:11.2.0.4.160719 (23054319)

24 732075;Database Patch Set Update:11.2.0.4.170418 (24732075)

故障分析及排查

当出现该问题后,数据库管理员登录数据库看到该RAC 数据库2 号实例(Instance 2)已经处于关闭状态。该问题具有随机性,不定时出现宕机情况,严重影响系统的正常运行。通过追踪查看数据库系统产生的警告日志文件Alert.log,笔者发现数据库在实例停止报错中出现了ORA-7445和ORA-600 错误。

ORA-07445 出现异常错误:

核心转储

[opiaba()+772][SIGSEGV] [ADDR:0xF0001078D9B0F1A][PC:0x1093DBDE4][Address not mapped to object] []

Incident details in:/haclu/ app/oracle/diag/rdbms/orcl/incident/incdir_820678/orcl_ora_50921614_i820678.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Mon Mar 09 10:16:11 2020

Sweep [inc][820678]:completed

Sweep [inc2][820678]:completed

Mon Mar 09 10:16:11 2020

Dumping diagnostic data in directory=[c dmp_20200309101611],requested by (instance=2,osid=50921614),summary=[incident=820678].

Mon Mar 09 10:16:18 2020

Errors in file/haclu/app/oracle/diag/rdbms/orcl/trace/orcl_pmon_37225990.trc(incident=819342):

ORA-00600 出现异常错误:

ORA-00600:internal error code,arguments:[17147],[0x7000107586604 D8],[],[],[],[],[],[],[],[],[],[]

Incident details in:/haclu/app/oracle/diag/rdbms/orcl/incident/incdir_819342/o rcl_pmon_37225990_i819342.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file/haclu/app/oracle/diag/rdbms/orcl/trace/orcl_pmon_37225990.trc:

ORA-00600:internal error code,arguments:[17147],[0x7000107586604 D8],[],[],[],[], [],[],[],[],[],[]

PMON (ospid :37225990):terminating the instance due to error 472

Mon Mar 09 10:16:21 2020

System state dump requested by (instance=2,osid=37225990 (PMON)),summary=[abnormal instance termination].

System State dumped to trace file/haclu/app/oracle/diag/rdbms/orcl/trace/jwya2_diag_42075868_20200309101621.trc

Instance terminated by PMON,pid=37225990

因为问题发生具有随机性,加之该故障原因是ORA-7445 和ORA-600 错误,这两种类型错误多为数据库自身产品BUG 等缺陷造成的系统级隐患。我们暂时只能通过重启实例来让系统进行恢复,不至于影响生产现场使用,同时,继续对故障进行跟踪。

随着数据库实例宕机次数的累计增加,通过报错日志以及数据库产生的跟踪文件,我们进一步查看/haclu/app/oracle/diag/rdbms/orcl/incident/incdir_820678/orcl_ora_50921614_i820678.trc文件内容,发现存在大量的删除语句,如图2 所示。

经过和Oracle 官方技术工程师通信协商后发现该SQL 语句中的绑定变量超过了80 000 个,系统资源耗尽,造成数据库实例2(Instance 2)关闭,并且该系统BUG 在Oracle 11.2.0.4 版本下已经无官方补丁支持。

故障解决

经过一段时间的观察和分析,我们逐步搞清楚了引发数据库实例2(Instance 2)随机性宕机的真正原因。

图2 文件内容存在大量的删除语句

由于应用系统前端应用服务器近期修改了部分软件功能,该功能会对用户数据库中的某表进行大量的插入或删除操作。我们特地找到了软件功能开发人员进行了沟通,发现如下一次性批量逐条数据插入代码:“qjsqDao.insertAttendancePerson(list_dyxx);”。当用户使用该功能后,系统会产生插入或删除操作。期间应用开发人员使用了数据库的绑定变量机制,该表需要插入的记录数实际为9 万多条,而数据库绑定变量要求最大不能超过65 535,当数据一次性批量逐条插入或删除时,生成的绑定变量数大于65 535上限。又因为该应用服务器连接数据库监听使用的是实例2(Instance 2)本地监听,而非RAC的SCAN 监听,导致数据库实例2(Instance 2)的数据监控和管理进程(PMON)错误,因此引起数据库实例2(Instance 2)关闭。

针对这一问题,我们经过和开发人员协商和测试,将对该表的一次性逐条增删操作改为批量提交处理方式,避免出现绑定变量数越界问题。核心代码如下:

经修改上线后,数据实例宕机问题彻底解决。

结语

此次生产数据库宕机故障看起来似乎是数据库问题,但其本质问题是因为应用程序使用绑定变量越界而导致的资源耗尽。在问题的排查过程中,追踪和信息收集对问题的处理和排查起到了非常重要的作用,信息系统的问题诊断也需要丰富的经验积累。有时候“脚疼”的问题真不一定出现在脚上,需要系统性对现象进行梳理和分析,才能更好的使问题本质浮出水面。

猜你喜欢

随机性开发人员实例
Semtech发布LoRa Basics 以加速物联网应用
认真打造小学数学的优美课堂
浅析电网规划中的模糊可靠性评估方法
后悔了?教你隐藏开发人员选项
对“德育内容”渗透“随机性”的思考
完形填空Ⅱ
完形填空Ⅰ
三星SMI扩展Java论坛 开发人员可用母语