用机器学习分析解决数据库疑难故障--技术人生系列第四十五期-我和数据中心的故事

在Jason负责管理的开发测试环境中，突然间有一个库连不上了，由于是12c多租户环境，好几个开发项目组同时暴跳。Jason登上环境，发现sqlplus已无法登录，alertlog里大量的ORA-4031。显然shared pool没有空间了。

由于是开发环境，为了让应用最快速度可用，Jason重启了实例。重启后恢复正常，Jason也能sqlplus进去看看信息了。通过dba_hist_sgastat视图，发现有个叫”gcindex split transactio“的component一直在不断增长，在宕机前涨到了将近80G，几乎占满了整个SGA。于是自然4031了。

首先求助万能的BING（不能用Google，百度没有用），没有任何相关条目。去Oracle的metalink知识库，竟然也没有任何条目。Jason暗暗叫苦，谁叫自己冲那么前面用12.2版本呢。

好在重启后恢复正常了，那就开个SR同时再观察几天吧。果然，一如既往，重启后这个component仍然以每天6个G的速度增长。并且SR的处理效率也一如既往的慢。Jason凭借多年经验判断，这个八九不离十是BUG。但是等官方确认是BUG并且提供补丁遥遥无期。难道只能定期重启？这样的问题上生产怎么办？能不能找到引发BUG的操作，至少能防患于未然。Jason决定不能坐以待毙。

没有配图，随便找张SGA吧...

既然定位BUG和补丁是Oracle的事情，那我们自己能做的，就是尽可能查到什么操作引发了这个BUG（现象）。大家都知道Oracle固定时间（默认1小时）会做数据库的快照，保存大量的系统信息到DBA_HIST视图。Jason就想，何不拿这些数据和这个”gcindex split transactio“的增长做一个相关性分析？说不定能发现些什么呢。说干就干，Python程序写起！

首先选取V$SYSSTAT中所有VALUE不为0的STAT_NAME，然后把每个快照期间他们的增量和”gcindex split transactio“的增长量求一个相关系数。想法不错，但马上遇到第一个问题，DBA_HIST_SGASTAT是累积量（culmulative)不是增量（delta）。没关系，好在有Oracle强大的分析函数（其他数据库就没那么幸运了），直接一句SQL把每行中的累积量换成增量：

然后，就在Python中把所有v$SYSSTAT中的指标全拿过来（1800多个），带入:name。每个指标取出的样本量是所有snapshot的总数。逐个用numpy中的corrcoef()计算相关系数。然后排序。最终获得相关系数最高的进一步分析。

大概也就跑了2分钟，结果出来了，排名靠前的指标和相关性 ：

可以看到user logons cumulative和logons cumulative的相关系数达到了8个9！基本上就是完全相关。于是接下去的分析方向就很明显了，单独拎出来跑个SQL，肉眼验证下：

的确很相关！用户登录在高的时候达到了每小时200万次。于是打开监听器日志，快速发现了是哪个PDB，从哪里连过来的连接。后经过和应用沟通，确实是应用的问题，应用服务器的/etc/hosts没有配好，导致连接失败，应用还疯狂的在连接。应用停了，修改完，一切都正常了。

读到这里，有些读者可能会想，早干吗去了，用得着那么麻烦吗？早点去看看监听日志，或者更仔细的去看看awr报告，不也能发现问题吗？

说的没错，不过你对Jason要求太高了，Jason不做一线DBA那么多年，迷失在流程和商务中，早已失去了一线DBA敏锐的观察力和经验累积。只能通过这种办法来分析问题（当然也是灵感乍现后突然来兴趣了）。但我也不得不说，这个问题Jason不是没有第一时间让一线工程师看过，并未得出有效结论。