上回我发了那个10年前的测试题，不少网友留言让我公布一下答案。实际上这些问题的答案很多在我的公众号里都有介绍。比如关于大型优化项目的工作流程，这是我每期培训都会反复讲的，每次实际上都会根据实际工作中遇到的问题做一些微调。这些流程性的东西比较复杂，而且涉及到团队的工作习惯，以及甲方的特点，因此没有标准答案，只不过有些环节可能不是一般的DBA接触得到的。比如说组织架构、工作协调、各种访谈等，只有组织有序的大型优化项目才能真正的开展起来。如果大家对流程感兴趣的话，我后续会发一些文章介绍一下。
在介绍几道题的情况之前，我又找到了几个文件，上面是2013一季度和二季度的考试成绩，人员之间的差异还是挺大的，大部分测试的平均分都是不及格。因为每次考试都会略微增加难度。下面是每次考试后对一些团队成员的简要评价，用于后续针对性培养。
第六题是一个十分典型的Oracle性能方面的问题，对于有经验的DBA不难从AWR中看出一些问题。首先我们从Load Profile上可以看出当时系统负载不高，甚至可以说是相当低。按理说这样的系统似乎不应该出现性能问题。
不过系统的性能问题有时候不是因为系统负载过高，资源不足引发的，一些很空闲的系统依然跑不快，在现在的优化项目中很常见。
Buffer nowait的比例96.76，系统中还是存在一定的BUFFER BUSY WAITS的，从TOP EVENT上也可以看出这一点。
与热块冲突相关的因素占了超过10%，在一般系统级优化中这已经是足以让人去重点优化的了。不过在这个案例中，要不要投入精力去优化热块冲突，以何种方式去优化热块冲突，这些数据还不足够。其实整个等待事件里最令人感兴趣的是direct path read，不仅仅因为这个等待占总等待的81.14%，更重要的是平均等待时长是6911。这个指标一般情况下是在几个毫秒，慢点的话也不超过15毫秒。直接路径读并不是不允许的，这是Oracle基于较高性能的IO子系统上的优化DB CACHE一种方法。通过强大的底层IO能力来优化DB CACHE的性能。不过如果direct path read引发了底层IO的性能问题，那么就要考虑如何优化了。因此在这个题目中，我们应该得到一个结论，下一步要去分析系统的IO性能如何（本题目中没有列出）。另外针对direct path read的优化方式也有多种，需要个根据实际情况来选择，如果是因为某些SQL不够优化并且可以优化，那么首要的就是优化SQL。如果底层IO能力较差，而经常会出现direct path read，那么关闭direct path read也是一个选项。不过关闭之前还要考虑物理内存和DB CACHE是否足够大的问题，同时要考虑去解决一下热块冲突的问题，否则关闭direct path read可能会加剧bbw，按起葫芦又浮起瓢了。如果你把上面的观点都表达清楚了，那么这道题目已经能够拿到大部分的分数了。
第七题如果是老司机那么肯定能够看出这个数据来自于一个AIX系统。负载不算太高，不过读写延时比较高。从avserv上看，指标还不算太差，说明后端存储的性能还可以。IO延时比较高可能是在多路径软件或者操作系统层面。对于早期的AIX系统，比如5.X/6.X,同时使用IBM自己的多路径软件，那么HDISK的queue_depth参数对于IBM自己的存储系统，默认值是8，对于HDS或者HP的存储，默认值是2，对于华为的OceanStor，默认值是1。如果在系统中用iostat -D，我们大概率会看到这些有问题的盘上有sqfull的情况，这就是队列满的标志。当某个HDSK并发访问量大一点的时候，就会产生等待，影响性能。在高负载情况下，我们一般建议设置16或者32。这是优化团队在以往这个客户那边的常见问题，也是在培训中也多次提到的小技巧。因此这道题当时在考试时算是送分题，只要认真参加培训的同学都能拿到满分。
实际上这里并不包含十分高深的技术与技巧，只是一些经验的积累与传承。培养一支队伍是比较困难的，3年时间里，我们给超过100人做过这样的培训，考过这样的题目。不过随着项目的终结，这支队伍在不到一年里就散去了。这些年我依然在关注着他们，从他们的微信朋友圈里我看到他们有些去了甲方，有些去了数据库原厂，有些去了数据库第三方服务企业，有些做了管理，也有不少转行去做其他事情了。不过他们中的一些人还是在做DBA的技术工作，这些经验的传承还是会继续下去的。
