对系统故障处理的思考

来源:srsunbing 责任编辑:栏目编辑 发表时间:2013-07-01 08:23 点击:

    年初去某公司面试时,对方的项目经理问如果数据库现在很慢,你该怎么办,我问慢的现象是什么,数据库是被调用的不会莫名其妙就慢了,对方说什么都没有,就是慢了,你该怎么办?我说既然是这样,那就按老办法处理了:
1. 登陆机器用topas 、svmon -G、sar 1 100、ps aux 等,查看cpu、内存、交换区、磁盘的繁忙程度,看下是否有占系统资源特别大的进程。
2. 查 v$session_event、v$session_wait 看是否有大量的 latch free、enqueue、 free buffer waits等等待事件,看下归档日志的文件系统是否满了。
3. 如有占系统资源特别大的进程,通过v$process和v$session两个视图找到 Oracle进程的sid,serial#,把它用 Alter  system kill session ‘sid,serial#’;杀掉;如果是归档日志满了,就清理日志。
4. 通过上面操作,表面现象基本会消除,下来再慢慢分析是什么原因引起的慢,是应用服务引起的、还是业务逻辑引起的、还是sql的性能引起的,找不到本质它还会慢的。
    写上面那段话,想要说明什么目的呢?其实很简单,就是想说明,任何故障都是有原因的,都是有表面现象的,说没有任何现象那是扯蛋,而且这一类的信息系统也就那么几类故障,绝对不会发生像动车追尾的事故,所以在发生故障时,观察现象是很重要的,对于一个有经验的人来说,从现象上就能基本判定是哪里的问题,
所以我们一定要提醒和引导报障人,报告故障时:
1. 要详细的说出故障的现象,说不清时就截图,图片更加一目了然。
2. 故障的时间点,通过时间点可以找到相关日志,还能了解到相关的人员在此时间做了什么操作,必定能操作系统的也就那几个人。
3. 故障的影响范围,是几个人用不了,还是很多人或者全用不了。如果影响了几个人,那肯定不是服务的问题,就不用去查服务了,直接去检查终端(有时也不能全凭经验,也要谨慎点);如果是影响范围很大,那就直接查看监控服务(如F5,每台服务的运行状态一目了然)。
4. 通过上面的几步已经基本确定故障了,下来尽快恢复系统正常运行,然后再慢慢分析故障原因。
5. 通过查找上面时间点的系统故障日志,基本会看到相关的错误信息的,如调用了那个数据库对象、返回了什么oracle的错误、写了什么java异常信息;如果没找到或者几百M的日志不好找,那只能模拟测试看故障能否再重现,一般有详细的操作步骤,故障大多能重现的。
6. 如果是Java 问题就去分析相关的jap、java文件、配置文件(或web服务的配置文件)等。
7. 如果日志记录了数据库对象的信息,那更简单,直接去test下相应的数据库对象,不是逻辑问题就是sql性能问题。
8. 修改找到的问题,形成案例集,避免类似故障下次再次发生。
   上面提到的只是日常故障的基本处理思路,不说处理方法,很多时候思路比方法更加重要,好多时候不是我们不会处理,而是我们没有处理的思路,不知道下一步该朝那走,这样就麻烦了。
   根据多年系统的故障来看,60%都是人为造成的,40%才是系统自身产生的故障,在系统产生的故障中大部分都是业务逻辑、sql性能引起的,还有一小部分是网络、硬件引起的。sql性能方面的主要有以下:
1. 没有使用正确的索引,如语句中写的是组合索引、函数索引,但表上没有建立相应的索引,或着是没把组合索引字段放在最前面。
2. 分区表没建立本地索引,或者是建了本地索引但没有用到分区字段。
3. 多表连接时基表没有选好,或者是where条件没有明确指定各表的连接条件,或者是过滤最大数据的条件没有放在后面。
4. 使用了不必要的类型转换,特别是字符型与数值型的比较,这点很容易疏忽。
5. 对列进行了不必要的操作,包括数据库函数、计算表达式等。
   例:
   select * from record where  substrb(CardNo,1,4)='0757'  
   select * from record where  amount/30< 1000  
   select * from record where  to_char(begintime,'yyyymmdd')='20101201'
6. 使用了 in 、not in 、exists、 not exists 等,应使用外连接outer joins 。
7. 使用了不必要的索引,应该用 +0 或 || '' 使索引失效。
8. 使用了复杂的group by分组计算条件。
9. 大数据量时,增加查询的范围限制,避免全范围的搜索。
10. 条件中用到or 、null、not null、<>、like 等操作符。
11. 中间表、临时表数据不及时truncate,历史表数据没有及时清理,索引没有定期重建等都会引起sql性能的低下。
    上面写的只是日常故障的基本处理思路和影响sql性能的一些可能点,随着系统运行的时间加长,还会有其它的问题出现,还会挖掘更多的隐患,只有那样才能触进系统更加健康良好的运行。

本文出自 “srsunbing” 博客,请务必保留此出处http://srsunbing.blog.51c

    相关新闻>>

      发表评论
      请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
      用户名: 验证码:点击我更换图片
      最新评论 更多>>

      推荐热点

      • sql常见面试题
      • SQL SERVER 2005性能之跟踪
      • SQL编程(一)
      • LINUX上RMAN自动备份脚本
      • sql server面试题
      • 浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色
      • 如何将多个SQL查询统计结果一次显示出来
      • SQL小技巧系列 --- 行转列合并
      • sql server 列转行
      网站首页 - 友情链接 - 网站地图 - TAG标签 - RSS订阅 - 内容搜索
      Copyright © 2008-2015 计算机技术学习交流网. 版权所有

      豫ICP备11007008号-1