故障简述 XXX第八人民医院HIS数据库7月13日11点左右从原先老服务器切换至新服务器，切换完成之后，数据库版本主机操作系统版本都保持不变。运行20天左右，从8月4日开始，前台操作人员反应业务程序响应出现延迟，此后延迟逐渐增大。8月5日科技工程师远程经过仔细诊断后发现存在大量磁盘读，采取增大SGA数据库内存的方式来减少磁盘读。但调整之后即第二天8月6日上午应用几乎瘫痪无法操作，后台数据库却很空闲。重启数据库业务程序卡顿消失，但过了十几二十分钟之后现象又产生，排除了网络和业务程序自身的故障后，考虑到事故的紧急性采取重启数据库临时解决问题。8月6日下午工程师到达现场仔细排查之后确认是由于连接方式所导致的故障，调整部分参数之后恢复正常，增大SGA后业务程序响应速度明显加快，部分报表查询甚至提升了十几倍。 相关知识点 前端应用连接数据库的方式分为两种：独占模式和共享模式。 独占模式又称专有模式，一个客户端连接对应一个服务器进程，一对一的处理方式。而共享模式则是多个客户端进程对应一个服务器进程，服务器端存在一个进程调度器来管理。 下面具体对共享模式的工作原理做简要分析： 共享模式主要分为6个步骤(如图1-1)： 1.用户发起连接请求 2.监听监测到请求返回调度进程地址，此时用户进程与空闲调度进程直接连接 3.用户发起操作请求(如dml)，调度进程负责把请求放入请求队列中 4.空闲的共享服务进程从请求队列中接过请求，后台处理 5.共享服务进程处理完请求，把结果放入相应队列中 6.对应的调度进程从相应队列中把结果返回给前端用户 图:1-1 问题详细诊断分析过程 本次故障中有两个现象很奇怪： 第一 在后台服务器和数据库很空闲的情况下，前台业务系统却很卡甚至瘫痪 第二 每次重启数据库的十几分钟之内是很正常的，但那之后又很卡 从中我们可以判断，在业务程序正常连接的情况下，问题可能出现在业务程序发出的请求没有及时被后台服务进程处理，而XXX第八人民医院前端业务程序正是采取了共享的连接模式(多个客户端进程对应一个服务器进程)。进一步查看his数据库共享模式下相关参数配置： his数据库配置了初始化5个共享服务进程(最大15个)和15个调度进程，由于数据库已重启具体进程的繁忙程度已经无法确认，我们只能通过dBA_HIST_RESOURCE_LIMIT来查询相关线索。 以上的查询结果我们可以看出max_shared_servers已经达到阈值 从以上的查询结果和awr报告中我们可以大致确定是由于共享服务进程无法及时处理请求队列中的用户请求。这也很好解释了每当数据库重启后，少量请求的情况下共享服务进程还是比较及时的处理用户的请求，随着请求数的最多和大事务的处理(比如报表)，导致共享服务进程达到阈值，无法及时响应，最终导致前台业务卡死。 故障处理： 方法一 调整max_shared_servers 和shared_servers 的值，增加共享服务器的数量 方法二 客户端连接方式改为独占模式 解决办法： 由于C/S架构调整客户端连接方式工作量巨大，所以采取调大max_shared_servers 和shared_servers的值，分别从原来的15和5增大到64和25。 1. 后续观察： 经过8月7日上午高峰期的观察，前端业务程序的响应速度都在正常范围内，部分报表的响应速度甚至提升了10几倍，后续数据库高峰期部分指标如下： 以从高峰期的返回结果来看，服务进程比较空闲的，一直处于空闲等待请求的状态，进程数也一直维持在初始化25，没有上升的趋势。 故障总结 从本次故障分析来看，随着业务量的增大及高峰期报表的执行，默认共享模式下的服务进程数量无法满足当前的需求，共享模式主要针对高并发小事务的OLTP系统而言，在如今内存充足的情况下推荐采用独占模式的连接方式。主要建议如下: 1.报表客户端连接方式改为独占模式 2.调大共享模式服务进程数量 3.优化部分sql减少单个服务检查的处理时间