从Oracle等数据库迁移到国产数据库上来，大家可能还有些不适应。如果遇到问题该怎么办？如何去做分析，如何定位根因呢？
图片
对于大多数国产数据库而言，除了数据库本身存在的问题或者BUG等，大多数的问题还是可以通过一些通用的手段来进行分析的。这两天老白花了点时间梳理了一张思维导图。下面我来简单介绍一下这张导图。
图片
分析的第一步肯定是查看日志，数据库日志永远是故障定位最为重要的环节，因此查看数据库日志是一切故障、性能分析的起点。有些日志问题可能很快就能帮你定位数据库故障，不过有时候可能遇到了BUG，或者你根本看不懂国产数据库的日志（某些国产分布式数据库的日志是极难阅读的），如果你的数据库厂商提供比较及时的服务，将日志采集好发送给国产数据库原厂售后人员是十分关键的。
有些时候遇到数据库性能问题，也可以开启慢日志来抓取相关SQL，不过开启慢日志会带来一定的开销，因此只能在分析问题的短时间内开启。
如果数据库日志没有发现问题，那么下一步就要做操作系统日志的分析。如果OS日志没有发现问题，那么下一步就是做OS资源分析。
图片
一般情况下OS资源使用率应该处于较为正常的范围，如果有OS监控系统，能够看到历史数据，通过历史数据的比对就更容易发现问题了。在OS资源分析的时候，更加注重于发现“异常”，而不是看绝对值。
对于内存，不能仅看内存使用率，内存使用率在LINUX系统中是一个指向性不强的指标。内存不可用率或者内存可用率的指向性更强。发现内存问题的另外一个方法是看系统中是否存在严重的换页。如果内存资源存在问题，出现了换页或者OOM KILLER，那么可以通过分析TOP 内存占用进程来找到可能存在的内存杀手。仔细查看MEMINFO文件，找出其中的问题关键是必须要做的事情。是CACHE占用内存过多了，还是没有启用大页，导致页表的内存占用过大。亦或是透明大页导致的内存碎片化，引发了内存的性能问题？
IO问题十分典型的包括IO吞吐量过大、IO延时超标等。如果IO延时过大，那么就要分析后端存储是否存在问题，多路径是否出现过切换。这时候有个检查项是容易被忽视的，那就是异常进程分析。如果D状态的进程很多，而且长时间不消除，那么大概率是存储系统的哪个地方出问题了。
CPU的情况比较复杂，不能仅看CPU使用率比较高就认定CPU引发了问题，还要看r队列的大小（LINUX中称为load,负载），如果R长期大于CPU线程数的2倍，那么CPU可能真的有瓶颈了，否则只能说系统负载较高，但是还不一定能引发性能问题。如果USR高，说明应用可能是CPU消耗过大的元凶，分析会话和TOP SQL就可以了。如果SYS过高，那么就比较复杂了。SPINLOCK，换页，内存碎片，存储系统故障，网络故障，数据库闩锁争用严重，达梦DSC集群争用等都可能导致SYS CPU使用率异常（这里说的异常不一定是SYS CPU特别高，当CPU使用率总体不高，SYS占比过高的时候，也可能已经出现了系统性能异常了）。如果WIO过高，那么大概率是存储出问题了。
图片
如果OS资源没有发现什么问题，那么我们就必须去从数据库的角度找问题了。这方面也有一些数据库通用的诊断方法。首先如果数据库支持等待事件，而且等待事件相对是准确的，那么通过等待事件可以看出一些端倪。如果等待事件无法发现问题，那么接下来去看长事务和锁就可以了。
如果这方面没有问题，那么进一步做会话异常分析，大概率会发现问题。这里要注意的一个是会话执行SQL数量最多的SQL是最需要关注的也是容易被忽视的问题。会话的数量是否异常，活跃会话数量是否异常，会话来自的服务器分布情况是否异常，会话来自的应用程序模块是否异常等等，都是判别会话是否异常的重要手段。
如果你的系统存在历史会话信息（类似于Oracle ASH），那么恭喜你，你拥有了更为强大的分析手段。将数据库会话分析的方法应用于历史会话分析上，会有更加好的效果。
基于我今天介绍的方案，针对一个集中式国产数据库，哪怕你以前没有怎么接触过，也可以轻松的进行故障、性能分析了。这套方案，基本上可以覆盖80%以上的常见问题。大家如果有兴趣可以在遇到问题的时候试一试。分布式数据库的诊断方法类似，不过有更复杂的逻辑，等我有空的时候再画一张图吧。
