一、问题概述
自助机系统及其它HIS等相关业务程序从3日早上8:20分左右出现使用异常,通过关闭自助机应用服务器及现场工程师KILL相关锁进程后正常。后续数据库工程师通过远程方式接入数据库环境进行问题排查,通过对相关日志等信息的深入分析,找出问题点并提出相应的解决建议,根据相关问题日志及分析处理情况整理汇总此文档。
二、问题时间段的数据库进程信息
- 数据库整体性能数据
节点1:DBTIM指标
节点2:DBTIM指标
节点1:等待时间
节点2:等待时间
- ASH基表中的数据分析
- 问题SQL的分析信息
三、总结与后续处理建议
经沟通了解,问题发生时现象为:上午9点附近将自助机的应用服务器关闭并KILL进程后,系统恢复正常;10点多再次开启自助机应用服务器,程序再次出现问题,关闭应用服务器后正常。下午开启自助机后(关闭了微信程序中自动审核相关的功能,近期此程序有更新),系统正常。
通过对数据库相关日志以可以得出如下信息:
- ASH中异常进程信息的分析:
(1).从ORACLE的ASH性能数据中可以发现,问题时间段自助机的应用服务器(主机名WIN2008R2180409)连接到数据库的进程,有严重的TX行锁(enq: TX - row lock contention)等待,对应的SQL语句是SQL_ID:10y4yb0924b1p,SQL_TEXT: UPDATE GY_BINGRENXX SET NIANLINGDW = :B2 WHERE BINGRENID = :B1 ;通过对阻塞进程的阻塞链及源头分析,可以发现自助机的应用服务器进程之间互相出现了阻塞情况。
(2).通过ORACLE SQLHC分析工具对问题SQL的执行情况分析,可以发现正常情况下SQL执行速度为0.2秒以内;问题时间段(上午8-10点时),SQL执行计划等未发生变化,主要是由于严重的锁问题,导致执行速度长达几百秒(10几分钟),因此业务程序使用异常。
(3).同时与其它时间段的数据库性能报告进行对比,从数据库AWR性能报告数据中其它时间段未发现问题SQL的执行数据,在SQLHC报告中仅抓取到6月3日上午8-10点时有此SQL执行的记录。
(4).从2.1章节的数据库的性能指标趋势图来看,6月3日9点时间段的数据库SQL执行消耗总时间及等待时间等均明显异常,其它时间段处于稳定状态。
- 下一步排查及处理方向
因此,接下来需要及时排查的问题为:
- 问题SQL对应的业务模块及其执行逻辑。
- 问题时间段应用服务器上相关日志进行检查,查看是否出现有主机或程序的性能问题(包括网络层/应用服务器操作系统/应用程序日志等),导致应用服务器处理性能下降。
- 设置相关监控软件程序,对系统运行情况进行监控、预警及事后性能指标监控回溯等。