Oracle资深技术顾问10年铸剑
领悟IT技术，品味人间百态
生动的案例实景 严谨的技术描述 鲜活的人生感悟 轻松、调侃、诙谐的语言
本人的确对Oracle技术情有独钟。因为在IT领域的众多专业技术中，我迄今仍然认为关系数据库技术是最富有数学理论基础，也是最充满美感及和谐的技术。试想关系代数多么系统而严谨，SQL语言又多么层次分明、韵律十足！成为关系数据库技术鼻祖和翘楚的甲骨文公司的一员，可访问Oracle的大量技术资源，面对国内各行业的大量客户，也许是自己的人生定位了。
我其实只懂点IT（挨踢）知识，IT里面其实只懂点甲骨文，甲骨文里面其实只懂点数据库，数据库里面其实只懂点SQL，SQL里面其实只懂点索引――你才是真正的专家啊！”
如果我优化得太好，第一，客户技术人员和开发人员反而会感到很难堪，因为反衬他们原来做得太差了。第二资源消耗会大大降低，会凸现客户在硬件采购方面盲目追求大容量、大处理能力的奢华了。第三，我们公司的销售可能也有意见。你怎么一次就把它优化到头了？还指望签更多的单子呢。更有甚者，有一次因为工作做得太到位，反而被客户列为不受欢迎的人。
《品悟性能优化》以数据库性能调优作为切入点，通过对案例故事实景的生动形象论述，介绍了数据库建设和运维优化的方法论，叙述议论结合，管理技术兼备，语言风趣流畅。作者专业技术积累深厚，善于总结提炼升华，简洁生动描述复杂问题背后“难以忽视的真相”。
作为老朋友，翻阅此书，能感受到一个跃然纸上、鲜活而立体的作者：一位对先进IT技术充满激情、渴望和执着追求的技术专家；一位对客户富有责任心、称职得有些“越位”的IT服务人员；一位真性情，善于将技术观点寓于生动故事中的传道者。
第一次看到枯燥的Oracle技术能以大量案例形式，以轻松、调侃、诙谐的语气写成这样，很有意思，也值得一看。还有与作者的好多同感：在IT系统中，技术与管理并重；应用设计、开发其实对IT系统质量影响大；基础技术的运用很重要……
《品悟性能优化》中生动叙述的大量故事，以及对IT行业、社会的大量积极向上、也充满一定忧患意识的有感而发，我想也是本书吸引读者的一大亮点。一名IT技术人员，不仅能深深品味出具体技术在实际应用过程中的体验，而且能对技术之外的事物充满感悟，的确难能可贵。我很欣赏本书的主题和定位：领悟IT技术，品味人间百态。
作为在Oracle中国公司服务部门就职多年的一名资深技术顾问，作者集多年驰骋在国内多个行业的经历和经验，“十年磨一剑”，以性能优化这一最容易引起业界各层次人士所关注的话题为切入点，实际上阐述了自己在架构、设计、开发、运维，甚至IT系统建设理念、文化等诸多方面的思考和独到见解，的确能引起IT从业人员的深思并受益。
我与作者曾经同在一个研究所工作，也都从事过与数据库技术相关的工作。这次得知作者编写了一本基于多年在Oracle数据库领域耕耘的经验之作，甚感欣喜。于是，第一时间就快速浏览了全书概貌，并精读了部分章节，很快就为这本不仅包容了大量技术内涵，同时又具有很强可读性的书籍所吸引，并欣然受邀为该书作序。
多年来，我一直在从事IT系统总体规划、论证、组织和建设工作，深深感受到方方面面对高品质IT服务的强烈需求，特别是对大量数据中心建设之后海量数据库系统的高性能挑战。如何有效解决性能问题？先进的计算理念、高性能的硬件平台和系统软件固然是重要的基础设施保障，但就像作者在书中多次所言，IT系统的整体规划，特别是应用系统的设计开发，才扮演着更重要角色，尤其是大量基本技术的合理运用将起到至关重要的作用，我想这也是作者在书中一直在诠释的一些重要观点。在崇尚云计算和节约型发展的当今社会，各行各业都在追求用信息和信息技术精确调控物质和能量的发展模式，由追求量转变为追求质，作为这种发展模式的重要手段，把IT系统本身的设计、开发等工作做得更精、更细，应成为IT从业人员矢志不渝追求的目标。
我对云计算的发展途径和面临的挑战长期关注。根据国外IDC组织的调查，企业最关注的云计算话题首先是安全性问题，？居第二的是各种各样的云计算中心服务的质量即性能问题。可见，IT系统性能不仅是业界所始终关注的话题，而且也是未来新的计算理念和架构运用的重要基础。也如作者在“架构和性能优化”一章所言：系统架构在某种程度上就是为性能优化服务的，而日益复杂的系统架构，又带来了更多富有挑战性的性能问题和性能需求。
浏览全书的另一大感触是全书丰富的案例和各种翔实的数据，这些来自作者亲身经历的国内银行、电信、政府等行业和部门大量一线IT系统的实际案例，不仅验证了相关优化技术的运用过程，凝结了作者多年的实际工作经验和感悟？对广大一线IT从业人员也一定大有裨益。如作者所言，案例也折射出一些IT系统技术之外的管理、体制等方面的问题。书中生动叙述的大量故事，以及对IT行业、社会的大量积极向上、也充满一定忧患意识的有感而发，我想也是本书吸引读者的一大亮点。
一名IT技术人员，不仅能深深品味出具体技术在实际应用过程中的体验，而且能对技术之外的事物充满感悟，的确难能可贵。我很欣赏本书的主题和定位：领悟IT技术，品味人间百态。 中国工程院院士：李德毅
第1章 从两个案例开始
有一次，我在给客户讲课时，围绕一个技术专题，展开了一个案例的描述。也许是因为讲得太绘声绘色，太让客户着迷了。课间休息时，一位客户走到我面前道：“罗老师，你的案例讲得太精彩了。说实在的，我只记住你讲的故事了，你的案例要表达的技术原理我倒记不住了。”
尽量将枯燥但非常重要的Oracle技术和概念，通过案例进行剖析和经验分享，是本书的重要目的和风格。因此，本书第1章就将剖析两个风格迥异的案例，从中总结性能优化的一些共同规律，例如很多复杂问题其实是一些简单原因导致的。同时读者也可自己体验两个案例的差异性，并从更深层次理解不同的IT系统建设理？带来的不同结果。
1.1 关于案例的说明
凡事都有利有弊。特别是在解剖性能优化、故障诊断的案例时，实际上是拿客户的系统在做靶子，有揭客户的短之嫌。况且，作为Oracle服务人员，我们的服务对象几乎都是关系到国计民生的重要IT系统，按照职业操守和安全保密原则，我们不能将这些系统的信息外泄。
因此，在本书中，关于案例的叙述，我还是斟酌再三，希望既不引起麻烦，又能生动、活泼，有效说明有关技术问题。于是，决定采取如下策略：第一，不对任何案例直接引用客户名称和具体系统名称，最多只描述行业和企业性质。第二，只描述技术细节，尽量不涉及太多的业务背景。但有些技术细节，比如表名、字段名等将保留原汁原味。一方面恕我无精力和时间去刻意加工处理，另一方面也为了让案例保持一定的真实性。即便碰巧是您熟悉的系统，也请原谅我们只是为了讨论技术问题，别无他意。希望我的用意您能理解，也希望您千万别对号入座。
本书故事并非虚构，如有雷同，亦属巧合。
1.2 体验日本人工作风格
2007年春节过后第一天，作为Oracle咨询顾问又开始了机场、酒店、客户现场三点一线的奔波生活。此行是去一家日本跨国汽车企业的中国公司，现场解决一个困绕其某重要系统很长时间的严重性能问题。第一次与日资企业合作，第一次去体验日本人的工作风格，第一次零距离接触当年最畅销车的生产基地，难免有些许激动与期望。
在现场的一周时间，在亲身感触、深入分析该系统的过程中，第一次对日本人的工作风格有了切身体验。尤其本人多年在国内多个行业从事IT系统服务工作，不同的文化背景、不同的做事风格，强烈的对比和感悟油然而生。
1.2.1 问题现象及解决过程
系统的具体问题是数据库服务器的CPU利用率一直居高不下，经常达到100%的峰值，直接导致了该公司各经销店对该系统访问速度的下降，并最终影响了客户服务质量。该问题也引起了日本总部的高度重视，他们每天都在远程监测分析系统的运行日志，但问题一直未得到解决。
本人在现场的第一天（周一）上午，在逐渐熟悉系统环境之后，凭借相关专业知识和类似经验，很快就诊断出问题的症结所在：大量重复SQL语句的Parse操作，极大地消耗了CPU资源，即语句共享性差。该类问题是影响系统性能的一个普遍性问题，尤其在并发访问量非常大的交易系统中。
问题的根源是应用程序，但可以通过数？库系统参数调整，在一定程度上得到缓解。鉴于该系统是日本公司总部开发的，应用软件改动的工作量和难度较大，本人建议采取简单可行的系统级方式，即只修改一个系统参数。
在该公司日方、中方人员对解决方式进行了3天研究，尤其是进行风险评估之后，终于在周四上午10：00，实施了修改动作。效果立竿见影，CPU利用率马上由原来的80%均值下降到40%左右。特别是通过对周四和周一的各方面指标进行对比分析之后，都验证了优化的效果。
以下是当年的优化效果对比图。
优化前的CPU利用率
优化后的CPU利用率
1.2.2 日本人严谨、细致的工作风格
上述问题的技术原因有些深奥，但修改动作很小。本人与客户技术人员笑言：本人此次的咨询报告，洋洋洒洒50多页，其实最管用的只有如下一条语句：
SQL> alter system set cursor_sharing='SIMILAR'；
但就是为了这一条语句，日方一直反馈到日本总部，反复评估了3天，才同意在现场实施。实施之后，日方马上在应用层面全面评估、对比分析实施效果，同时要求我在Oracle数据库层面也拿出各种分析对比数据。日本企业严谨、细致的工作风格让我第一次有了切？体验。
1.2.3 日本人的IT投入观
读者看到上面的CPU利用率图后一定会惊讶地发现：该系统是运行在Windows 平台上！
的确，该系统是运行在一台当年已经被Dell淘汰，价格只有五六万人民币的最低端服务器的Windows 2000平台上，很难想象就这么一个硬件平台，居然能支撑该公司整个中国市场客户关系方面的业务运行，数据规模也达到了数百GB。如果该系统是由国人开发、运行的，尤其是出现这样CPU利用率高的问题，肯定毫不犹豫地升级到价值数百万元的高档UNIX服务器了。而现在仅仅通过一个参数的修改，资源消耗？经得到大幅度下降。由于该系统本身的设计、开发总体质量高，预计该系统在同等平台上至少能运行好几年。
这就是日本人的IT投入观：宁可以每天万元的价格聘请Oracle顾问来解决问题，也要尊重事物的自身规律，不乱花一个子儿。
1.2.4 该系统的总体感觉
一个IT系统质量的高低，关键在于应用软件设计和开发质量的高低。很多同行都知道本人擅长查找各种应用系统问题，很多人一见SQL语句，特别是很长的SQL语句就吓得躲开了。我是一见到SQL语句，就像打了鸡血一样激动。但是此次在现场整整5天，让本人“失望”？是无用武之地，居然没有发现一条存在明显技术问题的SQL语句。而在国内大多数IT系统中，低质量、甚至业余错误的SQL语句比比皆是。仅从这一点就可以看出，该系统设计开发人员对系统倾注了多少心血。虽然上述语句存在共享性方面的问题，但该系统总体上真是一个设计、开发非常严谨的高质量的专业化系统。就如同日本人制造的电器一样，精巧而且质量高。
这就是日本人：并不盲目追求大而全，如果使用什么技术，就一定使用得非常专业、非常精细，将这些技术的作用发挥到极致。尤其是重视基础技术使用的扎实性。
而相比国人开？的系统呢？什么都敢用，尤其是什么新的、大的技术都敢用。但什么都用得不是那么精细、那么专业。本人一直在强调一个观点：如何在系统工程的总体层面综合评估各种技术运用的合理性，是国内整个IT行业都需要深入思考的方法论问题。
该系统存在什么问题呢？该系统最大的问题是由于最初是针对泰国、马来西亚等规模相对较小的市场而设计开发的，导致设计风格上不够大气。就像他们公司生产的车一样，也远没有美国车、德国车那么气派和大气。面对中国这样的大市场，数据规模和访问量的急剧增加，应该在超大型规模数据库（VLDB）的高度，？重新审核和评估现有系统的设计。例如分区技术、并行服务器的应用，从而满足高性能、高可用性、扩展性、易管理性等各方面的严峻挑战。
但这就是日本人的理念：我会的、需要的，就一定使用到极致，否则我就根本不用。——精明，但又有点迂腐。
1.2.5 在日本企业暖意洋洋的一幕
本人那次在日资企业现场服务期间，适逢该公司荣誉董事长从日本飞来亲临视察。周四午饭之后，本人巧遇这位德高望重的老头在接见该公司近百名中层干部并合影留念，在一片“茄子”声之后，正准备乘车离去。本人饶有兴趣地在一旁观？他们送别的情景。首先没有想到的是，堂堂荣誉董事长居然连该公司最畅销的高档小车都不坐，而是带着几位随从乘坐一辆普通面包车。在公司综合大楼前，近百名日方、中方人员集体列队热情洋溢地鼓掌为老头送行，老头也在车里满面春风地频频招手致意，车一直开出大门近500米，拐弯离开了众人的视线，老头致意的手才回到车里，近百名送行的人群也才停止招手，渐渐散去。
这种暖意洋洋、充满人情味的场景，真不是做秀，也把本人感染了。什么叫日本企业文化，什么叫日本企业的荣誉感和凝聚力，什么叫日本人把企业当家的精神。本人零距离感触到了。
1.2.6 也谈强国梦
有一年，电视上播放了一个好像叫《大国崛起》的系列政论片，我没有看过，只是在报纸上偶尔看了一些该片的解说词。强国的确是中国人梦寐以求的事情，国人也喜欢高谈21世纪是中国人的世纪。但最近看过一篇文章，一位法国人就对这个观点很不以为然，认为如果中国不能对世界输出有价值的观念，21世纪就不可能是中国人的世纪。
本人不是亲日派，也的确不喜欢日本一些人有点迂腐的文化观尤其是历史观。但日本人对现代科技执着、严谨、务实、有序的追求精神，的确为全世界所乐道和？可，也是日本成为世界强国的根本所在。
本人认为，中国经济GDP、税收的高速增长，众多的高楼大厦、高速公路，甚至在全球都领先的高速铁路，只是成为强国的基础条件。真想成为强国，一定要有兼收并蓄世界各民族优秀品质的博大胸怀，一定要去除那么多的浮躁，有更多的务实、缜密和细致，而且将中国传统优秀文化与现代科技实现完美的融合，才能对世界输出有中国特色的、真正影响世界的价值观。到那时，强国梦才指日可待。
作为IT从业人员，如果未来有一天看见国内某个系统出现问题的时候，国人不再首先是高谈政治、责任问题，也不再乱拍脑袋做决定，不再一天到晚想着一定要用最先进的IBM 780、IBM 595、DS 8300，而是能冷静客观地分析问题的本质，真正能以建设节约型经济、和谐社会为目标考虑一切问题时，我认为，这才是真正强国的表现。
1.3 国内某大型银行故障的解决
2006年本人几乎满世界飞了近一年，2007年1月份笔者回到北京的某一天，刚想稍微放松一下，手机里传来了老板的工作安排：明天赶紧去国内某大型银行数据中心，接替已经连续工作了几十个小时的两位同事，处理该行的紧急故障。
1.3.1 天塌下来一样的故？
第二天一大早赶到客户现场，与又坚持了一个通宵的众多客户、同事们坐在了一起，讨论故障的最新进展和下阶段工作安排，也开始全面了解此次故障的来龙去脉。
（1）日终批处理性能问题——导致业务停顿半天
此次发生故障的系统与股票、基金相关。当年股市、基金的火暴，使得交易量急增，在周二的日终大批量数据处理出现严重性能问题，70多万笔交易的日终处理居然运行了10多个小时，一直到第二天中午12时才完成。导致第二天上午该行全国网点的股票、基金交易被迫停止。
（2）数据误操作——导致丢失？百万记录
也许是因为连续几十小时分析、诊断上述问题的疲劳所致，客户技术人员在周四下午2点多进行后台操作时，又不小心把生产环境当成测试环境，将一张核心业务表进行了truncate操作，几百万的客户交易记录全部丢失。全国业务周四下午被迫提前一个多小时结束。真是雪上加霜，屋漏偏逢连阴雨……
幸运的是，通过系统级和应用级的多种措施，同事们和客户经过近10个小时的抢救，几百万数据终于得到了恢复。
但是，日终批处理性能问题仍然没有找到根本原因，依然可能爆发10多个小时无法完成日终处理的严重故障。
1.3.2 故障原因其实很简单
本人在碰头会上，一边听客户介绍下一步的工作安排，一边通过邻坐的同事们了解故障的技术细节。以下是系统的大致结构和问题现象。即该系统日终处理时，将存储在Oracle数据库中的一天交易数据（70万笔记录）大批量抽取到应用服务器中进行加工处理，并将处理结果返回存储到Oracle数据库中，但处理时间长达10多个小时。
毕竟同事们都是在Oracle工作多年的资深专家了，他们早就捕捉到了问题的具体症状：SQL*Net more data from client等待事件非常高，也基本分析了问题的原因：数？库服务器负载非常低，是应用软件没有提供给Oracle足够的处理请求，导致吞吐量太低。同事们已经在降低批处理量、优化并行处理策略以及监控分析等方面提供了多种方案。
本人此时一边听会议发言，一边打开了笔记本中的Oracle联机文档，详细分析导致SQL*Net more data from client等待事件的具体原因。
原因1：网络瓶颈
由于网络瓶颈，导致无法让Oracle吃饱，吞吐量太低。而此时数据库服务器和应用服务器的负载应该都很低。
原因2：应用端的资源瓶颈
由于应用端的资源消耗太高，无法及时向Oracle发送服务请求，同样无法让Oracle吃饱，吞吐量太低。
在该系统中，应用服务器资源消耗也很低，不像第二种情况，而非常类似于第一种情况。网络有问题吗？我带着疑惑，与众多同仁们来到了实际的测试环境。首先初略了解了测试结果和应用软件情况，虽然觉得应用软件在并行处理技术的运用方面有值得优化之处，但还不至于导致70多万笔记录要运行10多个小时。本人曾经在另一个银行项目上见证了客户3000笔/秒的数据加载量。如果进行换算，70万笔应该在4分钟左右就完成。难道网络真有问题？我的疑问马上遭到客户否认：网络传输速率测试达？了6MBps以上，符合百兆网的传输指标。
本人仍然不死心，坚持请求客户再测一次：数据库服务器到应用服务器一个600MB的文件，1分半钟，传输速率为6.6MBps，没问题。我还不死心，“再测一次另外一个方向，从应用服务器传回到数据库服务器的速度。”怪异的现象出现了：刚才1分半钟传完的600MB文件，现在却一个小时都传不回去。正好解释了为什么日终处理时，从数据库查询的速度不错，而往回插入数据时却慢得让人无法忍受。真是网络问题！
终于，客户在下午更换了应用服务器，解决了网络瓶颈之后，将100万条记录进行日终批处理，最终仅花费了14分钟多。
故障准确定位并彻底解决！
最终听硬件工程师介绍是该网卡在100M/1000Mbps自适应功能方面出了点问题，问题的解决简单到其实只需要重新启动一下主机服务器。
1.3.3 故障的启示
启示1：团队合作的重要性
本人周五才去现场，据了解此前公司老板们已亲临现场，与客户的领导共同分析问题，进行了大量的技术资源调配，先后调动了公司两个部门的5位技术人员。在故障解决过程中，Oracle公司和客户技术人员共同集思广益，充分体现了团队合作的重要性。我只是扮演？最后一棒冲刺的角色，正是因为大家前期连续几十小时的分析和跟踪，逐步缩小问题范围，才实现了最后故障的准确定位。
启示2：性能调优方法论的重要性
性能问题的诊断是涉及硬件、网络、系统软件、数据库、应用软件各个层面的问题。正确的方法论应该是：首先，要有站在总体高度的全局观。其次，应该采取自底向上的策略，先仔细检查硬件、网络层面相对简单的问题，再深入到系统软件和应用软件相对复杂的领域。
在初步诊断出是网络问题后，客户领导就在感慨，当初为什么偏偏忽略了仔细检查网络传输效率的问题？？家都聚焦在数据库系统、应用软件上苦思冥想。
本人为什么会死究网络问题？另外一个重要原因是当年连续在几个项目上被网络传输速率所困扰。可见，经验在性能问题的处理上也非常重要。
启示3：任何问题的解决也许就靠最后一点狠劲
如前所述，其实大家已经基本确定问题的症状和原因的大致范围，包括已经进行了网络传输效率的测试。本人唯一多了的一个想法就是：再测一下另外一个方向（从应用服务器到数据库服务器）的传输速率。世界上的很多事情也许都是这样：再努最后一把力，认认死理，就豁然开朗了。所以，IT技术人员也经常给人以好较劲的印象。
启示4：Oracle联机文档的重要性
很多客户都以为：Oracle专家一定要依靠很多神秘的公司内部文档和资料去解决一些棘手的技术问题。但此次故障的最终解决，Oracle技术人员根本没有访问公司知识库，完全是依靠公开的Oracle联机文档，根据对具体等待事件的分析，定位了问题的范围。
再次给众多客户一个建议：要想成为Oracle专家，每天坚持看Oracle联机文档一个小时！）——一个蕴藏了丰厚知识和经验的宝藏！
启示5：优化的无止境
根据我们的经验，日终批处理性能还能大幅度提高。100万条记录的日终批处理时间应该可以很容易优化到10分钟之内。这些优化措施包括以下几种。
改变计算架构和编程方式。即在Oracle数据库中，通过PL/SQL实现主要业务逻辑，一方面充分发挥Oracle数据库自身的强大计算能力，另一方面将网络的往返传输量（round trip）降到最小。如果早采取这种架构，本次事故根本就不可能发生。
改进并行处理策略和调度机制，更充分地发挥资源利用率，提高吞吐量。
Oracle针对大批量数据处理还提供了大量相关的技术。例如分区技术、merge语句、外部表等，可以结合具体应用，有针对性地使用。
上述技术都将是本书即将讲述的优化技术。
总之，优化是无止境的。
1.3.4 2010年银行案例的进一步感悟
在此需要进一步补充的是，该故障发生3年之后的2010年，本人与一位来Oracle公司时间不长的新同事一同出差，闲聊中才知道他曾经作为开发商的项目经理为该银行提供了多年的服务。无意中聊起当年这个事故，他居然一点也不知道当年很轰动的这个事故的原因和处理手段其实都很简单。而他当年从客户那儿得到的故障通报，却是复杂至极。什么主机问题、网络问题、数据库问题、应用问题，尤其是业务压力大的背景等，几乎包罗万象。
也许这就是“东方哲学”的功底和魅力：能把一个简单问题解释（包装）得非常复杂，云山雾罩，最后是不知所云，同时也方便不同人群从中各取所需。
……
