DBA都比较羡慕那些老鸟，他们看看日志文件，查几个指标，看两份AWR报告就能大致推断出数据库的问题到底出在什么地方。心向往之的同时，也在想我什么时候也能达到这样的水平，我需要怎么学习才能达到这样的水平。实际上这世上并无捷径，每个老鸟都是从菜鸟开始成长起来的 。每一次故障处置，每一次去现场的机会，每一次在网上和别人讨论一个案例，都是向老鸟前进一步的机会。如果你半夜接到老板的电话，让你去现场处置一个紧急故障，你觉得不公平，为啥叫我去，不让其他人去，那么你很可能就失去了一次锻炼自己的机会。年轻人吃点苦不怕，怕的就是到了30多岁才发现自己这些年太荒废了。大多数成功的老鸟都是比较勤奋的，在这年里，我还没有遇到过平时很懒，但是水平极高的高手。

勤奋只是一个必要条件，并不代表充分条件，仅仅勤奋是不够的，善于总结更为重要。有可能你已经半夜加了不少班了，但是你不去总结，仅仅是机械的重复老鸟教给你的那几招技巧，那么你很难有大的长进。运维知识的积累往往和总结密不可分，如果你只是不断的干苦活累活，并没有去做必要的总结，也没有人指点你如何去总结。那么可能你干了一辈子还是在一个较低的水平上徘徊。

你看到上面的等待事件会意识到什么?你需要怎么去进一步分析问题。要想分析这些问题，你需要在自己的脑子里构建出Oracle等待事件的知识图谱，大概每个等待事件的含义是什么，可能受什么影响，可能会影响到下游的哪些方面，产生什么样的后果。这个例子中，我们可以得到以下的结论：

占比最高的是direct path read temp/direct path write temp,这两个等待事件应该是关联的;

CPU TIME大致是SQL执行的开销，这个系统中CPU使用率很高，不过CPU TIME很小，大概率是SQL都比较小，没有复杂的消耗很大SQL;

log file sync和REDO的并发量有关，本系统中的事务并发量不大，REDO量也不大，延时有点高，可能配置上存在一些问题，不过不是主要问题;

latch：cache buffer chains等待与DB CACHE争用或者热块争用有关。占比不高，可能和热块冲突有关。

有经验的DBA对于常见的等待事件在脑子里会有一个类似知识图谱的东西，比如上游什么事件会引发下游什么事件。比如对于排名最靠前的等待事件direct path read temp/direct path write temp,脑子里的这个局部的知识图谱是这样的：

如果上游的图谱识别得不完整，只看到了HASH JOIN和SMJ，没有SORT，那么分析下去就有可能出现偏差。如果识别错了，把direct path read和direct path read temp搞混了，那就更麻烦了。

这是一个十分容易出现的认知偏差，有时候一马虎就忽略了temp这个词了，有些人对这个知识点了解得一知半解，也会存在错误认知，从而在分析问题的起点就发生偏差，最终导致无法准确定位问题。

如果我们使用了正确的知识图谱，那么下面就很容易找到验证问题的方法，看看临时表空间访问的效率，看看PGA命中率是不是很低，看看M-PASS排序都是什么样的大小。

这时候可能有点经验的DBA都能看出，这个问题应该是PGA参数设置不合理导致的。对于有经验的DBA来说，定位这个问题耗时几分钟就可以完成了，因为在脑子里有这个知识图谱存在。如果脑子里没有知识图谱，那么定位这个问题就需要去MOS上找相关案例，然后进行比对才能完成。

完成这个思考的图谱如上，实际上这张图可能更大，如果问题表现不同，可能会涉及更为广泛的知识图谱。大家可以看出，这种图是画不完的，因为知识体系十分庞大，甚至超过人脑可记忆思考的范围。人的脑子里的知识图谱也不是这么构造的，是通过长时间一点一滴积累的。是人的大脑自动把这些支离破碎的知识拼凑在一起的。有些时候这些知识点都在人的脑子里存在，只是没能把这些知识点之间的关系构建起来，那么在思考问题的时候，就无法十分流畅地进行推理了。

因此积累点状知识的同时，也要注意对知识的理解和梳理，只有打通了任督二脉，才能让真气运用自如。知识不能运用自如，就会像段誉使用六脉神剑一样时有时无，思路顺畅的时候行云流水，而下一回好像遇到了堰塞湖。这种情况一般都是因为你没有打通一些知识点之间的联系，没有把知识图谱梳理清晰。

梳理知识的比较好的方法是定时整理，而写文章是最好的整理方式，特别是写给别人看的文章，那么在写的过程中往往还要去做知识验证，否则写错了，就会贻笑大方了。因此写文章发博客、公众号是更好地梳理知识的方法。公众的监督会让你把这件事做得更好，因此我一般会建议年轻人多写写文章。在《DBA的思想天空》的序言中我也曾写过，我真正的梳理Oracle的知识是从想模仿《DELPHI深度历险》写一本名字叫《Oracle深度历险》的书，最后因为那时候对Oracle的理解还比较粗浅，书写得不成功，但是通过写书，把Oracle知识的任督二脉打通了。

虽然知识体系是一个庞大的网络，因此我偏好用知识图谱来描述。不过我们无法直接构建一张大而全的知识图谱来描述这些知识，只能以点状来学习和记录知识。庞大的知识图谱对于人来说也很难驾驭，思考问题的时候虽然会自动使用这些知识，但是人的算力总是有限的，而计算机系统在图处理方面的能力要远高于人脑，因此把这些知识放到图数据库里，通过图算法来处理这些知识会有更高的效率。这也是这些年我把手头的工作全部放下，全身心投入到运维知识图谱的构建工作中的主要原因。

不过这项工作并不好做，个人的能力总有穷时，必须集大家之智来做这件事才更为靠谱，不过目前我并没有找到一个更好的办法来集众之力，完成这一工作，只能先做起来再说了。