Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >故障树分析法在数据库诊断分析中的应用

故障树分析法在数据库诊断分析中的应用

作者头像
数据和云
发布于 2018-03-07 03:20:07
发布于 2018-03-07 03:20:07
2.2K0
举报
文章被收录于专栏:数据和云数据和云

编辑手记:将知识转化为能力,除了需要经验的积累和时间的磨砺,更重要的是正确的方法和思维模式,学会应用知识才是真正的能力。本文试图通过方法的讨论使大家能够形成一个稳定的解决问题的思路和方法,按照这个思路和方法将我们所学的知识整理武装起来,这样在面对问题时就能够快速地找到一条发现和解决问题之路。

故障树分析法

故障树分析法(Fault Tree Analysis,FTA)是在对系统的可靠性进行分析时最常用的方法之一。FTA方法是指在系统设计或改进过程中,通过对可能造成系统故障的各种因素(包括硬件、软件、环境、人为因素等)进行分析,画出逻辑框图(即故障树),从而确定系统故障原因的各种可能组合方式及其发生概率,并以此计算系统的故障概率,采取相应的措施,以提高系统可靠性的一种设计分析方法和评估方法。

故障树分析图经常被用在Six Sigma进程中,特别用在Six Sigma业务改进进程的分析阶段。

  • 故障树分析法对于数据库故障解决的意义

经过在实践和应用中的总结,我发现故障树分析法作为一种分析方法和思路,同样适合数据库故障的分析和解决,如果扩展一步来说,这种方法作为一种思维方式,甚至适合生活中所有事件的分析和处理。

但是需要注意的是,故障分析实际上是一种事后分析的方法,当然我们不希望工作、生活中当事故、问题出现后再来分析,所以,我一直提倡将故障树分析在事前实施,通过参考别人的经验、教训,将故障树引入事前,人类的学习特点应当能够使我们从学习中而不是亲身经历去获得经验。

通过实践我们发现,将应用于传统行业的故障树分析法引入到数据库故障分析及问题解决之中,可以极大地加快问题分析、处理和解决的速度,同时可以帮助我们发现系统的缺陷所在,从而通过实施有效的预防措施显著地提高系统的稳定性和可靠性。

  • 故障树分析模型的建立

如图所示是数据库系统故障分析树的一个示例,这里以数据库故障为起点,来分析可能导致数据库及应用故障的可能因素。

分析的过程是一个穷举故障原因的过程,我们可以按照不同的方法对故障的原因进行分类,在这个分析中,首先我将第一层归结为3类问题:客户端/中间层故障、网络故障、服务器端故障。这其中任何一处出现问题都可能会导致数据库服务出现问题。

再来进一步深入分析,在一个数据库系统中,客户端或中间层如果出现问题,就可能会影响数据库系统的使用,但这在用户看来同样是数据库故障。那么对于这一类问题,进一步细分,客户端/中间层有哪些故障会引起数据库的访问不畅呢?

首先如果客户端的应用程序损坏可能造成数据库的无法连接,曾经有很多案例因为客户端感染病毒而导致应用程序异常;然后常见的还有客户端版本及驱动问题,Oracle的版本众多,如果驱动版本不匹配可能也会出现问题;客户端的防火墙有时候也会成为阻碍数据库成功访问的障碍之一;当然更为常见的是客户端的配置文件(tnsnames.ora文件或中间件的配置文件)存在问题,导致无法正确连接数据库的。可能的原因还有很多,更为完善的故障树分析图如下图所示。

分析完客户端,在数据库和客户端之间还存在网络,网络问题也是常见数据库故障的问题点之一,可以尝试对网络故障再进行细分,如下图所示。

网络故障的可能原因也很多,首先是物理链路的问题,公网和内网都可能存在链路故障、品质降低等,再加上地址路由等因素,这方面的故障实在很多见,其次防火墙、带宽、流量等因素也是需要考虑的。

当客户端、网络一切正常之后,就到了最重要的一环──数据库服务器端,如果这里出现故障或性能问题,那么原因可能是极其复杂和多样化的。下图列举了一些常见的数据库端故障问题,这张故障分析图是应该存储在每个DBA的头脑中的。

首先客户端经过网络向数据库发送请求,数据库服务器端最先接受请求的数据库监听器,如果监听器出现问题,则数据库连接肯定会出现异常,所以监听器是一个重要环节和故障点。

数据库服务器还可能会经常出现资源短缺等问题,比如连接数耗尽、用户无法创建新的连接;因为归档或备份,磁盘空间可能被耗尽,导致数据库问题;或者磁盘I/O因为硬件故障或性能问题,都可能导致数据库故障或响应缓慢;内存资源或交换也是重要内容,如果内存不足,可能导致数据库性能低下,严重影响数据库的正常运行;CPU资源不足是实际生产中经常会遇到的问题,其原因多样化,可以沿这个节点进一步深入分析。

此外,应用问题也是经常会导致故障的原因之一,有的是因为SQL编写问题,有的是因为数据结构设计存在问题,有的甚至是数据库软件本身就存在Bug。最后来看一下这张图的全貌。

事实上,故障树分析法的使用完全可以十分灵活,我们可以以任何一个提出的问题作为分析起点,比如用户经常反映“数据库响应缓慢”的问题,就可以从这里出发进行问题分解和分析。

有了这样的分析基础之后,在遇到故障时就可以快速地在大脑里进行根据故障树进行分析导航,从而迅速地定位问题的原因,并根据经验或知识找到解决故障的方法。从这个意义上说,故障树也是一个索引。

在这篇文章的讨论过程中,曾经有专家问过我这样的问题:你这种方法只是一个理论的设想,还是在实际中能够有所应用?

实际上我在故障处理中一直是按这样一个思路在处理,后来当我思考怎样将思路转化为方法更容易为大家所学习、探讨时,发现了故障树分析法;我发现故障树分析法就正是我一贯的思维方式,两者契合得如此之好,所以我才将这种方法总结出来供大家参考。

故障树分析法在故障解决中的应用

接下来我们通过一个案例来讨论一下故障树分析法在实际问题解决中的应用。这是一个24×7的重要业务系统,故障出现时业务及开发人员报告系统运行缓慢,已经影响业务系统正常使用,请求协助诊断。

  • 性能缓慢到CPU消耗的定位

业务系统缓慢,根据我们的故障树,可能的原因有资源耗尽、应用问题等,在实际环境中,很多问题可能是同时出现和产生影响的。

首先登录数据库主机,检查当前系统状况。使用vmstat检查,发现CPU资源已经耗尽,大量任务位于运行队列:

本案例当时,系统CPU资源已经耗尽,Idle为0,并且运行队列大量进程排队等待。通过故障树分析思路,利用简单的系统工具辅助,很快就可以发现问题的症结所在。进一步地,我们可以检查一下进程问题,CPU资源的过度耗用可能是个别进程异常或者进程过量累积所导致的。

  • CPU到进程的故障树分析

通过Top工具,我们可以查看进程CPU耗用情况,如果存在进程异常,可以通过Top定位,为进一步诊断提供依据。对于本案例,观察进程CPU耗用,发现没有明显过高CPU使用的进程。

从Top的输出中,可以发现有大量进程处于running的运行状态,CPU消耗很平均,单进程消耗大约在1%左右,基本可以排除个别进程异常导致CPU问题的可能。没有个别进程异常,那么过量的CPU消耗可能是进程累积所导致的,我们根据故障树,在同一层面上对可能导致CPU过度消耗的原因进行排查。我们知道对于一个生产数据库系统,稳定运行的进程数量通常是可知的。

提示:对于稳定运行的生产系统,数据库的运行状况通常是稳定的,如果你绘制出性能曲线,你会发现每个星期的曲线几乎是可以重合的,所以说对数据库系统的运行状况及性能指标具有充分认识和了解是必须的。

来看一下当前系统的进程数量,从而进行比较判断:

bash-2.03$ ps -ef|grep ora|wc -l 258 bash-2.03$ ps -ef|grep ora|wc -l 275 bash-2.03$ ps -ef|grep ora|wc -l 274 bash-2.03$ ps -ef|grep ora|wc -l 278 bash-2.03$ ps -ef|grep ora|wc -l 277 bash-2.03$ ps -ef|grep ora|wc -l 366

发现此时系统存在大量Oracle进程,大约在300左右,大量进程消耗了几乎所有CPU资源,而正常情况下Oracle连接数应该在100左右。

由此,可以基本判断,是数据库或应用出现了问题导致进程任务无法完成,又不断累积,从而出现大量队列等待。这些等待在数据库中应该有具体的体现,接下来需要登录数据库进行检查了。

  • 进一步诊断应用问题

判断数据库可能经历了等待,那么Oracle数据库提供了相关视图供我们查询和发现问题,v$session_wait是首先值得关注的。查询v$session_wait获取各进程等待事件:

对于本案例,我们发现存在大量db file scattered read及db file sequential read等待。显然全表扫描等操作成为系统最严重的性能影响因素。确定这些进程因为数据访问产生了等待,我们考虑捕获这些SQL以发现问题。

这里用到了我的以下脚本getsqlbysid.sql,该脚本通过已知session的sid,联合v$session、v$sqltext视图,获得相关session正在执行的完整的SQL语句。

SELECT sql_text FROM v$sqltext a WHERE a.hash_value = (SELECT sql_hash_value FROM v$session b WHERE b.SID = '&sid') ORDER BY piece ASC /

使用该脚本,通过从v$session_wait中获得的等待全表或索引扫描的进程SID,可以捕获可能存在问题的SQL语句:

SQL> @getsqlbysid Enter value for sid: 18 old 5: where b.sid='&sid' new 5: where b.sid='18' SQL_TEXT ---------------------------------------------------------------- select i.vc2title,i.numinfoguid from hs_info i where i.intenab ledflag = 1 and i.intpublishstate = 1 and i.datpublishdate <= sysdate and i.numcatalogguid = 2047 order by i.datpublishdate d esc, i.numorder desc SQL> / Enter value for sid: 54 old 5: where b.sid='&sid' new 5: where b.sid='54' SQL_TEXT ---------------------------------------------------------------- select i.vc2title,i.numinfoguid from hs_info i where i.intenab ledflag = 1 and i.intpublishstate = 1 and i.datpublishdate <= sysdate and i.numcatalogguid = 33 order by i.datpublishdate des c, i.numorder desc ......

对几个进程进行跟踪,分别得到以上SQL语句,这些SQL可能就是问题产生的根源。

  • 从SQL到问题本质的诊断

使用该应用用户连接,通过autotrace功能检查以上SQL的执行计划:

SQL> set autotrace trace explain SQL> select i.vc2title,i.numinfoguid 2 from hs_info i where i.intenabledflag = 1 3 and i.intpublishstate = 1 and i.datpublishdate <=sysdate 4 and i.numcatalogguid = 3475 5 order by i.datpublishdate desc, i.numorder desc ; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=228 Card=1 Bytes=106) 1 0 SORT (ORDER BY) (Cost=228 Card=1 Bytes=106) 2 1 TABLE ACCESS (FULL) OF 'HS_INFO' (Cost=218 Card=1 Bytes=106) SQL> select count(*) from hs_info; COUNT(*) ---------- 227404

通过执行计划,可以看到以上查询使用了全表扫描,而该表这里有22万记录,全表扫描已经不再适合。检查全表扫描的数据表,发现存在以下索引:

SQL> select index_name,index_type from user_indexes where table_name='HS_INFO'; INDEX_NAME INDEX_TYPE ------------------------------ --------------------------- HSIDX_INFO1 FUNCTION-BASED NORMAL HSIDX_INFO_SEARCHKEY DOMAIN PK_HS_INFO NORMAL

检查索引键值:

SQL> select index_name,column_name 2 from user_ind_columns where table_name ='HS_INFO'; INDEX_NAME COLUMN_NAME ------------------------------ -------------------- HSIDX_INFO1 NUMORDER HSIDX_INFO1 SYS_NC00024$ HSIDX_INFO_SEARCHKEY VC2INDEXWORDS PK_HS_INFO NUMINFOGUID SQL> desc hs_info Name Null? Type --------------------------------- -------- -------------------------------------------- NUMINFOGUID NOT NULL NUMBER(15) NUMCATALOGGUID NOT NULL NUMBER(15) INTTEXTTYPE NOT NULL NUMBER(38) VC2TITLE NOT NULL VARCHAR2(60) VC2AUTHOR VARCHAR2(100) NUMPREVINFOGUID NUMBER(15) NUMNEXTINFOGUID NUMBER(15) NUMORDER NOT NULL NUMBER(15)

……

  • 调整并最终解决问题

检查发现在numcatalogguid字段上并没有索引,该字段具有很好的区分度,考虑在该字段创建索引以消除全表扫描。

观察系统状况,原大量等待消失:

在另外的session里,持续观察的CPU使用情况:

----以上为创建索引之前部分

----以下为创建索引之后部分,CPU使用率恢复正常

至此,此问题得以解决。

  • 性能何以提高

回答这个问题似乎是多余的,我只想重申一点:有效地降低SQL的逻辑读是SQL优化的基本原则之一。下面来比较一下前后两种执行方式的逻辑读取及性能差异。

(1)全表扫描的性能:

(2)使用索引的性能:

consistent gets从3499到89,可以看到性能得到了巨大的提高。

通常,开发人员很少注意SQL代码的效率,他们更着眼于功能的实现。至于性能问题通常被认为是次要的,而且在应用系统开发初期,由于数据库数据量较少,对于查询SQL语句等,不容易体会出各种SQL句法的性能差异。但是一旦这些应用作为生产系统上线运行,随着数据库中数据量的增加,大量并发访问,系统的响应速度可能就会成为系统需要解决的最主要的问题之一。在少量用户下性能可以接受的SQL,可能在大量用户并发的条件下就会成为性能瓶颈。

在我这个案例中,开发人员很难相信仅只一条SQL语句就导致了整个数据库的性能下降。然而事实就是如此,一条低效的SQL语句就可能毁掉你的数据库,所以在系统设计及开发过程中,你必须考虑到诸多细节,严格的测试也是提早发现问题的有效方法。

如果不幸以上环节都被忽略,那么,DBA(也许就是你)就是最后的一环,你必须能够快速地诊断并解决各种复杂问题。

故障树分析法应用的总结

通过以上的故障解决实例我们可以发现,整个故障的解决过程中,故障树的思想是被不自觉地贯穿始终的,那么现在,通过分析归纳和提炼,我将这个分析思路通过故障树的方法展现出来,希望能够对各位读者朋友有所帮助。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-02-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据和云 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
记录一则数据库死锁故障的分析过程
客户的监控告警频繁提示系统xx数据库死锁增长个数高于当前阈值_当前值1.00。 下面是详细的故障分析诊断过程,以及详细的解决方案描述。
Alfred Zhao
2020/05/08
1.1K0
Oracle诊断案例----如何捕获问题SQL解决过度CPU消耗问题
Last Updated: Sunday, 2004-10-24 0:37 Eygle
数据和云01
2018/09/12
6390
ORA-12547: TNS:lost contact导致数据库无法启动
墨墨导读:一个诡异的案例:ORA-12547: TNS:lost contact导致数据库无法启动,甚至sqlplus都无法登录,让我们一一来解开这个案例的真面目。
数据和云
2020/07/02
6.4K0
从一个故障案例看强大到令人发紫的Oracle数据库--我和数据中心的故事
作为一名混迹数据库江湖十几年的老DBA,当你对关系型数据库的了解越来越深入时,你会发现,Oracle数据库真的是强大到令人发紫! Oracle数据库的强大,不仅体现在其对ACID的巧妙实现,其对高并发的完美支持,更重要的是他的可管理性,包括可度量、可回溯,以及出现问题后的问题核查接口和问题检查方法论,真是强大到令人发紫,这是其他关系型数据库短期内还无法超越的。 中亦科技小y(黄远邦) 问题引入 电话响了,是某银行一位熟悉的资深DBA的来电。 “小y,现在应用连接数据库会hang住,sysdba登陆也会han
数据和云
2018/03/07
1.6K0
从一个故障案例看强大到令人发紫的Oracle数据库--我和数据中心的故事
经典故障分析 -用好UTL_FILE包其实并不是太容易
作者介绍 崔华 网名 dbsnake Oracle ACE Director,ACOUG 核心专家 UTL_FILE包可以用来读写操作系统上的文本文件,UTL_FILE提供了在客户端(FORM等等
数据和云
2018/03/08
2.1K0
经典故障分析 -用好UTL_FILE包其实并不是太容易
Oracle数据库运维方案及优化
运维优化 本文详细讲解了如何对Oracle数据库进行运维,从各个方面来说明了如何去运维。
全栈程序员站长
2022/11/01
2.1K0
Oracle大数据量更新引发的死锁问题解决方法及Oracle分区和存储过程的思考
前几天上午在对数据库的一张表进行操作的时候,由于这张表是按照时间的一张统计表,正好到那天没有测试数据了,于是我想将表中所有的时间,统一更新到后一个月,于是对80w条数据的更新开始了。整个过程曲折的一批。同时学到了很多知识,在此进行记录。希望对大家有帮助。
星哥玩云
2022/08/17
1.6K0
故障诊断:DRM导致Oracle RAC节点Hang住
生活就像一盒巧克力,你永远不知道下一颗是什么味道。 --《阿甘正传》 在DBA的世界里,数据库的新特性就是这样一盒巧克力,可能是惊喜也可能是坑。毋庸置疑,新特性总是伴随着新功能而来,然而在企业最核心的数据资产面前,某些新功能的出现所带来的好处,远远不及其对于性能和稳定性带来的危害。因此我们常常会选择禁用一些新特性,今天要分享的DRM就属于其中一个。 为什么DRM通常会被列入禁用的名单,今天我通过一个真实案例来认识DRM可能会导致的数据库故障。 什么是DRM 在Oracle 10g版本中,开始提出了DRM特性
数据和云
2018/03/07
2.1K0
故障诊断:DRM导致Oracle RAC节点Hang住
数据库服务器主机重启故障诊断分析
摘要:某客户RAC数据库服务器主机轮流发生集群与主机重启,数据库连接不上问题,如下为故障诊断思路.
用户6781613
2020/03/18
2.1K0
案例:Oracle 11g RAC 数据库连接数过高处理办法
墨墨导读:近期有一套数据库总是出现如下告警“严重告警:XXX Oracle 服务器:10.10.X.X 数据库的侦听器 LISTENER 状态为 Inactive ”,本文详述处理的整个过程。
数据和云
2020/11/16
1.1K0
案例:Oracle 11g RAC 数据库连接数过高处理办法
数据库的“黑匣子”--故障诊断日志基础
相信大家都知道,当飞机发生事故后,人们进行搜救的时候,总是会寻找一个东西---被誉为空难“见证人”的黑匣子。它可以给调查人员提供证据,帮组他们了解事故的真相。 同样,作为业界最为强大的关系型数据库,Oracle数据库也提供了无与伦比的“黑匣子”功能--数据库故障诊断基础架构。通过这个架构设计,当发生问题或者严重错误时,数据库会自动为每一个事件/错误分配一个事件号/错误号,然后输出相关的日志文件,为问题预防、发生重大问题后的追溯原因和修复缺陷等提供重要线索和证据。
SQLplusDB
2020/03/26
1.1K0
故障分析:数据库一致性关闭缓慢问题诊断
想必我们大家都知道,Shutdown immediate即一致性关闭数据库,数据库下次启动不需要做实例恢复即可open数据库。那么当数据库一致性关闭出现缓慢等状况时,该怎么办呢?那我们就来一起分析一下,数据库一致性关闭缓慢问题。 shutdown immediate在数据库中会做哪些操作? 从以上图得知在shutdownimmediate关闭数据库只需要在数据库中强制选择检查点并关闭文件,不需要等待当前事物处理结束,不需要等待当前会话结束,不允许新连接。 引发shutdown immediate slo
企鹅号小编
2018/01/25
7730
故障恢复:一次底层超融合故障导致的异常处理
数据库宕机之后,现场工程师开始用rman备份恢复数据库,当数据库alert日志提示控制文件有大量坏块。
数据和云
2020/08/18
8830
故障恢复:一次底层超融合故障导致的异常处理
记录一则数据库连接故障ORA-12560,ORA-12518
环境:Win Server 2008 R2 + Oracle 11.2.0.1 故障:客户反映数据库连接不上,本机sysdba和网络连接都连接不上。
Alfred Zhao
2022/05/06
1.5K0
MySQL 数据库高负载故障分析
shaonbean
2018/01/02
2.3K0
MySQL 数据库高负载故障分析
一次数据库宕机问题的分析(r6笔记第5天)
今天来到办公室,发现有一台服务器中的数据库实例停掉了。这种情况真是意料之外,尤其是我还不是很熟悉这台机器的服务。 赶紧查看数据库日志,可以看到数据库在昨晚停掉了,从日志来看没有人为的痕迹。 在宕机之前,有下面的日志。在此截取一部分。 TNS-12560: TNS:protocol adapter error opiodr aborting process unknown ospid (33498) as a result of ORA-609 ns secondary err code: 0
jeanron100
2018/03/16
1.6K0
Oracle 19C 通过 ODBC 连接 SQL Server 数据库指南 (Red Hat 7)
本指南详细说明如何在 Red Hat Enterprise Linux 7 系统上配置 Oracle 19C 通过 ODBC 连接 SQL Server 数据库。这种异构数据库连接方式称为 Oracle Heterogeneous Services,允许 Oracle 数据库直接访问非 Oracle 数据源。
晓松
2025/04/09
4030
Oracle 自动故障诊断
Oracle故障诊断有助于预防,检测,诊断和解决问题。特别针对的问题是诸如由代码错误,元数据损坏和客户数据损坏引起的重大错误。
Leshami
2018/09/20
2.2K0
Oracle 自动故障诊断
新书连载:Oracle数据库的跟踪和分析方法
编辑说明:《Oracle性能优化与诊断案例精选》出版以来,收到很多读者的来信和评论,我们会通过连载的形式将书中内容公布出来,希望书中内容能够帮助到更多的读者朋友们。 在今天的技术领域,DevOps已经成为最热门的话题之一,DevOps是开发和运维一体化的实践趋势,也是运维掌握一定的开发能力,推动和协助开发进行适应高效运维的渐进变革。 在我的技术生涯中,对Oracle数据库的接触最多,感受也最深。如果说要将最值得推荐的技能展示给大家,那么我想推荐的就是Oracle跟踪方法。事实上,通过跟踪能够实现的也正是不
数据和云
2018/03/07
1.1K0
【新书连载】应用无法连接数据库问题分析
编辑说明:《Oracle性能优化与诊断案例精选》出版以来,收到很多读者的来信和评论,我们会通过连载的形式将书中内容公布出来,希望书中内容能够帮助到更多的读者朋友们。 前不久某运营商客户反映某套业务系统在2016年8月4日凌晨出现过无法访问数据库的情况。当接到客户请求之后我才通过V**登录进行日志分析。 首先我分析数据库告警日志发现,8月4日凌晨54分开始出现unable to spawn jobq slave process相关错误,如下所示。 从上述告警日志来看,没有明显的OR
数据和云
2018/03/07
1.7K0
【新书连载】应用无法连接数据库问题分析
推荐阅读
相关推荐
记录一则数据库死锁故障的分析过程
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档