Preface前 言
美国有一句著名的谚语：如果上帝关闭了一扇门，他会为你打开一扇窗。美国还有一个有名的关于Oracle的笑话：上帝和埃里森的区别就是，上帝不认为自己是埃里森。
无论上帝怎么想，埃里森肯定认为自己是上帝，至少，是数据库界的上帝。这位数据库界的上帝所开创的著名的Oracle数据库软件是闭源的，对于想研究Oracle的DBA来说，相当于关上了一扇门。但同时Oracle中提供大量的DUMP命令，这又相当于为DBA打开了一扇窗。但现在，这扇窗正在慢慢关闭。
很早之前，有很多从Oracle公司流向外界的“内部资料”，对这些内部资料的研究甚至成为学习Oracle的一个专门分支：Oracle Internal。当时很多DBA都会在简历中加上一行：“精通Oracle Internal”。当然，笔者也不例外。但是，近五六年来，不知是因为Oracle公司加强控制，还是因为众DBA研究热情下降，或者二者兼而有之，市面上所见的“内部资料”越来越少，特别是近两三年，基本已经绝迹。
从笔者来看，造成这种情况是“二者兼而有之”。“Oracle有意控制”论并非空穴来风，伴随着Oracle数据库应用得越来越广泛，第三方维护市场的发展也是如火如荼。如果有了疑难问题只能找Oracle原厂的售后团队解决，那么第三方维护公司将很难与Oracle竞争，这是控制这块市场的最好方法。实现这一目标的捷径，当然就是控制非原厂DBA对Oracle数据库的了解程度。但是另一方面，Oracle对Oracle技术社区的支持还是有些力度的。所以个人感觉是二者兼而有之，但愿我是“以小人之心，度君子之腹”。无论Oracle是否有意控制，现在Internal爱好者越来越少已是不争的事实，这与Oracle的闭源策略有很大关系。
笔者早年也是“Oracle Internal”研究的爱好者，个人认为，对Internal的研究分为以下3个阶段：
好奇。
学以致用。
麻木。
好奇之心，人皆有之。对IT技术有兴趣的DBA，在接触Oracle不久后，总会对Oracle内部算法产生强烈的好奇心：它是如何计算HASH值的？它是如何搜索HASH 链表的？检查点到底完成了什么操作？如果你有这种好奇心，并且有强烈的探索欲望，恭喜你，你将有望成为高级DBA。跟着你的好奇心去探索吧，在网上查找资料，再加上自己动手做测试，很快你就会对各种Internal有朦胧的了解。当出现一些等待事件、一些性能问题或故障时，你就可以从你所了解的原理出发，去分析问题了。这就是第二阶段—“学以致用”，到这一步，“高级DBA”这个头衔就在向你招手了。
但是很快，你会发现，看不到Oracle的源代码，仅从各种DUMP结果中分析算法，无异于“隔靴搔痒”，有个最恰当的成语描述这种情况：雾里看花。你会发现，我们雾中看出来的“花”，在解决实际问题时，作用极为有限。一些疑难问题，还是无法理清头绪。这样的事情经历多了，就进入了“麻木”阶段。自然也会得出结论，对Internal的研究，现实意义有限，主要是满足好奇心。然后，有可能还会语重心长地告诫初学者，Internal意义不大，浅尝辄止即可，不必浪费太多精力。当这样的情况越来越多后，人们的“研究”欲望自然会越来越低。所以，现在基本上已经很少有人再去研究Internal了。
反观开源领域，虽然源代码的改动并不是“想改你就改”那么简单，因为有各种各样的管理委员会控制，如果不能成为委员，改一个Bug都难，但由于可以看到源代码，只要下工夫钻研代码，想做到“明明白白我的心”并不难。这样一来，在遇到一些奇怪问题时，进行诊断、分析将更有依据。这其实是开源数据库在国内流行的主要原因之一。国内的Committer并不多，就算能读懂源码也不能修改，在这种情况下，开源除了“便宜”、成本低之外，还有什么优势呢？优势就是“用得明白”、“用得清楚”。闭源的Oracle虽然Bug更少、更稳定，但出了奇怪的问题后就很难解决。开源则不一样了。一边是Oracle的“雾里看花”，你看不到隐藏在暗处的原理；一边是开源领域的“明明白白我的心”，众多技术人员当然选择“弃暗投明 ”了。
而且近些年，由于前面说的两点原因，Oracle这场雾更浓了，已经变成“雾霾”了。以前著名的内部资料DSI也止步于Oracle 9i，鲜见Oracle 10g版本的，更别说Oracle 11g的了。外界DBA由于缺乏对原理的了解，很多基本操作都要依赖原厂工程师。比如Exadata，如果没有原厂工程师协助，连安装都很难完成，更别谈运维了。Oracle的大门从来就没有敞开过，现在，连“窗”也在逐渐关闭。
变革正在到来。在“门”、“窗”都没有的大环境下，或许可以选择把墙给凿了。凿穿墙壁，一样能看到Internal。不过，工欲善其事，必先利其器。如果没有适当的工具，想要打开Oracle这样庞然大物般的软件无疑是以卵击石。幸运的是，现在凿墙利器已经有了，那就是“动态性能跟踪”语言，比如，Linux下的System Tap，Solaris下的DTrace，等等。经过笔者试用比较，Solaris下的DTrace更适合用来研究Oracle原理。虽然我们只能在Solaris平台使用，但Oracle的原理在所有OS下是一样的（除了在Windows下略有不同）。在Solaris下研究出的原理，一样可以用于其他平台，可方便大家进行性能调优、故障诊断。笔者书中大多数Oracle内部原理的结论，都是使用DTrace加MDB分析而得出的。
但由于笔者精力有限，而且部分结论还要对Oracle的核心代码反汇编才能得出，这将耗费更多精力，因此难免个别结论分析有误，如果各位读者朋友在阅读时发现有误之处，敬请告知，笔者不胜感谢。笔者的BLOG地址为：www.mythdata.com，有问题大家可以到该博客留言探讨。
DTrace跟踪，再加上调试工具MDB，笔者称为DBA中新的领域：“调试Oracle”。调试技术的引入，加上我们对Oracle的理解，可以让我们把Oracle原理看得更加清晰，可以达到与阅读开源代码同样的效果。这如同吹散“雾霾”的北风，让我们不再“雾里看花”。对原理把握得更加清晰，也使得调优、故障诊断更加精准。“Change”，是这两年最流行的词汇。“我们一直身处变革之中而不自知”。变革正在悄然进入DBA领域，传统的Oracle运维日渐式微，这已然是不争事实。众多处于“麻木”阶段的DBA纷纷转行。“调试Oracle”领域的出现，将是一条新的发展之路。希望本书能给大家提供一种新的思路。
第1章 存储结构 1
1.1 区：表空间中的基本单位 1
1.1.1 统一区大小表空间和区的使用规则 2
1.1.2 系统管理区大小 4
1.1.3 碎片：少到可以忽略的问题 7
1.2 段中块的使用 7
1.2.1 块中空间的使用 8
1.2.2 典型问题：堆表是有序的吗 9
1.2.3 ASSM与L3、L2、L1块的意义 10
1.2.4 值得注意的案例：ASSM真的能提高插入并发量吗 12
1.2.5 段头与Extent Map 21
1.2.6 索引范围扫描的操作流程 24
第2章 调优排故方法论 27
2.1 调优排故的一般步骤 28
2.1.1 常见DUMP和Trace文件介绍 28
2.1.2 等待事件 29
2.1.3 各种资料视图介绍 37
2.1.4 等待事件的注意事项 42
2.2 AWR概览 44
2.2.1 AWR报告的注意事项 44
2.2.2 AWR类视图 46
