本书是目前Oracle数据库运维领域不可多得的一本著作，也是为数不多的即有大量实践应用案例又包含实战方法论的著作。作者根据其多年的运维诊断经验，从数据库如何创建开始，循序渐进地介绍了数据库的启动关闭过程，如何配置监听并连接到数据库，如何对数据库空间进行管理和监控，SGA的调整和优化方法，数据库的CHECKPOINT和SCN机制与备份恢复，数据库性能优化的方法论以及Oracle Data Guard的配置和管理等内容。书中作者结合了大量的真实案例，把自己多年的宝贵经验融入其中，通过一些复杂案例的诊断过程来说明这些简单的原理和知识点，同时，作者并没有简单地停留在案例诊断分析的层面上，而是根据大量案例的经验汇总，把问题的优化、诊断和解决提升到了方法论的层面上，进一步帮助读者知其然，知其所以然。
周亮的第一部作品即将出版，我有幸先睹为快，揽卷细读，一股草莽之气扑面而来，如周亮于序言所诉，其步Oracle之路实为偶然，而个人喜恶泾渭分明，故果断避开发之途，专数据服务之径。数年之实践积累始有此书，所谓英雄出草莽，此书毫无学院派之专业凿凿，通篇遍布实践之积累总结，由此不愧实战之名，而由作者之成长观之，为攻略指导此界新兵亦绰绰有余。
我观其书，如空间管理章节，于各点结合案例分头击破，渐趋空间管理之全局；又如性能优化章节，各个角度、列表行文，既可作思路借鉴，又可作开发运维警示，实践意义彰显。愿读者能从作者之成长、经历借鉴学习，观其书、识其人、学其思，从而提升自身，如此则作者分享之愿达矣。
我与作者相遇于杭州，其身材魁伟，肤色黝黑，声如洪钟，杯到酒干，其书实如其人。集句二以赠作者：英雄出自草莽，佳作经年始成！
—— 盖国强 （ Eygle ） 云和恩墨创始人、Oracle ACE总监
周亮的这本书就是Oracle第三方服务团队的工作写照，他和整个团队每天需要支持几百套数据库的故障应急处理，每个数据库的数据量在100GB至10TB之间，每个数据库都有接近7×24小时的运行要求；一般来说，终端客户管理员能处理百分之八十以上的日常运维问题，当他需要联系我们服务团队时，故障问题既复杂又紧急，故障处理难度也远远高于运维问题。
这本书不是简单的Oracle概念知识汇总，也不是简单的典型案例汇总，而是侧重于日常实战经验的汇总，如果你是位初级管理员，这本书能大大加深你对基本概念的理解，快速掌握实战方法论、实战知识点和实战分析技巧；如果你是位中高级管理员，能让你透彻理解数据库启动的内部过程、数据库文件管理知识点，我相信它能让你视野大开；如果你是位资深的高级管理员，在书里你能看到或许只有大型数据库才会面临的大数据量高并发问题，高并发数据库带来的性能问题，相信能带给你不少启发。
—— 闻建霞 美创科技技术总监
与周亮共事已有7年多的时间了，有幸见证了作者从一名Oracle初学者一步步成长为大师的成长过程。作者从接触Oracle以来一直对Oracle保留着极大兴趣，兴趣是最好的老师一直引导着作者在Oracle技术领域不断探索前行。本书记录了作者在DBA工作中的一些经验总结，希望能够为DBA们提供一些参考与借鉴。更期待作者随后能出版更多的大作！！！
—— 徐荣星 资深数据库专家，容灾专家
Oracle作为一款成熟的商业软件，其软件的设计思想值得每一位研发人员好好学习。但是，作为Oracle DBA，最为关心的是如何让自己的数据库高可用、高性能运行。资深DBA比一线DBA更能解决疑难杂症不是因为其熟悉如何敲打命令，而是因为“经验”丰富：既能“调理”整个系统，又能一针见血指出解决思路。本书从作者的实际工作经验出发，分别从数据库启动关闭、监听管理、空间管理、高可用、性能优化等角度系统地阐述了数据库运维过程中需要注意的地方及解决问题的思路。Oracle DBA是一门手艺活儿，在探索Oracle技术的漫漫长路中，每个人都吃过不少苦头。如果您在读了本书之后能够发现更多的潜在问题，误操作能少点，故障处理速度能快点，那就值了！
作者简介
周亮 杭州美创科技Oracle技术服务团队负责人，Oracle 10g OCM。精通Oracle数据库原理，对于数据库架构设计、运维、调优、排故有着丰富的实战经验。带领Oracle技术服务团队，为公司客户提供上百套数据库维护工作。客户涉及政府、通信、金融、公安、电力、交通、医疗、制造等行业。
为什么要写这本书
经常有同行问我：“你为什么要学习Oracle？”
我往往这样回答：“我不喜欢编程，所以经朋友介绍去了一个大型项目团队做测试。在测试过程中用到Oracle，而且每天的实习工资有90块呢！”
我说的是实话。我确实不喜欢编程（至今仍然讨厌编程，熟悉我的人应该都知道），因为我讨厌记程序的语法，讨厌调试代码时出现的各种错误，而且每天90块钱的实习工资在当时确实诱惑力还是很大的。就这样，我阴差阳错地进入了Oracle这个博大精深的世界。
学习了3个月的理论知识后，我自信心暴涨，以为Oracle就那么一回事。被领导派往某客户处安装数据库时，结果连一条切换操作系统用户的命令都不会（su - oracle）。当时真是感觉后背发热，如坐针毡，这才真切地感受到了理论和实践的差距。
我永远记得同事说过的一句话：“工作了，不再像在学校里有老师逼着学习，现在都要靠自己了。”为了生存，我不得不硬着头皮逼自己学习领导交给我的Oracle官方文档，那段时间真的比高考都辛苦。我满脑子都是Oracle，睡觉前都在想Oracle后台进程之间的协调。随着学习的深入，我对Oracle的兴趣也越来越浓。不知从何时起，被动学习变成了主动学习（到今天为止，我每天都至少学习2小时以上），一天如果不打几条sqlplus命令，不看几篇MOS文章就感觉心里空荡荡的。当习惯已成自然的时候，我发觉我已经“入魔”了。
兴趣是最好的老师，我坚信这句话。
值得庆幸的是，我不是纯理论派的Oracle人，我的工作性质决定了我每天必须要处理好几个故障，所以这几年下来，也积累了相当的实践经验。很多同行碰到问题来问我，我基本上都能快速地给出一个处理思路或者解决问题的方向。他们在佩服之余，还送了我一个雅号—周处（双重含义：本人处女座，另外，处理故障快速到位）。殊不知，在从理论迈向实践的路上，我也经历过风雨，熬过很多个通宵。
我目前所在的公司是一家第三方Oracle服务厂商，所以差不多有十几个DBA专门负责维护客户的数据库。“铁打的营盘，流水的兵”，当新员工加入团队的时候，就面临着如何让新员工快速成长的问题，于是我就有了将自己的实战经验写出来的想法，希望可以有助于新人的学习。当新人碰到问题时，我可以说：“嗨，XXX，请参阅《Oracle DBA实战攻略》的第N章第M节，那里有解决问题的思路！”那岂不是很威风？！不知终点的等待，会让人觉得无助。如果哪天故障来了，你能迅速判断出方向，那就行了！接下来的事情，就是使用什么样的技术了！写书不仅可以传授经验，而且也可以系统整理自己的Oracle知识，“赠人玫瑰之手，经久犹有余香”。这种双赢的事情，何乐而不为呢？
我必须承认，严格来说，这本书不能说是我“写”的，太多来自于各位大师的研究成果，这么多年浸淫其中，我已无法一一指明出处。中国人常说“落字为证”。当真正开始要写书的时候，我就变得诚惶诚恐，生怕误导同行。学习Oracle最难的是如何将理论与实践结合起来。本书是我多年来工作经验的总结，书中的内容偏重于实战，并尽可能在每个重要的知识点之后说明需要注意的地方。抛开Oracle基本理论，阅读本书，你将会看到我在故障处理方面的思考过程和方法。将思考过程展现给读者是本书的特色，相信会给读者带来实际的提升。
不得不提一下，至今为止，虽然我仍然很讨厌编程，但是由于我痴迷于Oracle，在研究Oracle的过程中，深深感到自身的编码缺陷，所以我又反过头来再学编程了。因为有编程基础再学Oracle会更加得心应手。
“没有解决不了的技术问题”，这是我们领导说的。在学习Oracle的路上，我一直用它来鞭策和激励自己，与君共勉。
读者对象
本书是为以下读者写作的：
Oracle DBA或者开发人员。
有一定Oracle 管理经验、希望进一步提升的读者。
迫切希望在Oracle数据库领域一展拳脚的初中级DBA。
如何阅读本书
本书覆盖面较广，内容涉及Oracle运维过程中常见故障的诊断、空间管理、性能优化、备份恢复等方面。虽然Oracle是一台巨大的同步机器，但每一部分内容相对独立，读者可以根据需要有选择性地阅读相关章节。由于本书侧重实战，所以数据库故障处理思路、运维过程中的注意点始终贯穿本书。
本书共有10章。第1章为数据库故障的诊断方法与分析思路，主要讲解我在碰到各类故障时的解决思路，这些实战方法源于我的经验，不一定适合所有的DBA，但对大家有一定的借鉴作用。
第2章为监听的配置和管理。数据库的连接问题是运维过程中比较容易碰到的，而Oracle 监听（listener）则是客户端连接到数据库的必经之路，相信通过本章的学习，读者能找到解决问题的思路。
第3章为命令行创建和删除数据库，主要讲述命令行安装数据库的一些知识以及注意事项，因为研究命令行安装能比较清楚地知道创建数据库的来龙去脉。
第4章为SCN和CHECKPOINT。CHECKPOINT的最终结果会使得CHECKPOINT NUMBER增加，即SCN值增加。对于初学者来说，要将这么多SCN串联起来会有一定的难度，可是，如果理解了SCN机制，也就相当于理解了Oracle的核心，所以在本章会分批介绍几种常见的SCN，帮助大家理解。
第5章为数据库的启动与关闭。数据库的启动是一个相当复杂的过程。本章将花较大的篇幅来讲述数据库的启动过程，并通过大量的真实案例指出数据库在启动过程中潜在的故障点，以及解决这些故障的具体思路。希望通过本章的阅读，能让读者对数据库的启动过程有个较为清晰的认识。
第6章为数据库空间的管理与监控。本章很少涉及理论，侧重探讨数据库在日常运维过程中的注意事项。在到处充斥着Oracle理论的今天，运维经验显得弥足珍贵。
第7章为Oracle性能优化方法论。在大多数DBA眼里，数据库的性能优化似乎是一门虚无缥缈、难以掌握的技术。本章尽量使用形象直白的语言去介绍Oracle性能优化方法，从而帮助读者相对快速地找到Oracle性能优化的方向。
第8章为SGA的性能调整和优化思路。本章主要从我的实际工作经验出发，结合SGA的内存结构，着重与读者分享在处理SGA性能问题时的优化思路。由于生产环境异常复杂，再加上本人水平有限，其中有些观点难免有失偏颇，欢迎读者批评和指正。
第9章为数据库的物理备份与恢复。墨菲定理指出，事情如果有变坏的可能，不管这种可能性有多小，它总会发生。对于Oracle故障来说，当然也存在着由可能发生变为必然发生的风险。本章主要讨论的是数据库的物理备份和恢复技术，同时还会介绍一些与其相关的注意事项和最佳实践。
第10章为物理 Data Guard的配置与管理，主要讲解Oracle 物理Data Guard的配置和日常运维中的一些注意点。
勘误和支持
由于作者的水平有限，编写的时间也很仓促，书中难免会出现一些错误或者不准确的地方，不妥之处在所难免，恳请读者批评指正。如果你有更多的宝贵意见，也欢迎你发送邮件至我的邮箱za88888@gmail.com，我很期待你们的真挚反馈。如果你有微博，也欢迎互粉，大家一起学习、交流，共同进步。我的微博地址为http://weibo.com/dbathinker。
致谢
首先要感谢我的妻子，没有她的支持和肯定，我是不可能完成本书的。
感谢我的岳母，没有她精心照顾儿子，我是没有精力完成此书的。
感谢我的团队，他们出色地保证了系统的稳定运行，给了我写书的可能。
感谢陈佳媛、杨绣国对书稿的审阅，她们提出了很多中肯意见和宝贵建议。
最后，谨把本书献给我可爱淘气的儿子，愿他快乐健康成长。希望通过本书让他知道，老爸不陪他的日子里，还是做了很多有意义的事情的。
周亮
2013年4月写于杭州
计算机\数据库
周亮的第一部作品即将出版，我有幸先睹为快，揽卷细读，一股草莽之气扑面而来，如周亮于序言所诉，其步Oracle之路实为偶然，而个人喜恶泾渭分明，故果断避开发之途，专数据服务之径。数年之实践积累始有此书，所谓英雄出草莽，此书毫无学院派之专业凿凿，通篇遍布实践之积累总结，由此不愧实战之名，而由作者之成长观之，为攻略指导此界新兵亦绰绰有余。
我观其书，如空间管理章节，于各点结合案例分头击破，渐趋空间管理之全局；又如性能优化章节，各个角度、列表行文，即可做思路借鉴，又可做开发运维警示，实践意义彰显。愿读者能从作者之成长、经历借鉴学习，观其书，识其人，学其思，从而提升自身，如此则作者分享之愿达矣。
我与作者相遇于杭州，其身材魁伟，肤色黝黑，声如洪钟，杯到酒干，其书实如其人。集句二以赠作者：英雄出自草莽，佳作经年始成！
——盖国强 （ Eygle ） 云和恩墨创始人、Oracle ACE总监
周亮的这本书就是ORACLE第三方服务团队的工作写照，他和整个团队每天需要支持几百套数据库的故障应急处理，每个数据库的数据量在100GB至10TB之间，每个数据库都有接近7×24小时的运行要求；一般来说，终端客户管理员能处理百分之八十以上的日常运维问题，当他需要联系我们服务团队时，故障问题既复杂又紧急，故障处理难度也远远高于运维问题。
这本书不是简单的ORACLE概念知识汇总，也不是简单的典型案例汇总，而是侧重于日常实战经验的汇总，如果你是位初级管理员，这本书能大大加深你的基本概念理解，快速掌握实战方法论、实战知识点和实战分析技巧；如果你是位中高级管理员，我相信它能大大扩充你的实战视野，能让你透彻理解数据库启动的内部过程、数据库文件管理知识点，我相信它能让你视野大开；如果你是位资深的高级管理员，在书里你能看到或许只有大型数据库才会面临的大数据量高并发问题，高并发数据库带来的性能问题，相信能带给你不少启发。
——闻建霞 美创科技技术总监
跟周亮共事已有7年多的时间了，有幸见证了作者从一名Oracle初学者一步步成长成大师的成长过程。作者从接触Oracle以来一直保留着对Oracle的极大兴趣，兴趣是最好的老师一直引导着作者在Oracle技术领域不断探索着前行。本书记录了作者在DBA工作中一些经验总结，希望能够为DBA们提供一些参考与借鉴。更期待作者随后能出版更多的大作！！！
——徐荣星 资深数据库专家，容灾专家
周亮 著：暂无简介
推 荐 序 一
记得10年前，我信誓旦旦地表示要写本Oracle性能优化方面的书，我们的客户浙江省新华书店表示出版和销售由他们来负责，在持续动笔四、五次之后，还是放弃了，写书也就成了一个遥远的梦。当同事告诉我，周亮在写书的时候，我很兴奋，要求团队全力配合，主要是在时间上给予支持，使其可以相对专心的写作。相信任何一个在第三方维保公司工作的DBA都知道自己的工作角色会使成书不易，高强度、高压力的工作，时间上的不规则，不要说写书了，就是在论坛灌灌水，写写博客都会成为一种奢侈。事实上，大家也可以看到在市场上销售的Oracle书籍，来自于第三方维保服务商DBA的也就只有那么寥寥几本。 特别是来自于第三方维保服务商DBA的著作还不是简单的案例堆积时就会显得更为弥足珍贵，相信本书也会经久不衰，成为DBA进阶的指路明灯。
在OCP、OCM泛滥的今天，DBA这个职业似乎突然从黄金职业变成“烂大街”的职业了。作为国内最为资深的DBA之一，个人认为各位同行完全不需要为这个发愁，DBA确实是一个好职业。数据重要性的持续提高，可以保证DBA这个职业未来是可持续发展的，而且DBA这个职业的高度和广度决定了其转行到其他职业相对也会比较简单。作为一个初中级DBA，关键在于如何让自己进阶，成为一个真正的高级DBA。对于绝大部分职业来说，天赋非常重要，只有天赋出色才可能成为最顶级的专家。对于广大的DBA来说，非常幸运，DBA是一个不是很看重天赋的职业，只要你足够勤奋，有足够的经验积累和适当的指导，你就可以成为业内顶级的专家。
知识、经验和方法是DBA进阶的不二法门，任何一个优秀的DBA都是知识，经验和方法的综合体。当方法统领知识和经验的时候，你就可成为一个顶级DBA；当经验统领知识和方法的时候，你就可成为一个优秀的DBA；当你仅仅拥有知识和少许经验时，你就只是一个初级DBA或者是一个入门者。我始终认为Oracle或者数据库是一门特殊的学问，大家知道一般知识的学习，你掌握并精通了某个章节的内容，很可能你就能完成很多实践性的工作。但Oracle数据库不同，必须要通晓所有章节并且在章节之间可以进行有机关联的时候才可以认为在知识领域入门了，才可以完成一些基础性的实践性工作，所以Oracle DBA的学习周期相对比较长。
美创科技一直以DBA进阶速度快而著称，作为本书出版的礼品，透露一些商业机密也在所不惜，接下来就和大家分享一下我们团队DBA的成长过程。
第一阶段：知识学习阶段。在DBA进阶的漫长过程中，勤奋是任何一个优秀DBA的必备素质。作为商业团队，当然也无法忍受员工漫长的学习周期，所以超过高考和考研究生的学习压力必然是初学者面临的场景，对于初学者，我们会为每个人都分配一个老师，并为其制定学习计划，监控学习进度，随时沟通交流学习成果。为了防止学习基础不扎实，我们禁止一年以内的工程师阅读任何中文书籍，甚至不鼓励Google和Metalink的使用。作为一个重要分享，学习Oracle最重要的学习材料自然是Oracle Concept文档了，当然，在初学阶段对于Oracle Concept会比较模糊。Oracle Concept是DBA进阶的持续学习材料，即使到了顶级DBA，也需要持续针对Oracle Concept进行学习。
第二阶段：受控工作阶段。作为支持甲方DBA的团队，出现在甲方现场的同事必须扮演专家的角色，所以我们不惜成本以老带新在客户现场积累经验，我们极为重视工程师的第一次独立亮相，事先事后都会做好周密计划，确保其圆满完成任务，从而树立在用户层面的专家形象。在圆满完成第一次客户现场任务之后，就算是入门了，之后会持续地分配受控的现场任务，也会跟随老工程师一起处理一些复杂问题，一直到工程师基本可以独立处理问题为止。
第三阶段：经验积累阶段。在工程师可以独立工作之后，取消师徒制，开始进入独立工作阶段。作为一个支持甲方DBA工作的DBA，每天都要处理大量问题，会快速积累大量经验。对于我们的团队来说，在不担心经验积累的情况下，决定DBA能否进阶的关键在于是否进行持续的学习和案例的总结分享。这个时候，Oracle Metalink就成为一个巨大的资源库，对于一个具有持续学习愿望的工程师来说价值非凡。在这个阶段，我们会鼓励工程师看一些中文出版物，主要是学习一些解决问题的思路并积累一些经验。事实上，在经验积累阶段的前期，依然不鼓励员工看一些内核研究相关的书籍和文章，人的精力是有限的，过早地接触这些内容对于学习成长并没有太大的好处。我们不鼓励工程师在遇到无法处理的问题时就搜索Metalink和Google，而是鼓励通过团队内部沟通和支持来解决问题。Metalink不会带来处理问题的方法，团队内部沟通和支持可以带来处理问题的方法，对于处理方法论的形成极其重要。在精通Google和Metalink搜索时，Google和Metalink对于工程师是一个极其高效的助手，但也正是因为这个助手过于高效，于是养成了一大批Google DBA或者Metalink DBA在分析问题之前就开始从Google和Metalink寻找答案，如果不改变工作作风，这些DBA几乎永远无法成长。
第四阶段：化蝶阶段。客户的持续信任会让你介入客户IT运维的全方位工作，你可能会参加客户的各种技术会议、客户各种IT相关系统的上线咨询、客户各种运维方法和规范等，这个时候客户是你学习的一个强大驱动力，要求你脱离Oracle的范畴来全方位地思考问题，之前培养的持续学习和快速学习能力是支持你完成这个阶段的重要保证。
除了技术因素之外，成为优秀DBA还有些其他决定性因素。责任心、抗压、果断、沟通是成为优秀DBA的主要非技术因素，没有这些因素的支持，即使技术水平再好也很难成为一个可以依赖的优秀DBA，至少无法成为一个支持甲方DBA工作的优秀DBA。
作为一个从事Oracle DBA近15年的资深工程师，看过很多的Oracle著作，绝大部分书籍都几分钟翻完就不会再去看了。目前市场上主要有两类Oracle书籍，适合于初学者的书籍和适合作为资料翻阅的书籍，很少有书可以为DBA进阶提供较大帮助。拿到周亮这本《Oracle DBA实战攻略》，内容还是相当震撼的，充斥在纸张中的经验和处理方法论贯穿全书，点到即止的描述使其内容异常充实，或者说是具有海量的内容。很显然，这不是一本短时间可以看完的休闲作品，需要大家像品尝Oracle Concept一样“细嚼慢咽”，这是一本少见的Oracle DBA进阶的作品，非常适合于中高级DBA进阶使用。
今年是周亮从事Oracle DBA职业的第7个年头，DBA从业者的黄金年龄，让我们跟随周大师的步伐开始Oracle DBA的进阶成长。对于初学者或者初级DBA而言，周亮的成长途径完全可以跟随和学习，对于遇到进阶障碍的中高级DBA而言，周亮的这本书也可以在一定程度上帮助你们完成DBA进阶突破。
柳遵梁
杭州美创科技有限公司创始人
资深安全专家，容灾专家
Oracle 8 OCP
推 荐 序 二
印象中很少帮人写序，提笔后才发现这也不是件轻松的事情。
初识周亮应该是2012年10月到杭州出差，经一个杭州的同事介绍认识，虽然是第一次见面，但是聊得却很投机：一方面大家都是这个圈子里的人，虽然之前没有打过交道，但是有着很多共同的朋友，因此感觉比较亲切；另一方面是我们两个的相似点非常多，因此共同语言也就比较多。大家都是Oracle的DBA，都对Oracle技术感兴趣，也都在Oracle的圈子内积累了不少经验，即便是只聊技术，也能找到说不完的话题。更何况我们两个人的工作性质几乎完全一样。我们两个目前都是从事乙方运维的工作，我是2011年开始从事Oracle数据库的乙方运维管理工作的，而周亮的乙方运维经验则比我长得多，如果从这个角度讲，他的Oracle数据库运维经验要比我丰富得多，这无疑也使我们增加了更多的共同话题。于是当天晚上，从Oracle数据库聊到了具体的案例，从工作聊到了客户，从技术聊到了团队，就差谈人生和理想了。
也就是在那次聊天过程中，我了解到他正在写书，而且已经动笔几个月了。当时Eygle的新书刚刚出版不久，而我的几个好友也恰好都在写书，所以这方面的话题也比较多，也就多聊了几句，当时对他的新书有了一个第一印象：这本书是根据案例和实践经验整理而成的，当时给我的感觉应该和DBA手记系列比较相似。
之后的几个月，听说他仍然在笔耕不辍。乙方工作的辛苦自己是深有感触的，能在日常繁忙工作的基础上，把一些知识要点记录下来已经是很少有人能做到的事情了，而还能坚持不断地写作，这绝对是需要毅力才能完成的工作。因为写作和写博客不同，虽然二者可能都是需要每天挤出半个小时到一个小时的时间，前者对时间的要求更高，必须要有整块的时间，否则难以展开思路；而对于后者而言，如果有了什么思路或者碰到了什么案例，可以用很短的时间先记录下来，随后也可以通过零碎的时间进行实验和验证，所以，说起来似乎是同样的一小时时间，前者的坚持和付出要远远高于后者。
直到最近他成书后邀请我写序，我才发现他的书并不是简单的案例集合，而是存在一条主线将各个知识点串联在一起的，这从成书的困难程度上来讲，就要比DBA手记之类的案例集合至少上了一个台阶。
从严格意义上讲，我没有写过书，只是写过文章。虽然参与了《Oracle数据库性能优化》以及《Oracle DBA手记》等书的编写，但形式仍然是供稿方式。这几本书的最大特点在于没有一条明确的主线来穿起所有的内容，书中的各个章节独立，因此成书相对来说要容易得多。而如果要独立写一本书，就需要考虑完整的架构、背景知识、贯穿全书的主线，以及选取的案例是否合适等，显然这要比纯案例的组合困难得多。而即便是案例类的书籍，事实上，其成书过程也并不是一蹴而就的。先不说素材、案例的选取，知识点深入程度的把控等对于技术含量要求很高的事情，只说整本书编写工作完成后，对全书的修订和审阅工作也不是一件轻松的事情。因为自己有过这种不断修订的经历，每次都是一个很痛苦的过程，以至于到现在仍记忆犹新。而如果要我独立写一本书，要有明确的主线，要有详尽的基础知识介绍，要覆盖Oracle的主要体系结构点，还要有大量深入的案例作为佐证，最好还要有一些尚未公开的研究结果，光想想就已经头大了。因此，我一直很钦佩那些能独立完成一本书的人，无疑，本书作者也是令我钦佩的大牛之一。
周亮令我钦佩的不仅仅是技术上的积累，也不只是我提到的为了成书而付出的艰辛，更令我钦佩的是其对技术几年如一日的持续专注的态度。最近微博上还有人讨论是否应该写书。国内的技术和出版的大环境，决定了靠写技术书籍赚钱绝对是Mission impossible。即使是Eygle这种几乎一年一本的速度，且每本都很畅销的情况，也完全不足以通过写书养活自己，那就更不用说其他人了。通过写书来出名也越来越难，其实很多人是因为作者本身的名气才买的书。有位网友说得很有道理，别人知道你是因为你做了什么，而不是你写了什么。在现阶段无论是收名还是获利，想通过写书的方式来实现，其投入产出比都非常不好。但是也正因如此，以名利为目的作者越来越少，而写书更多地变成了一些有技术追求的人，把自己的技术沉淀、总结和自我提升的过程。大浪淘沙始得金，我们欣喜的看到，近期出版的和即将要出版的几本Oracle书籍，无不是业内专业人士的呕心力作。本书正是其中之一。
作者根据他多年的运维诊断经验，从数据库如何创建开始，循序渐进地介绍了数据库的启动关闭过程，如何配置监听并连接到数据库，如何对数据库空间进行管理和监控，SGA的调整和优化方法，数据库的CHECKPOINT和SCN机制与备份恢复，数据库性能优化的方法论以及Oracle Data Guard的配置和管理等内容。仅看目录似乎都是非常基础的内容，似乎这是本针对Oracle初学者的入门级书籍，其实恰恰相反，所谓大道至简，能把最基础的东西写出新意并加入自己的理解本身就是一件非常见功底的事情。而且作者结合了大量的真实案例，把自己多年的宝贵经验融入其中，通过一些复杂案例的诊断过程来说明这些简单的原理和知识点，这正是作者高明的地方。更何况作者并没有简单地停留在案例诊断分析的层面上，而是根据大量案例的经验汇总，把问题的优化、诊断和解决提升到了方法论的层面上，这就不仅仅是通过几年经验积累就可以轻易达成的，必须要求作者不断地思考、分析、归纳和验证，才能上升到理论指导实践的层面。
最后希望本书，可以帮助更多的数据库技术爱好者解决日常碰到的技术困难，给那些以日常操作入门的运维人员指出一条深入学习、快速提高的道路。
杨廷琨
ITPUB管理版资源版主
Oracle Ace Director
推 荐 序 三
从前有座山，山上有座草房，草房里住着一位隐者。
山下住着一位致仕还乡的京官，素好风雅，常上山与隐者谈古论今，偶而也会手谈一局（手谈：围棋）。一来二去，便与隐者渐成好友。
一日京官又上山与隐者谈天论地，对弈数局。不觉天色渐晚，两人腹中空空，甚感饥饿。京官要告辞下山，隐者挽留：“不如先吃碗清汤面垫一垫，再行下山。”京官一听，也觉有理，但环顾草房，家徒四壁，陈设极简，暗自揣度这清汤面恐是淡而无味，难以下咽的。须臾，已有家丁将做好的清汤面呈上。
京官一看，微微皱起眉头，白色瓷盘，加上白色“素面”，清汤寡水，果然让人全无食欲，不免在心中叹道：隐者生活真是清苦。想自己年少入仁，宦海一生，锦衣玉食。而这位隐者，终日食着这无滋无味的“素面”，这人生际遇真是不同啊！
京官不好意思放箸不食，只好端起盘来，浅尝了一口。未曾想这清汤面的味道奇好，前所未有。不觉之间，京官已将一盘清汤面尽数吃净。抬头看隐者，竟还没有吃完，仍端着盘细嚼慢咽。京官想到自己狼吞虎咽的样子，微微有些不好意思。
辞别隐者，回到家中，京官立马喊来厨子，命其也去做这味道不同寻常的清汤面。不料，数日后，厨子遍试清汤面烹饪之法，仍做不出京官记忆中的味道。
京官一怒之下，命人将厨子绑在院子中的大树之上，一顿猛打。并命其寻找烹饪秘方，若数月后仍做不出来，就将他发配边疆。厨子不舍家人，无奈之下持刀深夜上山，将隐者绑于柱上，威胁其传授清汤面烹饪之法，如若不然，两人共赴黄泉。
……
数月后，厨子呈上做好的清汤面，白色瓷盘，白色“素面”，与隐者家实为相似，尝之，恰也正是那日食得的味道，京官连声叫好，重赏厨子。并询问此“素面”烹饪之法。
厨子说，简单。养一群小鸡，每日喂以糯米。十日后宰杀几只，将小鸡之血和面，肉骨尽弃。再十日，再杀几只，用鸡血和面……如此这般数月，将鸡群宰杀殆尽，“面”成。用此面做成面条，自然味道迥异。
原来，这看起来极为简单但又美味无比的清汤素面，竟是下足了“工夫”的。技术，又何尝不是？
周亮，为人低调，不怎么混迹于QQ群，也不太上论坛，就如隐者之清汤面，清淡、简单，但不平凡。对于技术，他一直执著地追求着。他所领导的DBA团队，单是专职的Oracle DBA已逾20人，虽其日常管理工作繁忙，但作为领导者，周亮一直对Oracle疑难杂症、数据库相关的新技术，保持着高度的敏感。物以类聚，人以群分，我喜欢与对技术有追求的人为友，周亮正是这种人。经过多年的锤炼，他积累了丰富的经验（在我们的小圈子中享有调优排故第一人的称号）。而本书正是作者本人对自己长期以来所积累经验的分享。
本书一共10个章节，内容全面，涵盖安装类故障、网络、检查点、内存、I/O等方面。而且在第1章中，还有一个提纲挈领式的调优排故方法论的总结。另外，书中还包含着大量详实的案例，真金白银的技术分享，让人期待。故而本书也是我今年最期待的Oracle技术图书！
作为美创公司数据复制产品的主要设计人员之一，周亮负责产品最重要的部分：分析Oracle Redo格式。在内部格式的挖掘时，要求技术人员对原理十分清楚。周亮不单是对日志相关原理了如指掌，对Buffer Cache、共享池等各部分的原理也都很熟悉，在本书中，原理与案例结合的内容很多，对于开阔DBA思路，很有帮助。
再以隐者清汤面的故事结尾：简单之下有复杂，人是如此，软件亦是，调优排故，亦复如是。
吕海波
ITPUB管理版版主 VAGE
前阿里巴巴B2B最高级别DBA
DTrace GDB/MDB 技术倡导者
推荐序一
推荐序二
推荐序三
前言
第1章 数据库故障的诊断方法与分析思路 / 1
1.1 数据库安装类故障 / 1
1.1.1 安装数据库时容易犯的错误 / 1
1.1.2 无法启动安装界面的解决方法 / 2
1.1.3 安装数据库的最佳实践 / 3
1.2 数据库连接类故障 / 4
1.2.1 检查是否由网络故障引起 / 4
1.2.2 检查是否由主机资源引起 / 5
1.2.3 检查是否由监听故障引起 / 5
1.2.4 检查是否由数据库故障引起 / 6
1.3 数据库HANG类故障 / 6
1.3.1 数据库全局性HANG的处理过程 / 7
1.3.2 数据库局部性HANG处理过程 / 8
1.4 数据库性能类故障 / 9
1.4.1 性能类故障的处理思路 / 9
1.4.2 怎样快速定位资源持有者 / 9
1.5 数据误操作类故障的处理思路 / 10
1.6 数据库坏块类故障 / 11
1.6.1 数据库对象坏块的处理思路 / 11
1.6.2 SYSTEM/UNDO表空间损坏的处理思路 / 11
1.6.3 数据库在线日志文件损坏的处理思路 / 12
1.6.4 控制文件损坏的处理思路 / 12
1.7 总结 / 13
第2章 监听的配置和管理 / 14
2.1 简析监听连接示意图 / 14
2.2 深入解析监听配置文件 / 16
2.2.1 一个典型的监听配置模板 / 16
2.2.2 监听的常用命令 / 16
2.2.3 配置监听别名 / 17
2.2.4 配置文件中的关键字解析 / 18
2.3 tnsping命令的作用和适用场景 / 23
2.4 监听的静态注册 / 24
2.4.1 静态注册的配置内容 / 24
2.4.2 监听状态中服务名和实例名 / 25
2.5 监听的动态注册 / 26
2.5.1 动态注册的内容 / 26
2.5.2 监听状态中的服务名和实例名 / 26
2.5.3 监听动态注册时的实例状态 / 27
2.5.4 动态注册的时间点 / 28
2.5.5 实例不能动态注册的处理思路 / 29
2.5.6 跟踪实例的动态注册过程 / 31
2.6 巧用SSH的端口转发功能 / 32
2.7 跟踪监听的工作过程 / 33
2.8 监听的优化思路 / 35
2.9 诊断案例之一：RAC 某节点宕机之后的监听故障处理 / 36
2.10 诊断案例之二：使用客户端跟踪数据库连接问题 / 40
2.11 诊断案例之三：本地sqlplus连接HANG的诊断和分析 / 42
第3章 命令行创建和删除数据库 / 45
3.1 创建数据库的大概流程 / 46
3.2 理解Oracle SID / 46
3.3 检查操作系统环境 / 47
3.4 规划数据库文件系统 / 50
3.5 创建Oracle日志文件目录和密码文件 / 51
3.6 创建Oracle参数文件 / 52
3.6.1 设置内存相关参数 / 53
3.6.2 设置进程相关参数 / 53
3.6.3 设置DB_FILES参数 / 54
3.6.4 设置BLOCK_SIZE和DB_FILE_MULTIBLOCK_READ_COUNT参数 / 54
3.6.5 设置参数OPEN_CURSORS和SESSION_CACHED_CURSORS / 55
3.6.6 一个典型的数据库参数文件 / 56
3.7 创建数据库 / 57
3.7.1 数据库的创建脚本 / 57
3.7.2 使用OMF特性创建数据库 / 61
3.8 创建数据字典 / 61
3.8.1 执行catalog.sql / 62
3.8.2 执行catproc.sql / 63
3.8.3 执行utlrp.sql / 64
3.8.4 执行pupbld.sql / 64
3.9 命令行创建RAC数据库 / 66
3.10 怎样彻底删除数据库 / 68
第4章 SCN和CHECKPOINT / 70
4.1 SCN / 70
4.1.1 SCN的作用 / 70
4.1.2 SCN和时间之间的转换 / 71
4.2 SCN的最大阈值 / 74
4.3 几种常见的SCN / 75
4.3.1 控制文件中的SCN / 75
4.3.2 数据文件头中的SCN / 77
4.3.3 数据块中的SCN / 80
4.3.4 日志文件头中的SCN / 83
4.3.5 事务开始时的SCN / 84
4.3.6 数据库的CURRENT SCN / 85
4.4 CHECKPOINT / 86
4.4.1 CHECKPOINT的作用 / 86
4.4.2 全量CHECKPOINT和增量CHECKPOINT / 87
4.4.3 CHECKPOINT和REDOLOG / 89
4.4.4 影响数据库打开速度的因素 / 90
4.4.5 CHECKPOINT的优化思路 / 91
第5章 数据库的启动与关闭 / 93
5.1 实例与数据库 / 93
5.2 数据库参数文件 / 95
5.2.1 参数文件的类型 / 95
5.2.2 参数设置 / 96
5.2.3 参数文件之间的类型转换 / 98
5.3 简述数据库的启动步骤 / 99
5.4 数据库的启动步骤之一：NOMOUNT / 102
5.4.1 连接至空闲实例 / 102
5.4.2 读取数据库参数文件 / 107
5.4.3 分配SGA内存 / 110
5.4.4 派生后台进程 / 115
5.4.5 诊断案例：主机内存的使用率达到99% / 116
5.5 数据库的启动步骤之二：MOUNT / 118
5.5.1 读取控制文件 / 118
5.5.2 校验控制文件 / 118
5.5.3 MOUNT数据库 / 122
5.5.4 控制文件损坏的处理思路 / 127
5.6 数据库的启动步骤之三：OPEN / 128
5.6.1 详解CRASH RECOVERY / 130
5.6.2 CRASH RECOVERY的故障处理思路 / 137
5.6.3 详解CACHE RECOVERY / 139
5.6.4 CACHE RECOVERY的故障处理思路 / 148
5.6.5 详解TX RECOVERY / 157
5.6.6 TX RECOVERY的故障处理思路 / 158
5.7 数据库打开HANG的故障处理思路 / 160
5.8 如何强制打开数据库 / 161
5.9 如何快速关闭数据库 / 165
5.9.1 影响数据库关闭速度的因素 / 165
5.9.2 数据库无法关闭的诊断方法 / 166
第6章 数据库空间的管理与监控 / 168
6.1 数据库的空间管理 / 168
6.2 表空间管理 / 169
6.2.1 区管理和段管理 / 169
6.2.2 临时段管理 / 176
6.2.3 回滚段管理 / 182
6.2.4 表空间的监控脚本 / 196
6.2.5 维护表空间的注意事项 / 197
6.3 数据文件管理 / 198
6.3.1 裸设备头上的保留信息 / 198
6.3.2 浅析数据文件的操作系统头 / 200
6.3.3 破解数据文件头内容 / 201
6.3.4 维护数据文件的注意事项 / 203
6.4 在线日志文件管理 / 205
6.4.1 破解日志文件头信息 / 206
6.4.2 LGWR进程在日志文件中的写进度 / 207
6.4.3 维护日志文件的注意事项 / 208
6.5 归档日志管理 / 209
6.5.1 开启和关闭归档模式步骤 / 209
6.5.2 归档日志的命名参数 / 210
6.5.3 查看归档日志的几个脚本 / 212
6.5.4 使用LOGMNR挖掘归档日志 / 213
6.5.5 开启归档模式的注意点 / 214
6.5.6 开启归档模式的好处 / 215
6.6 闪回日志管理 / 217
6.6.1 数据库闪回相关的视图和参数 / 217
6.6.2 数据库级别的闪回种类 / 218
6.6.3 闪回日志空间的释放 / 219
6.7 控制文件管理 / 222
6.7.1 常见的控制文件故障处理 / 222
6.7.2 维护控制文件的注意事项 / 225
6.8 跟踪文件管理 / 226
第7章 Oracle性能优化方法论 / 228
7.1 数据库性能优化的目标 / 228
7.2 建立数据库性能基线 / 229
7.3 寻找关键变化 / 230
7.4 定位主要影响因素 / 230
7.5 检查操作系统资源 / 231
7.5.1 查看CPU资源 / 231
7.5.2 查看内存资源 / 231
7.5.3 查看I/O资源 / 232
7.5.4 查看网络资源 / 233
7.6 常见的数据库性能故障 / 234
7.7 数据库性能优化的常规方法 / 235
7.7.1 数据库性能调整的基本流程 / 235
7.7.2 调整Oracle内存参数 / 237
7.7.3 调整数据库在线日志 / 237
7.7.4 调整SQL的执行计划 / 238
7.7.5 优化对象的I/O读取 / 239
7.7.6 降低CURSOR解析成本 / 240
7.7.7 其他数据库性能调整手段 / 240
7.8 利用OWI监控数据库性能 / 241
7.8.1 OWI的基本原理 / 241
7.8.2 等待事件的含义 / 241
7.8.3 监控数据库的手段 / 243
7.9 利用时间模型监控数据库性能 / 244
第8章 SGA的性能调整和优化思路 / 245
8.1 BUFFER CACHE的内部结构 / 245
8.1.1 BUFFER HEADER / 247
8.1.2 HASH CHAIN和HASH BUCKET / 249
8.1.3 LATCH:CACHE BUFFERS CHAINS / 250
8.1.4 LATCH:CACHE BUFFERS LRU CHAIN / 252
8.1.5 FREE BUFFER WAITS / 255
8.1.6 BUFFER BUSY WAITS / 256
8.2 BUFFER CACHE的优化指标 / 257
8.2.1 BUFFER CACHE的命中率 / 258
8.2.2 AWR报告中BUFFER CACHE的一些争用指标 / 259
8.2.3 BUFFER CACHE大小的建议值 / 260
8.3 BUFFER CACHE的优化思路 / 261
8.3.1 BUFFER CACHE内存不足的优化思路 / 261
8.3.2 BUFFER CACHE的数据块争用的优化思路 / 263
8.3.3 其他有关BUFFER CACHE的优化思路 / 265
8.4 SHARED POOL的内部结构 / 265
8.4.1 堆管理 / 267
8.4.2 CHUNK / 267
8.4.3 FREE LIST / 268
8.4.4 LRU LIST / 271
8.4.5 RESERVED FREE LIST / 272
8.4.6 SHARED POOL的SUB POOL技术 / 273
8.4.7 关于SGA内存抖动 / 276
8.5 LIBRARY CACHE的内部结构及等待事件 / 279
8.5.1 LATCH:LIBRARY CACHE / 279
8.5.2 LIBRARY CACHE LOCK/PIN / 281
8.5.3 LIBRARY CACHE OBJECT / 283
8.6 浅析SQL的解析过程 / 287
8.6.1 软解析 / 287
8.6.2 硬解析 / 288
8.6.3 软软解析 / 290
8.7 ROW CACHE上的故障诊断方法 / 294
8.7.1 ROW CACHE的大小 / 294
8.7.2 ROW CACHE上的LATCH / 295
8.7.3 诊断案例：LATCH:ROW CACHE OBJECTS故障处理 / 297
8.7.4 建立测试环境重现问题 / 301
8.8 SHARED POOL上的优化思路 / 307
8.9 LOG BUFFER上的优化思路 / 309
8.9.1 LOG BUFFER的大小 / 309
8.9.2 浅析REDO WASTAGE / 310
8.9.3 LOG FILE SYNC等待事件 / 312
8.9.4 减少日志量的方法 / 314
第9章 数据库的物理备份与恢复 / 316
9.1 物理备份与恢复的基本概念 / 316
9.1.1 物理备份的基本概念 / 317
9.1.2 物理备份时的注意点 / 319
9.1.3 物理恢复的基本概念 / 320
9.1.4 物理恢复时的注意点 / 323
9.2 数据库的冷备份和恢复 / 323
9.2.1 冷备份数据库步骤 / 323
9.2.2 冷备份下的数据库恢复 / 325
9.3 数据库手动热备份和恢复 / 326
9.3.1 手动热备份 / 327
9.3.2 热备份下的数据库恢复 / 331
9.4 使用RMAN备份和恢复数据库 / 332
9.4.1 RMAN的结构 / 332
9.4.2 RMAN占用的内存 / 333
9.4.3 RMAN备份与恢复示例 / 334
9.5 数据库闪回 / 344
9.5.1 数据库闪回和普通闪回点 / 345
9.5.2 强制闪回点 / 348
第10章 物理Data Guard的配置与管理 / 350
10.1 Data Guard的原理 / 350
10.1.1 解析Data Guard原理图 / 351
10.1.2 Data Guard正常运行的前提 / 352
10.2 Data Guard的保护模式 / 353
10.2.1 最大保护模式 / 353
10.2.2 最大可用模式 / 353
10.2.3 最大性能模式 / 354
10.2.4 切换保护模式 / 354
10.3 配置物理Data Guard / 354
10.3.1 配置Data Guard简要流程 / 354
10.3.2 配置Data Guard相关参数 / 356
10.4 管理物理Data Guard / 357
10.4.1 配置Data Guard的注意点 / 357
10.4.2 管理Data Guard的注意点 / 358
