感谢 Troubleshooting Oracle Performance 作者 Christian Antognini 给中文读者的寄语。现在此书译稿已经进入排版阶段。期待能早日面市。

下面是 Chris 的邮件内容：

I still remember when I saw for the first time part of my book translated in Chinese. I was looking at the news provided to me by Google Alerts when, among the other links, there was a link related to “Troubleshooting Oracle Performance” (this is one of the terms I monitor through Google Alerts) pointing to a Chinese page. I opened the referenced page and, it goes without saying, I was not able to read it. I just recognized the cover of my book and its name. So, I put the first part of the text in yet another Google application to let translate it to English. Then I understood what it was all about. It was part of chapter 1 of my book. Amazing!

If you have a copy of the Chinese edition in your hand, it means that the translators managed to finish their work. I know for sure that it was a huge undertaking and, therefore, I would like to thank David Feng、Jame Tong、Yiwen Hu and Yi Zhu for doing it. I know that they spent a considerable amount of their valuable time to translate the text. Thanks to them, more people will be able to learn something about Oracle Database, how to use it efficiently and how to approach performance problems. And that is something that makes me proud. I hope you will be one of them.

Christian Antognini
August 14, 2009

我还记得当我第一次看到这本书的部分内容翻译成中文的那一刻。当时我在查看Google Alerts服务提供给我的新闻，在这些链接中，有一条和”Troubleshooting Oracle Performance”（这是我通过Google Alerts服务监控的关键词之一）相关的链接指向一个中文页面，我打开该页面，不用说，我看不太明白。我只是知道和我的书有关。所以，我把第一部分内容用Google的另一个应用(Google翻译)译成英文。然后我明白这是怎么回事了。这是我的书中第一章的部分内容。令人惊讶！

如果有一本中文版在你手里，这意味着译者已经完成他们的工作。我确信那是一项艰巨之事，所以，我要感谢冯大辉、童家旺、胡怡文以及朱一等几位译者的工作。我知道他们花费了大量宝贵时间进行翻译。感谢他们，更多人可以学习关于Oracle数据库的知识、如何高效使用以及如何解决性能问题。这让我感到自豪，我希望你也是从中获益的读者一员。

Christian Antognini
August 14, 2009

（邮件内容翻译的比较匆忙，见谅)

–EOF–

OakTable Network本身就是一群喜欢相互讨论并和有类似想法的朋友交往的人。更确切地说，是一群致力于对Oracle数据库技术进行科学探讨并爱追根究底的家伙。

这一切都始于1998年的某个时候，那时一帮Oracle专家，包括Anjo Kolk、Cary Millsap、James Morle和其他一大群朋友开始每年以各种借口进行一到两次聚会。每个人都会带来一瓶苏格兰或波本威士忌，作为回报他们也赢得了在我家里某些地方打地铺的权利。
大部分时间我们围着餐桌闲坐，周围布满了电脑、网线、纸和其他一些东西，讨论Oracle，聊聊趣事，使用数据库领域新的并且更优异的方法做实验。在2002年的春天，所有条件更加成熟。一天夜里，我意识到我有16位世界知名的Oracle科学家闲坐在我的餐桌旁。我们三四个人挤在一个房间睡觉，甚至不得不在早上借邻居的淋浴。Anjo Kolk建议我们把自己叫做”OakTable Network”（名字来源于我的餐桌），大约两分钟以后，我们注册了域名http://www.OakTable.net。

James Morle 现在和他的妻子Elain一起维护这个网站，虽然或许网站没有像预期的那样保持经常更新，但至少可以用来提供链接、名字等等，这就挺有用了。我们经常在上面进行问答挑战。

挑战是我们在讨论过程中偶尔发生的事情。询问我们任何关于Oracle的技术问题，如果我们不能在24小时内提供答案（不管是对，错或解决办法），提问者都将得到一件T恤，代表他(或她)打败了OakTable。

这个挑战，尽管有时没有像我们想要的那样进行，也许是因为它看起来好像是我们喜欢被自己回答不上的问题挑战。不过它的反面却是真实的，那就是我们的目的是解答任何人的疑问，不管这些问题看上去是多么的”简单”或是”容易”。

注：这是 Mogens Nørgaard 在 Troubleshooting Oracle Performance 一书前言中介绍 OakTable 技术组织的来龙去脉。OakTable 是 Oracle 数据库领域最有趣的一个技术组织，他们以运用科学方法（以及科学团体的伦理）从事所有活动。其成员都是顶尖的技术高手，现有大约70位成员，遗憾的是，或许因为语言的隔阂，还没看到来自中国的成员。Ooops , 前言真的不好翻译…

–EOF–

继续贴出 Troubleshooting Oracle Performance 一书第十二章《优化物理设计》的翻译稿的部分节录。最近真是筋疲力竭。翻译不止是考验技术水平、英文水平、中文驾驭能力，还有耐心和信心。

(此书中文名字还未敲定，要不大家帮着命名一下?)

段头块的争用

每个表和索引段都会有一个头数据块（header block）。这个数据块包含以下元数据：关于这个段的高水位（highwatermark）的信息，组成这个段的区间（extent）的列表以及关于空闲空间的信息。为了管理空闲空间，根据使用的段空间管理方式的不同，头数据块会含有一个空闲列表（freelist）或者一组包含自动段空间管理（automatic segment space management）的信息的数据块。比较典型的情况是，段头数据块在多个进程并发地修改其内容时会发生争用。注意，头数据块在以下几种情形下将会发生修改：

• 插入语句使得有必要提高高水位
• 插入语句使得有必要分配新的区间
• 删除、插入或更新语句使得有必要修改空闲列表

解决这些问题的一个可能思路是，对这个段进行分区以将压力分布到多个段头块上去。虽然有时候根据负载以及分区键值（partition key）其它的分区方式也可以实现，但是在大部分时候，可以通过散列分区实现这一点。然而，如果是由于第二或第三种情形导致这个问题，还可以使用其它的解决办法。对于第二种情形，可以使用更大的区间（extent）来解决。这样，新的区间分配将很少发生。对于第三种情形，空闲队列（freelist）可以被空闲队列组(freelist group)移动到其它数据块，这对于使用自动段空间管理模式(automatic segment space management)的表空间不适合。事实上，在使用多个空闲列表组的时候，空闲列表就不再被存储在段头数据块（segment header block）中了（它们被分布到与参数FREELIST GROUPS数量一致的数据块中，这样在它们上面的争用将减少，而不仅仅是将争用移往别处而已）。另一个可能是使用自动段空间管理的表空间而不是空闲列表段空间管理的表空间。

注意：长期存在一个关于Oracle数据库引擎的神话是，空闲列表组只有在使用RAC（Real Application Cluster）的时候才是有用的。大谬。空闲列表组在任何数据库中都是有用的。之所以特别强调这一点是因为我看到听到这种错误信息太多次了。

其实我一直想尝试用一点比较新的语言，比如最后一句，用”这种事儿我都听过N次了”，效果可能更好。但，还是放弃了。

–EOF–