一、问题概述

自助机系统及其它HIS等相关业务程序从3日早上8:20分左右出现使用异常，通过关闭自助机应用服务器及现场工程师KILL相关锁进程后正常。后续数据库工程师通过远程方式接入数据库环境进行问题排查，通过对相关日志等信息的深入分析，找出问题点并提出相应的解决建议，根据相关问题日志及分析处理情况整理汇总此文档。

二、问题时间段的数据库进程信息

1. 数据库整体性能数据

节点1：DBTIM指标

 

节点2：DBTIM指标

 

节点1：等待时间

 

节点2：等待时间

 

1. ASH基表中的数据分析

 

1. 问题SQL的分析信息

 

三、总结与后续处理建议

经沟通了解，问题发生时现象为：上午9点附近将自助机的应用服务器关闭并KILL进程后，系统恢复正常；10点多再次开启自助机应用服务器，程序再次出现问题，关闭应用服务器后正常。下午开启自助机后(关闭了微信程序中自动审核相关的功能，近期此程序有更新)，系统正常。

通过对数据库相关日志以可以得出如下信息：

1. 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执行消耗总时间及等待时间等均明显异常，其它时间段处于稳定状态。

1. 下一步排查及处理方向

因此，接下来需要及时排查的问题为：

1. 问题SQL对应的业务模块及其执行逻辑。
2. 问题时间段应用服务器上相关日志进行检查，查看是否出现有主机或程序的性能问题(包括网络层/应用服务器操作系统/应用程序日志等)，导致应用服务器处理性能下降。
3. 设置相关监控软件程序，对系统运行情况进行监控、预警及事后性能指标监控回溯等。