在 2006 年，Oracle 宣布推出 Unbreakable Linux，同时也暗示了不会对 RedHat 进行收购，人们一直猜测 RedHat 会在 Oracle 待收购名单上，但这个事情到现在也没有发生。另外，在嵌入式 DB 领域也做了收购，将 Sleepycat 收入囊中，Berkeley DB 从此改换门庭。现在，在中国还有一只研发队伍呢。

2007 年底，Oracle 以 33 亿美金的代价收购 Hyperion，在 商业智能 (BI) 领域进一步增强自己的实力。当时在 BI 领域，Oracle 排名第七，Hyperion 第四，尽管收购之后并没有挤入前三名，但至少收获了不少 Hyperion 的客户，从长期看，也是比较划算的生意。

与收购 Hyperion 的 33 亿美金相比，收购 BEA 的 85 亿美元似乎并不太高，因为 BEA 的规模与影响力都是不小，毕竟这是第五大软件公司。可相像的是整个收购过程也遭到了 BEA 创始人的强烈抵抗。其实在 Oracle 收购 PeopleSoft 之前据说就有意向收购 BEA ，只是当时报价让 Oracle 觉得不可接受：37 亿美元。

BEA 由比尔·卡尔曼(Bill Coleman) 、爱德·斯考特(ED Scott)、庄思浩（Alfred Chuang）联合创建，公司名字就来自三人名字的首字母，这是大家都熟悉的典故。或许是因为庄思浩是华人的缘故，中国用户更熟悉他。BEA 是一家神奇的公司，其起家并赖以成名的产品 Tuxedo 与 Weblogic 都是买来的，Tuxedo 从 Novell 手里买来，三人先拿到了 5000 万美元的融资，然后借鸡生蛋，买下了 Tuxedo，到后来这东西恐怕比 Novell 市值还值钱，要说的是，BEA 也真有点石成金的本事，因为抓住了中间件领域的这个前所未有的发展机遇， 从1995 年到 2001 年，六年就成为有史以来以最快速度达到10亿美元年收入的软件公司，但是到了这个阶段之后的几年却停滞不前，无法实现更大的销售规模，产品线的单薄给 BEA 种下了苦果。来自 IBM 、Oracle 的竞争也不断加大，而开源软件 JBoss 的壮大也无形中给了 BEA 不小的压力。

如果 Oracle 能够按照预期收购 JBoss 的话，或许也就不会对 BEA 下手了。不过 2006 年 4 月，消息传来，RedHat 用 3.5 亿美元收购了 JBoss 。如果假想一下当初 BEA 能够收购 JBoss 的话，或许市场格局是另一番景象了，但是 JBoss 没卖给 IBM 、Oracle ，恐怕也不会卖给 BEA，毕竟 JBoss 创建人 Marc Fleury 更愿意保持开源精神。

在 2007 年十月的时候，Oracle 以每股 17 美元的收购请求遭到了拒绝。BEA 的拒绝理由是价格不合适，庄思浩将价格提到了 21 美元。请注意这个说法，这意味着 BEA 对其独立性并非如何看重。Oracle 一计不成，欲擒故纵，说要看看投资人的建议， 这时候，一个重要的投资人卡尔·伊坎（Carl Icahn） ，在这次收购案中起到决定性作用。

卡尔·伊坎这个人在美国号称激进投资者，也有人叫他"企业掠夺者"，大家应该熟悉这个他，这人也曾是雅虎的股东之一，给雅虎管理层搞出来不小的压力，整天喊着要炒掉杨致远。卡尔·伊坎的拿手好戏是买入公司部分股票，拿到一部分代理权，然后给董事会施压，逼迫企业卖出，获益后抽身而退。卡尔·伊坎在 BEA 股价在 13 美元的时候大肆买进，后来持有超过 13% 的股份，如果 BEA 卖给 Oracle ，必然股价上涨，从投资人的角度看，也是无可厚非的事情，作为投资人，不会对 BEA 有任何感情。投资人都是魔鬼，这话有几分道理。

买家嫌价格高，卖家嫌价格低，卡尔·伊坎倒是成了中间人，以他为代表的投资人力主卖出，以庄思浩为首的董事会虽说不愿意卖，可一看价格已经谈到可接受的地步，私下里掏出计算器算了半天自己能拿到多少利益，也就都半推半就了，当然这是笔者的演绎而已。这次交易，最大的赢家应该是卡尔·伊坎，据说获利超过 20 亿，当然股东们也都有所收获，要不怎么有人将他叫做股东权益代言人呢。

拿下来 BEA 市场之后，Oracle 在中间件领域稳居第二，相信在经历过艰苦的整合之后，将对 IBM 第一的位置发起再次冲击。

这几篇文章都用标题里都用了"战"字，收购过程看似稀奇之处，暗藏的刀光剑影很难为外人所知。而并购过程中对人员的清洗也是相当的残酷，说是大战，倒也不为过。

接下来谁会是 Oracle 的收购对象? 很多人没想到，居然 Sun 成了 Oracle 的盘中餐。欲知后事如何，且听下回分解。

• 书写历史的甲骨文--ORACLE公司传奇(1)
• 书写历史的甲骨文--ORACLE公司传奇(2)
• 书写历史的甲骨文--ORACLE公司传奇(3)
• 书写历史的甲骨文--ORACLE公司传奇(4)
• 书写历史的甲骨文--ORACLE公司传奇(5)
• 书写历史的甲骨文--ORACLE公司传奇(6)
• 书写历史的甲骨文--ORACLE公司传奇(7)

未完待续...

如同互联网时代 Paypal 黑帮一样，在应用软件领域，Oracle 公司的叛将力量同样超级强大。

可以看一下这个列表：

• Tom Siebel ，创建 Siebel 公司，2005 年被 Oracle 收购。
• Mike Fields，曾任销售部总裁，后出走创建 OpenVision 公司，1997 年被 Veritas 收购。
• Gary Bloom ，曾经的二号人物，后出走担任Veritas 公司CEO，Veritas 2005 年被赛门铁克收购。
• 克莱格·康威(Craig Conway)，前 PeopleSoft CEO ，给 Oracle 收购 PeopleSoft 带来了最大障碍。
• 马克·贝尼奥夫(Marc Benioff)，Salesforce公司创始人、CEO。Salesforce 仍然满身光环。

此外，Ray Lane，前 COO，总裁，现在是 KPCB 投资机构的合伙人。在业界的影响力依然很大(KPCB 投资的 Fortify 非常有意思）。或许，Salesforce 是 Oracle 的一大收购目标，只要危及自己或者是收购之后可以抢占更大市场，那就必然在收购名单上，估计马克·贝尼奥夫必然举起反抗旗帜，尽管拉里也是 Salesfoce 的早期投资人，但早已经被赶出董事会，而且，马克·贝尼奥夫以其人之道，还治其人之身，利用拉里的名义帮自己宣传---当年，拉里也是借着在盖茨前面发言而抛出NC的概念，才在更大范围内广为人知的。

在 Oracle 公司，拉里就是这个王国的君主，谁越靠近他，谁就更可能下台，他的一句以讹传讹的名言是"Everyone else MUST Fail"。企业发展史其实也和政治史没什么本质区别。Oracle 公司的被放逐的干将们倒是充分验证了那条著名的"彼德定律"，能力总有不能胜任你的岗位的一天，一旦能力触及天花板，达不到职位的要求，那么在 Oracle 的命运似乎只有一个，滚蛋！不卖力光等着养老那是不可能的。

写这篇文章的时候，Oracle 公司的 2、3 号人物分别是 Charles Phillips 与 Safra Catz 。Safra Catz 投资银行家出身，与拉里关系紧密，但据说缺乏管理经验，而菲利普斯来自摩根斯坦利，加入 Oracle 之前就有针对性的对 Oracle 有过深入的了解。 竞争对手都在猜测目前这两个人究竟谁能接班坐上 Oracle 一把手的位置，还有待于时间的考验，但至少，不会再次出现大清洗的局面了，毕竟这么大的盘子，再折腾恐怕要伤筋动骨。还要给帝国留一个接班人不是?

且说拉里这个人虽说对身边的高管毫不手软，倒是对公司的技术人似乎颇为仁慈。尤其是对自己的老搭档 Bob Miner 评价是相当的不错。拉里当年不是很好的程序员，但是他对技术人员颇为关心，而且自己常常自认为是个程序员，他的确有过当程序员的经历。最近几年，Amdahl 定律渐渐广为人之，但是很少有人知道，当年这个 Amdahl 公司还曾经解雇过他的往事，那时候他在 Amdahl 做程序员。

另外，尽管不懂细节，但他是个很不错的预言家，从主机时代，到客户端/服务器架构时代，到 Internet，Oracle 每次都能提前转身，抢在很好的战略位置。这要完全归功于拉里对商业需求的敏锐预知。尽管他也曾经有过不太靠谱的 NC (网络计算机)的论断，但现在看起来，倒像是一次提前但成功的预言。他也是少数真的懂得销售自己家产品的公司掌舵人，或许这一点和他的好朋友乔布斯有些相像。

• 书写历史的甲骨文--ORACLE公司传奇(1)
• 书写历史的甲骨文--ORACLE公司传奇(2)
• 书写历史的甲骨文--ORACLE公司传奇(3)
• 书写历史的甲骨文--ORACLE公司传奇(4)
• 书写历史的甲骨文--ORACLE公司传奇(5)
• 书写历史的甲骨文--ORACLE公司传奇(6)

未完待续...

从 2005 年开始，Oracle 的发展历史差不多就是其收购史。在收购仁科之前，Oracle 有的收购动作并不多。可圈可点的似乎只有一笔，那就是收购 DEC 的 Rdb ，并且从 Rdb 吸收了 CBO (Cost-Based Optimizer)技术。

直到 2004 年开始，Oracle 开始展开收购战略，这恐怕与 Charles Phillips 在 2003 年加入公司有关。数次收购都是 Phillips 操刀。

在 2005 年除了整合仁科之外，Oracle 还进行了 12 次收购（参考)，其中对 Retek 的收购达到 6.3 亿美元，对 i-Flex 的收购金额为 9 亿美元，其它的收购金额没有对外公布。这一年的收购目标大致上都是为了完善自己的在不同行业的解决方案而做。

有两个收购值得一提，一个是针对 Innobase 的收购，Innobase 是开发 MySQL 存储引擎 InnoDB 的公司，而 InnoDB 从现在来看，仍然是 MySQL 最好的存储引擎。Oracle 用极小的代价牵制住 MySQL 的潜在威胁。这是一步妙棋，堪称神来之笔。

另外一个是针对 TimesTen 的收购，这是 Oracle 对实时数据处理的尝试。不过从近几年来发展来看，TimesTen 被用户接受的程度不大，因为 Memcached 或类似开源解决方案对这个产品的冲击太大了。

收购 Siebel 之战

2005 年另一个大手笔收购是 58 亿美元收购 Siebel。如果说，收购仁科之战让 Oracle 抢到了 ERP 领域的资源，收购 Siebel 则是拿下了 CRM 软件市场的大片江山。

Siebel 公司由 Tom Siebel 伙同 Patricia House 在 1993 年创建。Siebel 在发展的过程中拿手好戏也是收购，这可能与 Tom Siebel 的销售出身有关。 要知道，当年他也是埃利森手下得力干将。据说在 Oracle 有句话，叫做谁离拉里最近，谁就最快垮台。做老板的当然不愿意看到下属抢了自己一点风头，拉里尤其如此。只是从后来的事情发展来看，Tom Siebel 和拉里似乎并无多大冤仇。

在收购 PeopleSoft 之后，Oracle 虽说也是 CRM 领域的一个参与者，但是远远排不上前三名，而此时的 Siebel 正在面临市场下滑萎靡不振的局面。与 SAP 的正面争斗没得到什么好处，Salesforce 异军突起也抢走了 Siebel 不少客户(Salesforce 创建人马克·贝尼奥夫也曾是 Oracle 的干将)。待到 Oracle 手持收购大棒前来，Siebel 竟然开城投降。相比之下，人家 克莱格·康威(Craig Conway) 在 PeopleSoft 作为一个打工者尤能抵抗到底，而 Tom Siebel 作为创建人，倒是生生的把自己的孩子送给了人。收购时，Siebel 手里的现金还有 22 个多亿，Oracle 相当于 36 亿拿下了这个竞争对手，可以说是相当的便宜。

Oracle 收购 Siebel 倒不是感受到了来自这家公司的压力，其目的也是要扩大自己的产品解决方案能力而超越 SAP。当然，SAP 的领头羊地位要超越可并非易事。

或许有人问，Oracle 收购这么多大牌厂商，如何消化? Oracle 这样的公司，本质上说，是销售驱动技术的公司，所以，销售线路的整合并非难事，都是买东西而已。至于研发方面，因为收购的厂商大多以 Oracle Database 为基础开发的软件，PeopleSoft、Siebel 都是如此，双方在收购前就已经有所合作，技术上的融合也并非太大难事。当然，这也是我个人的理解。

在 2005 年，Oracle 在产品方面没有什么太大的动作，只是发行了一个免费的 Oracle Database 10g Express Edition (XE)。

• 书写历史的甲骨文--ORACLE公司传奇(1)
• 书写历史的甲骨文--ORACLE公司传奇(2)
• 书写历史的甲骨文--ORACLE公司传奇(3)
• 书写历史的甲骨文--ORACLE公司传奇(4)
• 书写历史的甲骨文--ORACLE公司传奇(5)

未完待续...

最近稍微修订了一下《书写历史的甲骨文--ORACLE公司传奇》，本文可以看作是其续篇。在接下来一段时间，我可能会把 Oracle 这几年的发展历程做个回顾。

收购仁科之战

2004年12月13日，Oracle 公司宣布签订了以每股26.50美元、总计约 103 亿美元的代价收购仁科(PeopleSoft) 的最终协议。历时十八个月的争斗终于尘埃落定。

从 2003年6月宣布的51亿收购金额，到最终的 103 亿美元，Oracle 可以说是付出了血本。这次收购对于 Oracle 公司来说有着深远的意义。且听笔者慢慢道来。

PeopleSoft 公司由大卫·杜菲尔德（Dave Duffield）和 Ken Morris 在 1987 年联合创建，面向企业应用软件，在上世纪 90 年代发展得顺风顺水，到这场收购大战之前，在 ERP 领域已经稳坐第二把交椅。市场第一当然是SAP，而 Oracle 则远远落在后面。现在回过头看，PeopleSoft 当年能够在强敌如林的 ERP 市场有其一席之地，把客户放到第一位，用更好的服务赢得客户的心是PeopleSoft 的竞争法宝，而能做到这一点，与创始人大卫·杜菲尔德的处世之道有直接关系 。

Oracle 觊觎企业应用市场已久，苦于无法抢占更大领地，而在 2003 年，PeopleSoft 完成对 J.D. Edwards 的收购，代价是 15 亿美元，J.D. Edwards 在中型企业及制造、流通和资产密集型行业颇有一手，本来PeopleSoft 在人力资源管理方面已经是绝对的领先者，合并后，在企业应用市场，PeopleSoft 绝对超过 Oracle 处于第二位，这样一来在 ERP 领域也无疑给 SAP 相当的压力，老二当久了，谁都要做老大。话说，这样一来，Oracle 觉得在 ERP 领域要追上第二名都已千难万难，要做第一，更是无望，至于做到世界第一的位置，更是遥不可及了。因而这一领域是 Oracle 必争之地，依赖数据库这一块，虽说赚得盆满钵满，担市场增长毕竟有限，不在企业应用领域有所突破，迟早会在这个强手如林的市场上走下坡路。

如果某个领域不能战胜对手，最好办法就是收购，然后让竞争对手消失。手持大把现金的 Oracle 宣布对 PeopleSoft 展开并购，受到时任 PeopleSoft CEO 克莱格·康威(Craig Conway) 的超强力反对。康威本是 Oracle 的旧臣，曾任高级副总裁，当年也是埃利森身边红人，按理说应该和 Oracle 暗通款曲，竖起白旗才对。其实不然，当初康威离开甲骨文并非功成身退，而是被迫出走。正是出于这样的原因，新仇旧恨，难免要发起强势阻击。仁科公司上下也几乎都反对收购，明摆着一旦收购成功，Oracle 必将大刀挥起进行裁员。当然，这些因素不会有决定性作用，股东以及董事会才是决定这家公司命运的人。

这场收购战的前 16 个月可以说胜负未分，仁科抛出了若干自救的方法，大施"毒丸计划"，除了与 Oracle 对薄公堂之外，对客户发起了退款保证计划，大幅度增加福利提高 Oracle 收购成本，甚至和 IBM 结盟力求自保。

眼看着 Oracle 打赢了反垄断的案子，一场大战即将决出胜负，谁料想仁科董事竟然临阵换将，解除了康威的职务，理由是对其继续领导公司的能力失去信心，当时也有传言说董事会对康威不满有其它原因，包括其行事作风独断专行，但这个时候临阵换奖，无疑是头脑发昏。几年后回顾这个情节，真的怀疑是不是 Oracle 用了什么反间计，感觉像在看商业版的赤壁之战。

创始人杜菲尔德重回公司，企图挽救仁科。但这个时候情况已经对 Oracle 有利了，逐利的投资者们临门一脚，竟然多数同意收购，仁科束手投诚。尽管杜菲尔德坚决不妥协，但游戏规则就是如此，自己一手创建的公司从此改换门庭。

收购完成后，Oracle 裁掉了仁科 5000 多名员工，大屠杀，热忱的杜菲尔德自掏腰包建立了一只基金，帮助被裁员工就业，足见老爷子的仁爱之心。

从这次收购开始，Oracle 在企业应用软件市场上一跃成为第二名。这么大手笔、马拉松式的收购的最终成功极大的刺激了大手笔并购的信心与野心，整合仁科(包括J.D. Edwards)这样的大公司也给其带来了大量且可复制的并购管理经验。从这次收购开始，Oracle 收购战正式拉开序幕，其影响直到今天仍未散去。

• 书写历史的甲骨文--ORACLE公司传奇(1)
• 书写历史的甲骨文--ORACLE公司传奇(2)
• 书写历史的甲骨文--ORACLE公司传奇(3)
• 书写历史的甲骨文--ORACLE公司传奇(4)

未完待续...

Question：假设一家 C2C 网站，数据库中某表存储买卖双方交易的数据信息，对于一条交易来说，买卖双方数据具有一定程度的耦合性，比如卖家的状态更新对应买家的状态也会更新，对于一个中大规模的电子商务网站，架构师在设计中如何考虑数据分片的问题（假定该表随着数据的膨胀必须拆分)?

Answer：对于一个中大规模的电子商务网站，随着网站的不断发展，其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于 C2C 类型的网站，由于交易记录不容易进行水平的数据分割，因此对于这样的应用处理要再进行细分：

• 买卖双方交易的信息，具备较高的时效性，即交易全部完成后就不会再有更新，因此这部分数据可以与正在交易中的数据区分开来，并可以单独分表，定时归纳。具体的做法可以采用水平分割的数据分片技术，比如可以根据用户号码段范围进行切片，把不同的群体划分到不同的 DB 上，这样可以很好的进行横向水平扩展（Scale Out）。它可以很好的突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
• 对于正在交易中的数据，主要根据时间进行分表。如果分的更细，则可以分三个表，但是这样在事务保证方面则要复杂很多，不建议这样做。

这个问答是《程序员》杂志架构师接龙栏目的第一期的内容。提问者是我，回答者是腾讯研发总监王速瑜先生。其实我抛出问题后当时还真不知道接龙的是哪位，只是知道会是百度或是腾讯的朋友来回答，当然我也对这两家的数据处理方式都是比较感兴趣的。最后刊登的内容或许让很多人觉得不过瘾 -- 如果能更详细一点就好了(毕竟还有其他问题呢)。不过能够引发思考就好，这也是这个栏目的初衷吧。

对这个问题或许可以补充的是，切分或许还算是容易的事情，但是切分后用户对数据的查询多少是有点麻烦。一旦要查询历史交易信息，则必须考虑跨多个数据分片获取数据并排序的问题。交易中的数据与交易完成的数据是否做切分，是有必要根据自己的实际情况仔细衡量。要注意如对交易中的活动数据单独存放的一个表中，则还是不可避免的要产生 I/O 热点问题，而且，这个表实际上变成了一个数据队列(新的瓶颈)--新生成的交易进来，完成的交易删除或归档。这样产生的双重 I/O 压力不容忽视。

当然，这个问题的前提限制了回答的发挥，其实在设计初期也可以考虑买家信息与卖家信息分别放入不同的表中，然后对这两种属性的表再进行切分，这也是可选的途径，这样的开销是每笔交易会重复存储一条记录，而记录的变化也要在两个表中更新。对数据的一致性维护有一定的挑战。这似乎是个只带来额外开销的办法？其实也有益处--索引的设计起码会更简单一些，而用户对交易记录的定制查询也会更加方便。

数据分片(或 Sharding) 现在几乎是每个网站架构师都必须要考虑的基础问题。多数情况下，分片的粒度和方式取决于业务，慢慢地快变成可意会不可言说的话题了，你有什么建议或意见不妨留言说说。

--EOF--

为了避免误导，对于数据量不大的站点，首选如何利用好 Cache 吧，分片只是手段，不是目的。

对国内互联网用户来说，OpenDNS.com 这个服务在技术圈子里还是有些知名度的，当然这要归功于国内电信服务商对域名的无耻劫持行为。

OpenDNS 的员工 Richard Crowley 在 Velocity 2009 上和与会者分享了关于 OpenDNS Stats 服务的实现。当时的数据是每天有 140 亿次的 DNS 查询，而现在从公开的数据看，每天已经超过 180 亿次查询。这个 PPT 的内容就是讲 OpenDNS 是如何处理并统计这些查询记录的。

主要的策略分两步，第一步，根据网段切数据；第二步，聚合与存储。体现到 DB 层面是给每个网段单独分配一个表，尽可能的让表更小，让主键更小。

选择合适的方式存储域名。如果表使用 auto_increment 字段做主键是不太合适的做法--不同的引擎都有或多或少的锁问题，OpenDNS 采用域名的 SHA1 摘要值用来做域名的主键(SHA1 是20个字节，倒也不算浪费空间)。用了两台机器，每台 48GB 左右的存储空间，另外通过跨在 8 台机器上总共 28GB 的 Memcached 来避免对数据库的读操作。

对于聚合数据的进程会产生内存溢出的问题，采取的办法是清空内存，重启进程（而不是释放内存)的思路。利用了 supervise 这个小工具来做到。这地方其实值得商榷。

开始曾发现 80% 的 I/O 等待表的打开与关闭上。通过 Strace 发现存在大量的 open() 与 close() 调用。通过設置 ulimit -n 600000 解决(关于 ulimit 参数的意义参考。这意味着 OpenDNS 用了大约 60 万个表(网段)！(?) 这的确是比较极端的做法。

而在 DB 存储引擎的选择开始用了 MyISAM ，也是不合适的，通过迁移到 InnoDB 速度得到了很大提升。这似乎是缺乏评估与规划的表现，或许 OpenDNS 在这方面并非十分擅长。

(Copyright by Richard Crowley )

上图从右向左看，查询日志通过 rsync 同步到 Stage 1 的服务器上（位于旧金山)，根据查询到的域名把查询日志映射为中间文件，然后把数据文件同步到 Stage 2 的服务器，启动聚合进程把中间文件读入，修剪(Pruning)进程把拼装好的 SQL 语句写入 DB。整个步骤其实暗合 MapReduce 的思路。虽然不是严格的 MapReduce 实现。

听说国内提供类似服务的 DNSPod 因为上次的暴风长老事件受到了广泛瞩目，前不久成立了公司旨在专门提供智能 DNS 服务。不知道每天查询量有多大。[Updated: 见楼下 DNSPod 站长的回复 "DNSPod请求数每天20来个亿" ]

--EOF--

几句题外话：因为逐渐远离一线技术环境，为保持对技术的兴趣，每天多读一些 PPT 也是有乐趣的事情，或许一年没有敲多少条命令，但是看的 PPT 恐怕没有几个人比我多。看到一些还算有趣的 PPT 就做点笔记和大家分享。或许对人有用呢。

Updated：Google 开始提供 DNS 了。Google Public DNS

还可以参考一下这篇：OpenDNS MySQL abuses，另外，Richard Crowley 已经在2010 年2月份从 OpenDNS 离职...

看到有反馈说到《Oracle性能诊断艺术》中对于 Instrumentation 这个词的翻译问题。说实话，对这个词的处理当初挺让我头疼，这是个可以意会但很难用一个中文词汇对应的术语，一些翻译词典或是已有的翻译作品对这个词的处理也是五花八门。在图灵著译俱乐部里面提问得到很多回答（这里要致谢！）。权衡再三，最后根据整个章节的重点以及上下文选择用 "性能测量"。

我不喜欢用有些人说的测试领域内所用的术语"插桩"，实在是有点诡异。当然，如果这个词不翻译的话，或许更好。其实很多计算机术语容易受到早期译者的影响，比如关系数据库的 "Lock" 这个词 ，动词的时候，很多译者喜欢翻译成 "封锁"，个人觉得实在是累赘，就是锁就行了嘛，为什么非要"封"呢?

另一个比较难以处理的就是 "Profiling" ，根据维基百科的解释 ，这个词指"动态程序分析的一种形式...根据程序执行收集到的信息调查程序的运行行为，通常用来查找程序中的瓶颈"。最后我用了"剖析"。(Updated: 中文是 "性能分析"。不过我觉得似乎有点容易混淆。)

这两个词很有趣，任何一个程序或者软件项目构建的初期，如果没有考虑 Instrumentation ，在程序或项目交付后，又不能做 Profiling ，那么这个程序或者项目肯定会是灾难。所以，能对 DBA 着重强调一下这一点或许要比看更多的同质化内容更有价值。

在这本书的最后定稿的时候，编辑来信要求确认术语的统一，对于 "Hash" 这个词，要求用统一的术语"散列"，最后我们几位编辑极力坚持用"哈希"这个词(当然，最后用了"哈希")。大部分的数据库图书，尤其是 Oracle 相关的图书，这个词已经是约定俗成的了。所以，说起术语标准化，个人看法也是术语对应列表用来做指导而不是生搬硬套。

翻译需要技术，更需要艺术。这活儿，真的不好干。

--EOF--

更新：Twitter联合创始人 Nick Bilton 说过这样一句话"Early on our biggest problem was that we didn't have any gauges into the system and we didn't have metrics, so we were kind of flying blind. The way we got around it was to instrument the entire system so we could see what was going on" (refer)。可见缺少 Instrumentation 会带来多么严重的问题。

几周前，《Oracle性能诊断艺术》（Troubleshooting Oracle Performance 的中文版）终于面市，现在线下的实体书店应该也可以买到了。这半年来一直有朋友在问什么时候能够出版，现在总算有个交代了。

关于中文版书名，图灵出版社编辑们费了不少心思，尽管最后敲定的书名中"艺术"两个字似乎有点托大，不过我个人觉得也还算好，恳请读者把重点放到内容的汲取上而不是和书名较劲。

这本书从接手到现在也快一年的时间了，整个过程尽管有辛苦，也已经成为过去式。这或许是我最后一本翻译的图书--除非以后出版自己写作的东西(如果内容还能过得去的话)。

如果朋友们针对书中内容有任何问题，可以访问 支持页面留言反馈或者发邮件给几位译者。相信译文中仍有欠妥的地方，译者将尽量提供技术支持以及延伸内容。

--EOF--

感谢这本书翻译过程中给予我们帮助的所有朋友们，有你们的支持，是几位译者的幸运。