从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%以上的常见问题。民众要是有趣味不错在遭受问题的时候试一试。散播式数据库的会诊花式相同开yun体育官网入口登录体育，不外有更复杂的逻辑，等我有空的时候再画一张图吧。