收获，不止Oracle(第2版)(txt+pdf+epub+mobi电子书下载)

作者：梁敬彬

出版社：电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

收获，不止Oracle(第2版)试读：

dbaplus社群简介

数据连接未来！围绕数据（Data）、区块链（Blockchain）、AlOps的企业级专业社群，拥有徽信群（近100个）、订阅号（粉丝10万+）及官网（UV24万+）。行业大咖、技术干货，每天精品原创文章推送，每周线上技术分享，每月线下技术沙龙，受众20万+。dbaplus社群丛书收获，不止Oracle　第2版梁敬彬　梁敬弘　著电子工业出版社Publishing House of Electronics Industry北京·BEIJING内容简介

在这本书里，读者将会跟随作者一同对Oracle数据库的相关知识进行梳理，最终共同提炼出必须最先掌握的那部分知识，无论你是数据库开发、管理、优化、设计人员，还是从事Java、C的开发人员。接下来作者再将这部分知识中最实用的内容进一步提炼，浓缩出最精华的部分，分享给大家。这是“二八现象”的一次经典应用。

这部分知识就是Oracle的物理体系结构、逻辑体系结构、表、索引以及表连接五大部分。通过阅读本书中的这些章节，读者将会在短时间内以一种有史以来最轻松的方式，完成对Oracle数据库的整体认识，不仅能解决工作中的常规问题，还能具备一定的设计和调优能力。通过对这些章节的学习，读者在Oracle的学习中一定会有极大的收获。

然而，作者更希望看到的是：让读者的收获，不止Oracle。

为达到此目的，作者精心将全书分成上下两篇，刚才所描述的具体知识点体现在全书的上篇中。而在下篇中，读者将通过各种精彩故事、生动案例，体会到该如何学习和如何思考，在意识的天空抛开束缚，无拘无束、尽情飞翔。

在这里，读者也许会有疑问，前面说的有史以来最轻松的方式是一种什么样的方式呢？

还请亲爱的读者自己去揭晓谜底吧。

未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。

版权所有，侵权必究。

图书在版编目（CIP）数据

收获，不止Oracle/梁敬彬，梁敬弘著.—2版.—北京：电子工业出版社，2019.4（dbaplus社群丛书）

ISBN　978-7-121-36092-3

Ⅰ.①收…　Ⅱ.①梁…②梁…　Ⅲ.①关系数据库系统　Ⅳ.①TP311.138

中国版本图书馆CIP数据核字（2019）第039839号

策划编辑：张月萍

责任编辑：刘舫

印刷：天津嘉恒印务有限公司

装订：天津嘉恒印务有限公司

出版发行：电子工业出版社　北京市海淀区万寿路173信箱

邮编：100036

开本：787×1092　1/16

印张：29

字数：724千字

版次：2019年4月第1版

印次：2019年4月第1次印刷

印数：4000册

定价：99.00元

凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888，88258888。

质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。

本书咨询联系方式：010-51260888-819,faq@phei.com.cn。

推荐序一

这是一本非常有趣的技术书，全书以对话穿插故事的形式完成编写，让人在轻松愉快中了解各种知识，构思让人拍案叫绝。也正是由于如此出色的构思设计，本书第1版多次印刷，依然售罄。应业界的强烈要求，结合Oracle 12c的第2版新书终于面世了。

梁敬彬是我们公司的特级专家，他服务的客户遍布全国各地，并取得了良好的口碑。他能在十分忙碌的工作之余，雷打不动地坚持每天早上4点起床整理技术知识，把自己宝贵的工作经验撰写成生动有趣的经典技术著作分享给广大技术人员，我非常欣赏技术人的这份激情。

不过，我更欣赏的是梁敬彬身上的创新精神。梁敬彬同时也是我们研究院的副理事长，是研究院许多好点子的主要贡献者之一，比如设置了 EX 币、创办了电子期刊、发布了悬赏令，策划主持了技术比武等，将研究院运作得风生水起，引发了许多电信内部兄弟公司的兴趣，并在电信集团层面进行了分享。

一个历史悠久的公司能够永葆青春，需要有优秀的内部创业文化，每个专家都要有创新精神，敢于否定自己的过去。梁敬彬就是我们公司许多有着创新精神员工的一个代表、一个缩影，希望更多员工能为公司多多建言献策，未来聚焦“两外两T”业务，在互联网化规模发展、机制创新、文化建设等方面进一步加快步伐，

期待公司出现越来越多的创新人才，以给我们带来更多的惊喜。吴刚中电福富公司总经理

推荐序二

经典升级再现，技术传播孜孜不倦

敬彬兄的经典著作《收获，不止 Oracle》要再版了，邀请我写一篇推荐序。因为这本书本身写得很好，推荐序于我而言就不太好写了，相形见绌反而不美，那我就写写与敬彬相识相知的过程吧。俗话说，文如其人，人如其文，真诚的人写的书也定是真诚的。

跟敬彬是在ITPUB时代的老友，大家在论坛里就各种问题互相回复，纯然的技术友谊。第一次见面，应该是九华山会议，ITPUB请了一些版主见面聚会，敬彬给人的感觉就是温文尔雅，彬彬君子。

第二次见面，是在2013年的 DTCC 会议上，我当时分享的议题是《大型业务系统 Oracle数据库10g到11g的升级实践》，而敬彬分享的则是《赢在起点—谈数据库设计规范》。我有幸聆听敬彬的分享，一个富有经验的老师，将生活中的故事揉进枯燥的技术里，娓娓道来，引人入胜。之后敬彬的《收获，不止Oracle》和《收获，不止SQL优化》两本书相继出版，秉承了他的演讲风格，内容提纲挈领，文字风趣幽默，讲解深入浅出，让读者更易于吸收。

dbaplus社群成立后，敬彬在繁忙工作之余，多次参与社群的线上分享和线下峰会，用他独特的方式持续传播Oracle技术。如今他又投注精力将Oracle 12c/18c的新特性及这些年工作生活的新积累更新到《收获，不止Oracle》（第2版）中，实乃读者之福。杨志洪dbaplus社群联合发起人，Oracle ACE,Oracle10g/12c OCM

推荐序三

别出心裁，另辟蹊径

敬彬的新书就要出版了，邀我写一点感受，于是就有了这一段文字。

我和敬彬相识是在2010年，那时我正在编辑《Oracle DBA手记》一书，偶然被他发表在ITPUB论坛上的一篇文章所吸引，那篇文章的题目是《DBA小故事之SQL诊断》，其内容鲜活、行文引人，于是就和他约了那篇稿子加入书中，邮件往来再到北京会面，就此熟识。

从当时的一篇文章到今天的一本书，我能够清晰地看到作者一以贯之的思考和叙述方式，这种积累与坚持也正是作者成长和成功的要素之一。

当时那篇文章的感受和今天这本书是类似的，作者能够用细腻的笔触将自己的经历真实生动地再现出来，并且带领读者一起经历一次思维的探索，这是属于他的独特风格。

作者在书中反复传达的核心观点是：Oracle数据库看似艰深的原理实际上和生活中的基本常识并无二致。理解了这一层意思，就能够消除一些人对于这项技术的畏惧之心，此后的学习自然就能顺风顺水。

诚然如此，我也经常和朋友们说，对于 Oracle 的很多艰深算法，如果由我们去深思熟虑，其结果都必然大致相同。类似HASH原理、布隆过滤等算法，理解了你就只觉得巧妙而不觉艰深。

现在梁老师就为我们寻找了一系列源于生活、循序渐进的学习路线，如果你能够细心领会，就会觉得这项技术实在是趣味横生。盖国强（eygle）Oracle ACE总监，云和恩墨创始人，ACOUG创始人

推荐语

梁先生的技术功底和文字功底同样深厚，更重要的是，他具有作为讲师那种缜密、体系化的思维方式，以及对读者心思的透视力，因此成书脉络清晰，里面还不断穿插许多人生哲理、技术前瞻，让人获益良多。这本书非常适合入行者和在行业里谋求上升的同仁阅读，动人的文笔可以让你一口气读完这本书。这是一本值得向行业推介的优秀技术书籍。黄志洪（tigerfish）Dataguru创始人

到底是什么后天原因导致人和人之间的学习结果发生重大差异呢？其中有一点就是思维方式。于是我尝试在思维方式方面去影响身边的一些人，其中的很多人在各自的工作领域都获得了成功，而在此之前他们却是默默无闻的。

敬彬的这本书就是用诙谐幽默的语言生动地引导大家在意识层面发生改变，然后逐步转化为行动上的改变。按此坚持，几年下来，相信每个人都能迈上新的台阶，这的确早已超越Oracle的范畴，对我们学习、生活等诸多方面都有益处。冯春培（biti_rainy）支付宝平台数据部资深总监

通读本书，如醍醐灌顶，豁然开朗，本书从实战出发，出发于技术，而超脱于意识，回味无穷。作者拥有多年的Oracle应用和体系架构设计经验，付出了超于常人的努力，总结出众多独到的经验，不失为一本好书，为学习和使用Oracle的技术人员带来诸多益处。傅祥文中电福富公司运营总监

敬彬兄的书笔触轻松而生动，在内容表现形式上使用了故事和对话场景，让读者在阅读时有很强的代入感；书中展现了大量的脑图总结，清晰直观，十分便于知识的理解和记忆。此书无论对于新手还是资深技术专家，都具有极大的借鉴意义。在Oracle技术已然成熟的今天，带给DBA的挑战和机遇依然有增无减，希望敬彬的这本书能成为你Oracle学习生涯的起点。杨建荣dbaplus社群联合发起人，Oracle ACE,《Oracle DBA工作笔记》作者

由梁敬彬、梁敬弘兄弟合著的《收获，不止Oracle》一书出第2版了。第1版取得了很大的成功，成为业界数据库书籍中的经典，堪称不易。该书第2版是响应业界的声音而再次出版的，融入了Oracle的新特性，预祝新书再次获得成功，同时也祝兄弟二人在事业上不断取得新的成就。黄连生清华大学计算机系教授

看过很多Oracle的书，让我印象深刻的并不多，梁老师的这本书是我给新员工推荐的必读书。这本书寓教于乐，将做事做人的道理潜移默化地传授给读者，虽然从事的是国产数据库的事业，此书依然能够给我们带来很多启发，收获确实不止Oracle，你值得拥有！黄海明达梦技术总监

敬彬兄这本书有着与市场上其他Oracle书籍不同的特点，通过一个个精彩的小故事，串起Oracle 的核心知识和优化方法论，并时刻强调学习和工作的意识，如何不被技术束缚，如何跳出技术，意识和方法真的很重要。相信读完本书，你的收获，绝对不止Oracle！丁俊（dingjun123）ITPUB Oracle开发版资深版主，《剑破冰山—Oracle开发艺术》副主编

梁敬彬先生通过自己在日常工作和培训中的磨炼，把自己对Oracle技术的感悟，通过一个个生动鲜活的小故事，浅显而又形象地展现了出来。对于初学者来说，可以慢慢地在一个个小故事中去了解Oracle数据库。读完这本书，你也许会恍然大悟：“哦，原来Oracle是这样子的。”罗海雄（rollingpig）ITPUB Oracle管理版资深版主

前言 迈出崭新一步——本书特点及存在的意义

0.1 当今时代，既是最好的也是最坏的

近年来，我深刻地体会到，如今这个时代对于绝大部分技术人员而言是幸福的时代，能在这个时代从事IT技术相关工作的技术人员应该很开心。因为比起老一辈技术人员，现今的技术人员几乎从来就不缺学习参考资料。除了可以在各技术平台的官方网站下载到详尽且准确的资料，还可以很容易地在各种搜索引擎中搜索到自己想要的答案，也可以很方便地在各种技术论坛上注册提问从而获取别人的帮助。

然而，这个时代对技术人员来说也是痛苦的时代。无论是传统的电信、金融、证券行业，还是新兴的互联网行业，我们都不难发现运维系统涉及的数据量、访问量及并发量都在以惊人的速度不断激增。重压之下，很多IT系统运行举步维艰，技术人员压力巨大，甚是痛苦。除了负载压力外，系统的复杂度也随着业务复杂度的增加而呈指数级增加，让开发设计人员头昏脑涨，让故障诊断及系统维护的相关技术人员无从下手。

痛苦还不止于此，在这个时代，除了海量负载和高复杂度，还有让技术人员应接不暇而无所适从的各种新技术。且不讨论IT所有技术，仅以数据库为例，除了以Oracle、DB2等为代表的一系列传统关系数据库外，还有内存数据库、列式数据库、以HBase为代表的分布式数据库等，让人眼花缭乱。此外，除了各类纷繁技术的选型外，我们还要适应具体各个版本的不断更新，以Oracle数据库为例，从早期的Oracle 5版本到今天的Oracle 12c,Oracle每一次发布新版本都需要我们投入大量的精力和时间去学习和适应。

这是幸福的时代，也是痛苦的时代。这是最好的时代，也是最坏的时代，如图0-1所示。图0-1 当今时代

0.2 技术人员，真正的差距其实在意识

在这个特点鲜明的时代，我目睹了一大批在IT项目中不能有效适应这个时代而导致摔得鼻青脸肿的技术人员，而这些人之中大多还是勤奋上进之人，少数还是技术能手。当然，也有成功的例子，让我来说说他们的故事吧。

0.2.1 小白的故事

工作两年多的小白是一个很努力的员工，每天除了用心工作外，还坚持充电学习，两年来他除了把Oracle的官方文档几乎读了个遍，还购买了不少相关的书籍来学习。由于小白的项目组工作强度大，时常需要加班，因此小白工作、学习外的时间就只够吃饭和睡觉了。那他的工作表现很出色吗，天道是否一定酬勤？实际情况却是不尽如人意，虽然他了解很多相关知识，可是在实际工作应用中却不得要领，频频出错，领导经常对其提出批评，他自己也相当苦恼。

其实小白只是因为缺少了一种被称为“意识”的东西，这个意识就是，该如何学习。在他的学习过程中，他犯了很多错误。

1.忽略了知识的重点

小白读完了Oracle官方文档的几乎所有内容，毅力让人钦佩！遗憾的是，他忽略了“二八现象”这个事实：20%的知识，解决80%的问题。小白根本不需要读完Oracle的所有文档，他所在的项目组是从事数据库开发相关工作的，而他却花费了大量的时间阅读完了至今他都尚未开始从事的数据库管理相关知识，比如备份恢复、RAC、DATAGUARD部署及高级数据同步复制相关的技术，这是完全没有必要的。

另外，语法方面的资料小白也根本无须细读、记忆，因为平时用得多的语法，自然记得住，遇到偶尔忘记的场合再去官方文档翻阅即可，现在各种搜索引擎的功能也非常强大，搜索到相关语法易如反掌。

人的精力是有限的，如果我们做到当前做什么事对应学习什么知识，尽量理解原理而不强记语法，将能省下多少宝贵的时间啊。

2.从未考虑知识落地

小白曾经对我说过自己的烦恼，向我说明了他有多努力，看过了多少资料。我试探性地问他是否知道Oracle的体系结构是什么？他很自信地做了回答，滔滔不绝，甚至还画了草图给我，回答得让我相当满意。我又问他是否知道索引的结构和原理是什么？再次得到完美的答复。

接下来我再问他，这个体系结构对我们的工作有什么帮助呢？他一下子回答不上来了。我继续问他，那索引的结构和原理对我们工作中的数据库应用有什么好处呢？再次答不上来。

这就是问题的关键所在！

知识要落地，要思考应用的场合，这就是我除了让他掌握学习重点外的第二个建议。他的学习其实就是为了学习而学习，没有思考应用场景的学习，是没有任何意义的。

后来我建议小白来听我在公司开讲的Oracle系列讲座，让他明白原来了解体系结构后我们居然可以将一条SQL指令的执行时间从42秒优化到不足0.01秒；了解索引结构后，我们居然可以优化我们身边最为常见的SQL语句，比如COUNT（*）、MAX（）等。而在此之前，这些语句根本不会让他对索引产生联想。他终于彻底明白了什么叫知识落地，明白了意识有多么重要！

我最后强调，不只是 Oracle，学习任何技术都是一样的，没有思考过你所学的某项技术有什么用，没有想过如何落地，如何应用到实际工作中去，都是毫无意义的学习，纯粹浪费生命。

3.选择技术使用场景

近来小白连续犯错，他学习了并行度这个章节后，知道并行可以有效地利用多个CPU，就将自己的代码加入了并行度。但他忽略了生产系统不只运行他这一个应用这个事实，结果导致代码运行后系统资源大量争用。直至最后我们定位到问题在他的代码中，将写法修正，取消了并行度后，系统终于恢复正常。

他为什么会犯这个错误？主要是因为他只专注于技术本身而忽略了应用的场景，如果是凌晨2点的某个大任务操作，他的这个设置就很好，因为那个时刻其他大多数应用都已经停止运行了，资源不用白不用。

这就是什么时候选择什么技术。小白还有一个有趣的故事，就是在我给他提这第三个建议之后的一周，他又使用了并行，这次他不是在代码中写死，而是选择临时性场合使用，在凌晨2点运行系列特定脚本。结果这次运行比想象的慢得多，还不如之前未用并行的时候。

大家知道是什么原因吗？其实还是因为不知道什么时候选择什么技术。这次他不会影响他人了，因为凌晨静悄悄。但是他影响了自己，因为他的任务的特点是小而多，平均不到0.01秒可以完成一条SQL执行。他忽略了另外一个细节，并行是需要调度的，调度是需要开销的，调度的开销甚至达到0.1秒，那当然是越跑越慢了。所以，小任务实际上是不需要考虑并行的。

类似的故事还有很多，在本书中大家还会接触到什么时候选择什么技术的各类场景，这里暂且只说并行。

小白的故事说完了，其实要是在早些年，他或许不会有这些苦恼，因为学习资料少，他即便不抓重点也不至于学到筋疲力尽；此外，他的诸多失误都和性能有关，而早些年大多IT系统压力很小，在基本功能满足后性能问题几乎可以忽略不计，那小白也就没错可犯了。

再次强调，当今的IT建设项目，如果不对海量数据和高并发带来的性能问题进行有效的架构设计、部署规划，你的项目基本上就被判了死刑。而Oracle新版本为什么对应大量技术文档，很大一部分原因是Oracle新版本提供了更多的性能调优功能。为什么现在新技术如此繁多，其实也是源于此，难道内存数据库和列式数据及分布式数据库的产生，不是为了让系统跑得更快一些吗？只是这里要注意，它们不可能替代传统关系数据库，因为它们都有各自适合的应用场合。小白的故事如图0-2所示。图0-2 小白的故事

0.2.2 小刘的故事

1.该如何请教他人

工作近5年的小刘特别勤学好问，工作中一遇到不明白的技术问题就问，有时问周围的同事，有时发帖子在论坛上提问。可是最近他非常郁闷，因为总是没人愿意回答他的问题。是不是大家不够团结友爱？非也！问题出在他自己身上，你们知道为什么吗？

让我们来看看他是怎么问的吧。“请问，对表的某列建索引如何建？”“请问，分区表中删除分区后，索引会不会失效？”“哦，您说我问过同样的问题了，我怎么记不起来了？”

前两个提问有问题吗？不少人都觉得一点问题都没有，其实是很有问题的。因为很显然第一个问题可以在搜索引擎中搜索到，而第二个问题除了可以搜索外，完全可以通过做一个试验来得出结论。

网上可以很方便地搜索到的东西去问别人无异于浪费别人的时间，当今这个时代，搜索能力成为最重要的能力之一。知道关键字的比不知道关键字的搜索能力更强；英文好的比英文糟糕的搜索能力更强。为什么不去锻炼自己这方面的能力呢？显然可以动手试验证明结论而不去试验，会让你白白失去一个宝贵的试验和总结的机会。

第三句对话暗示该同学经常问同样的问题却不自知，这说明了什么？别人告诉你答案时，你思考过吗，记录过吗，总结过吗？

2.问题该怎样描述

某次我在外地出差，下飞机后打开电脑，收到了小刘的一封求救邮件，内容是这样写的：今天早上上班发现宁夏的数据库很慢，请帮忙诊断分析一下，万分感谢！

之前我还收到过小刘的另外一封求救邮件，内容是这样写的：紧急求救，湖北数据库崩溃了，请尽快帮忙处理，谢谢！

从这两封邮件可以看出来，求救者严重缺乏经验，在沟通上存在着巨大的问题，你们知道是什么问题吗？

先说这个“慢”的邮件，是某个局部慢还是整个系统都很慢，不同情况的处理方式截然不同。是今天开始忽然变慢还是一直以来都慢，直至今天再也无法忍受，不同情况的处理方式显然是截然不同的。再说这个“慢”字，有一次我对求助者说，这个语句1秒就执行完了，你怎么会觉得慢得受不了了？他的回答是，原先只需要0.1秒左右，这个语句一天可是会跑上千万次啊。哦，原来1秒也让人觉得超级慢。还有一次有个求助者对我说，这个语句现在要跑2个多小时啊，原先超级快，只需要5分钟左右。哦，原来5分钟也有人觉得超级快。因此，你准确地告诉我现在要执行多长时间，希望执行多长时间，不是很准确吗？

再看第二封邮件，崩溃了？什么叫崩溃了，是数据库忽然关闭无法启动，还是系统运行太缓慢，还是数据文件丢失？哦，我来公布答案吧。后来知道这个“崩溃了”原来是指系统资源负载太高，系统运行缓慢。原来这就是崩溃了，为什么要说这么模糊的字眼呢？

还有，这两封邮件都有一个共同的特点，就是既没有提供接口人的联系电话，也没有提供所需要处理的机器的IP地址、登录用户名和密码。

毫无疑问，接下来我要再确认好多次，才能最终帮上他。

3.失误不只是粗心

小刘最近非常苦恼，因为近期系统经常遇到并行相关的等待事件，导致系统运行缓慢，后来查出来是诸多表和索引都有默认的并行度，这是因为系统很多大表通过并行的方式完成了创建，小刘创建完毕后忘记将并行度取消了。因为此事影响了生产系统正常运行，小刘被领导批评了，他也承认了自己过于粗心的毛病。

其实我们仔细分析就能知道，这种问题绝对不只是因为粗心。显然有一个更重要、更本质的东西没有揪出来，这就是流程和规范。

如果小刘在操作前事先准备好操作步骤，而不是即兴发挥现场操作，就不会忘记取消并行度的步骤。

即便他忘记了这个步骤，连脚本都没有体现，也没有关系。如果有规范，要求生产的操作准备脚本，并且必须要他人审核通过方可操作，那也就不会出错了。

即便审核的人也犯错了，如果有一个完善的流程，在生产中完成操作后必须检查哪些项目，那这个例行检查也必然会让错误再次避免。

人不是机器，都会失误，即便有的人素质非常高，不容易犯错，你也不能指望所有的人都这样，因此流程和规范才是最重要的。在本书中大家会发现我们都有哪些流程和规范可用来避免误操作。小刘的故事如图0-3所示。图0-3 小刘的故事

0.2.3 自己的故事

1.湖北神秘调优之旅

某日湖北某工程点向我求救，需要优化他们的生产系统，瓶颈正出在数据库上，为此公司让我去湖北现场进行调优。去之前我心里很没有把握，因为据说这个性能问题已经困扰该工程点半年多了，在这期间该工程点已经请过好几拨人马来调优过了，而且请来的人员中还不乏精通数据库的知名高手，这么多人这么长时间都无法把系统性能提升，我可以吗？

结果呢，我赶赴湖北现场忙碌一周后，该工程点生产系统性能最终得以大幅度提升，该工程点兴奋之余还发了一封表扬信到我公司，以此来肯定我的贡献。事后不少同事问我为什么那么多人长时间没解决的问题，而你一个人一周就搞定了，用了什么Oracle的高深技巧搞定这事的？实际情况是，我并没有用任何Oracle技巧，甚至我根本就没有利用到和数据库有关的任何知识，但是我却解决了性能问题，圆满完成了任务。这是千真万确的事。

我到底做了什么事，让我来公布一下答案吧。我到了湖北，和现场技术支持人员以及相关人员对当前业务深入交流了一周，精简改写了大量逻辑被人为复杂化的SQL，删除了部分多余的SQL，对大表的保留记录情况根据业务特点进行了合理规划，让不少大表变成了小表。

然后呢，然后就没有然后了，系统运行飞快，我胜利归来。这是一个很简单的道理，原先不少难以优化的、运行缓慢的语句被直接去掉，从系统中消失了，此外不少大表变成了小表，系统变快不是自然而然的事情吗？

2.三句话恢复的故障

某日早上10点，我接到项目组的紧急求救电话，被告知当天早上8点，某平台的生产系统运行极其缓慢，已经有相关人员在现场进行调查分析了，可惜两个小时过去了，直至现在依然没有解决问题，客户投诉不断，情况非常紧急。恰逢我在外地出差，且不说我在外地有重要事情要处理，即便是立即飞回来也需要一天的时间，该如何解决这个问题呢？

结果呢？10分钟后，在我的帮助下，问题解决了，故障恢复了。我做了什么事，这么神奇？

其实，我只在电话里和求助者交流了短短的三句话，求助者心领神会而去，然后问题就解决了。我是让他们调整什么神秘的参数吗？不！其实我用的方法和数据库的知识一点关系都没有，他们要是早点给我打电话就好了，免得相关技术人员折腾了两个小时，却无法消除故障，实际上这个技术人员的水平并不低，甚至可以说是Oracle方面的行家。

到底是哪三句话这么神奇呢？“系统是从什么时候开始变慢的，是一直就慢还是突然变慢？”回答是今早上班忽然感觉缓慢，昨天下班以前都是正常的。“那昨天你做了什么吗？”回答是昨天晚上升级了补丁。“补丁允许回退吗，如果允许，你就回退补丁吧。”回答是系统都不能用了，如果回退可以解决问题，当然可以回退。

接下来十分钟后，电话告知我，回退补丁后系统正常了，问题解决了。

现在不影响生产系统的应用了，剩下来的事情就是开发人员自己慢慢去检查代码有什么问题，最终问题在于代码有死循环和笛卡儿积，后续更改后投放生产就没问题了。

这其实就是生活，好比你去医院看病，肚子疼医生肯定会问你从什么时候开始疼的，如果就是今天早上疼，那接下来必定会问你昨天晚上吃了什么……

3.数据迁移有那么难吗

某日，某生产环境要做数据迁移，方法是通过 EXPDP 的方式将旧环境中的数据库导出，然后通过IMPDP的方式将数据导入到新环境，要求在凌晨2点开始导出，6点前完成导入，因为之后需要测试，必须保证上班时间8点前，新系统可以正常运行。

这里涉及的技能是掌握Oracle的EXPDP/IMPDP命令，如果今天让我来上课描述这个工具的使用，大致45分钟的时间可以完成课程的讲述，其中还包含动手试验的时间。因此这显然不是一件很复杂的工作，当时现场的操作人员是一位工作多年的、拥有 OCM 证书的技术人员，大家也都觉得很放心。

然而实际情况是，从凌晨2点开始操作，直至下午6点，才完成导入工作，整整比预计推迟了12小时！这期间虽然临时做了不少应急补救措施，但是还是严重影响了生产的正常运营。

为什么会这么糟，中间出了什么问题？其实这里的故事太耐人寻味了，需要改进的细节也太多太多了。

接下来揭晓谜底吧，还是通过一段对话展开。“请问你要导出的库有多大？”答曰不知道。“请问你要导出的库最大的对象有多大，能否列举前20名的大对象？”答曰没统计。“请问是否所有的对象都需要导出？”答曰应该是，没确认。“请问你知道导出和导入机器的CPU、内存配置情况吗？”答曰没注意。

好了，这就是原因了，让我来告诉大家我调查的结果吧。全库有1TB大，其中某记录操作日志的表T1就达到400GB，连同索引，大小合计500GB左右，近乎占一半的量。而和业务人员确认的结果是，T1表可以暂且不导出，只需在新环境中建表结构即可。前20名的大对象中除了巨无霸 T1表外，还有不少也很庞大，其中有一张单表即有120GB，只需保留最近三个月的记录即可……经过我的确认，1TB的数据最终只需要导出300GB左右。

接下来的调查还发现了更加惊人之处，导出和导入的机器的CPU个数居然都达到64个，强劲得让人惊叹！而我观察操作的脚本，也有写并行度，但只是随便写了PARALLEL=8。当时是凌晨，我们完全可以将导出导入的并行度设置得更大，比如设成60都不为过，这里又将会有5倍以上的提速。

后面我告诉他们，其实这次导出导入只需要合计2小时就足够了，不需要4小时，更不会操作了整整16个小时！

4.充分准备是要领

某次我应邀去安徽某工程点进行数据库调优，周二晚上接到通知，要求周三下班前赶到现场，周四一天之内要把系统性能显著提升，从而应对周五集团的检查工作，当时公司领导也在现场，情况相当紧急。

这是一件相当让人头疼的事，因为系统调优是一项相对复杂和艰巨的任务，要求在一天时间内立竿见影，可能性很小。虽说没有把握，但是也只好硬着头皮去试试看，我在出发前做了充足的准备，这些准备方法大多来自平时的积累，这种积累非常宝贵、非常重要。有了这些重要的准备，我在出发前通过工程点现场同事的配合，获取了大量我想了解的重要信息，在路上和飞机上做了充分的分析和研究，等下午6点到工程点现场，我已经对这里的情况了如指掌。

然后，晚上调优到凌晨2点，第二天再奋战一天，第三天，系统终于运行平稳了，IDLE从原先的0～1%变为40%～50%，系统性能显著提升。

这个小故事说明了一个道理，积极的准备是很重要的。我准备了一个非常详细的处理及定位问题的流程和思路，从动态到静态，从整体到局部，非常详尽和实用，将会在后续分享给大家。读者可以从中体会到我是如何定位以及分析探索问题的，此外，还可以学习到我所总结的优化思想和方法论。我自己的故事如图0-4所示。图0-4 自己的故事

0.2.4 故事的总结

至此我讲完了小白、小刘和我自己的故事。别小看这三个人的故事，其实都是非常典型的。这其中小白的故事告诉了我们学习是很有技巧的，是一门技术活。而小刘的故事告诉我们如何提问、求助以及制定规范是非常重要的。最后我本人的故事告诉大家，很多时候，解决问题不一定完全依靠技术本身，我的4个故事中的制胜法宝全部是非技术的，这说明技术虽然重要，但是不能仅仅依赖技术。技术人员的故事如图0-5所示。图0-5 技术人员的故事

0.3 收获Oracle，更收获“少做事”

包括我在内的几位技术人员的故事表面上说明的重点各不相同，实际上有一点是相同的，那就是一个非常重要的意识：准确地把握需求，尽可能少做事！不要小看了这句话，这是永不过时的一句话，生活难道不是如此吗？

精简起来可以用三个字概括：少做事。

就只是少做事？

别惊讶，让我们一起分析一下。

小白是一位数据库开发人员，数据库开发就是他的工作职责，很显然他的学习任务就是了解数据库开发的相关知识。他这时就应该选择性地进行学习，尽量抛弃和工作任务无关的知识，例如数据库的迁移、备份、部署等相关知识与他工作无关，就可暂且不学，这就是少做事。

暂时在工作中应用不到的内容先不学，何乐而不为？接下来我们还要保证精简学习的内容，要最快地掌握，别拖拖拉拉地学了三五年，这不符合这个时代的要求。这时最大的技巧就是将学习和工作结合在一起，带着知识点该如何落地应用以及什么时候该选择什么技术的想法去学习，这样目的性极强的探索性质的学习，往往学习一遍就够了，那些为了学习而学习的传统方法，学了很多遍往往也无法有效地应用到工作中去。这又是少做事。

小刘为了能更好地提升自己的技术水平，经常请教他人，希望快速获取别人的帮助。节省时间，本质是想少做事，这个出发点是对的，但是他问的问题是可以很方便地搜索到的，这样的提问对被提问者来说，就是让被提问者多做无意义的事，浪费生命，所以能搜索到的问题尽量不要去请教他人。同理，问过的问题也尽量不要再问。此外，自己动手做试验来证明结论，这件事表面上看不如直接问或者查资料来得快，不过试验可以让你在动手动脑的锻炼中加深印象从而过目不忘，和那些由于从不动手进行试验而导致学习过于浮躁、停留于表面，最终反复学习多次都无法很好掌握相关知识的人相比，显然也是少做事了。

小刘的两封邮件表达得过于糟糕，导致我一头雾水无从下手，最终必然要再次联系反复交流。为什么不养成好的习惯，一次性说清楚，让大家都快速投入到故障处理工作中去呢？这也是少做事。

接下来说小刘的工作失误，文档规范、评审等看似是多做事了，其实也是典型的少做事，因为公司、部门的工作大多都有通用性，有了这些准备资料，交接的工作者可以直接拿来使用，既准确又省心，就是少做事。

最后点评自己的故事。湖北之行是一次精简程序和为表瘦身的旅程，显然是一次少做事的经典之旅，三句话解决故障显然是一次最精简的故障定位案例。接下来说数据迁移案例，从导出1TB到导出300GB，是否很有技术含量，可以说没有，也可以说有。说没有是因为这真的没什么技术可言，说有是因为有意识的人比起没意识的人，差别是非常大的。最后说说安徽之行我准备的文档和脚本，且不说提前准备后让我一到现场就开始解决问题，少做了定位问题的事（提前在路上完成了），节省了宝贵的时间，就说这份文档和脚本的分享，足以让后人少做不少事，节省不少时间。

点评完三个技术人员的故事，我的书要怎么写呢？前面说了这么多，其实主要在谈如何少做事的意识，现在这本书的主基调就明确下来了，就是主要和大家分享少做事解决问题的思路和方法。

分享这个主题首先要选择一个场景或者道具来和大家讲述，选择什么道具呢？考虑到现在IT 行业中开发、设计、测试、维护等几乎所有 IT 相关技术人员，或多或少都需要接触到关系数据库，而Oracle又在当前关系数据库的市场份额中遥遥领先，因此学习Oracle会让绝大多数人更容易找到合适的工作，从而在就业之路上多一些选择，少一些奔波。于是本着尽量少做事的原则，我们的道具确定是Oracle。

围绕Oracle我们将会惊奇地发现，其实在Oracle技术本身的细节中，到处渗透着少做事的思想，从体系结构到物理结构，从表到索引的设计，无一例外。例如，SQL执行第二次就会比第一次更快，显然是因为第一次执行保存了共享池的解析动作，缓存了磁盘中的数据，第二次无须再解析，无须再去物理磁盘读取数据，从而提升了性能，这就是少做事。又如索引的体积一般比表小得多，如果能只访问索引完成需求一定比在表中进行更快，这也是少做事。再比如分区表，如果没有设置分区表，则需要全表扫描，如果设置了分区表，或许只需要在某个分区中查找即可，访问的路径少多了，这也是少做事……这些例子不胜枚举，多得可以写成一本书。哦，不对，就是可以写成一本书，这本书不就主要写这个吗？

本书不会将Oracle的所有知识都描述完，其中只涉及体系结构和物理结构，表、索引与表连接这几个章节，虽然涉及的内容不多，但却是非常核心和重要的，所有不同角色的人员都离不开这几个章节的学习，这是共性的部分，只有把这几个章节学好了，后面的学习才有意义，这是为了避免让大家像小白一样一头雾水、漫无目的地去学习，少做和自己任务无关的事。另外，最重要的是我讲述的学习的路线图和思路以及方法，这就是少做事的体现。

此外，我特别强调知识的落地，探讨最多的话题就是，学习这些知识有什么用，和不知道这些知识的人相比，在工作中有什么差别，从而保证大家不浪费时间。在这些章节中，大家将会和我一起体会，原来理解体系结构后，我们可以把一条常见的SQL语句的执行时间从原先的42秒完成提升到0.01秒左右，实现一次从单车到飞船的飞跃；原来理解了索引后，立即就可以着手优化身边最常见的SQL语句。

接下来书中有另外一个重点部分，就是我的方法论、工作习惯、实用的准备工作脚本以及相应的经典案例，这些章节再次强调了理解业务、尽量少做事或不做事的思想有多么重要。

这就是本书的全部内容，学完本书后，大家还会发现，原来用少做事的思想去学习数据库是那么亲切，那么容易理解和记忆。用尽可能将知识落地在工作中的意识去学习，学完后应用在工作中的那种感觉，是多么让人兴奋。

最后就是写书风格的确认了，这是一本非常有趣的书，灵感来源于我平时大量的授课。很多学员告诉我他们特别喜欢上我这样风格的课程，非常容易理解也非常实用。对此我很开心，猛然有一天有了这样的一个想法，将我的视频变成文字，这个想法得到我弟弟梁敬弘博士的大力支持，并答应帮我一起完成此书。于是全书就变成了“老师讲课、学生听课，老师提问、学生回答，学生提问、老师解答”这样轻松的对话方式。我终于实现了将视频变成文字。这本书成了一本轻松的书，读者很容易身临其境产生共鸣。而我讲述知识的方式也变得非常灵活了，有时故意不说的重点知识，在学生们的思考中被引发出来，而读者也一同经历了这个难忘之旅。本书还有一个显著的特点，就是所有的知识点推论都有试验证明，而这些试验读者完全可以自己进行，再现老师的结果。这在保证知识准确性的同时，能让读者进一步加深印象。不过全书最有趣的特点还是我构造的小余一家的故事。

学完本书后，大家就会发现，虽然当前数据压力比较大，但是并不可怕。其实调优如同生活一般，一点都不神秘。在老师的故事中，平均每处理10个成功案例中，就有5个不是依赖技术来解决的。牢牢抓住需求，在设计和开发中巧妙地应用“少做事，不做事”的思想，产品就能高效，且很少存在性能问题，因此就很少需要调优。

学完此书后相信大家会有一种强烈的感觉，原来学习技术可以如此轻松，原来学习要落地才有意义，原来少做事的意识这么重要。如果大家真有这个感觉，那我的所有努力—用心良苦的书写风格、精心构造的试验脚本、精彩有趣的经典案例就没有白费。我对于如何写此书的规划如图0-6所示。

最后我希望读者—收获，不止Oracle！图0-6 书该如何写

上篇 开启惊喜之门——带意识地学Oracle

第1章 意识，少做事从学习开始

本章的学习路线如图1-1所示。图1-1 学习路线

1.1 选择先学什么颇有学问

公司新人培训开始了，小莲和众多新人一样，坐在培训大厅等候梁老师的出现，今天的课程安排是Oracle数据库技能介绍。

之前已经培训4天了，大家先后学习了公共制度、公司业务、共通质量体系、企业文化、UNIX 基础知识……所有人都感觉很枯燥，也很疲惫。不过想到从明天开始公司会安排一周的新人野外拉练，心里倒是多了不少期待，大家都希望今天能过得快一点。

不一会儿，梁老师来了，准备好电脑和投影设备后，一天的课程即将开始。清了清嗓子，梁老师的开场白来了：“各位同学，大家好！你们都是刚离开校园的新员工，接触过Oracle数据库的同学请举手。”

小莲犹豫了一会儿还是举手了，毕竟实习半年了，多少也接触过一些Oracle相关数据库环境。她转眼看周围，举手人数大致过半。“看来还是有不少人没接触过Oracle数据库，”梁老师笑着说，“那有谁用过Google或者百度搜索工具？”梁老师继续问。

这下大家都举手了，小莲放眼望去，没有不举手的同学。不过，接下来梁老师说的话，让大家谁也想不到……“太好了，看来大家都懂得搜索，那你们在后续工作中，遇到 Oracle 数据库相关应用的问题，有困难去搜索就好了，今天我的课可以到此结束了，谢谢大家！”

台下沉默了半晌，接下来爆发出一阵笑声……“大家笑什么啊？”梁老师微笑地问大家，“是不是可以下课了，很开心？”

场下继续笑……“好了，大家都知道我是开玩笑，不过工作中遇到数据库相关的问题，不懂就去搜索，搜索到就应用，所以我不用教大家了，这有什么问题吗？谁能提提反对意见？”

小莲觉得这个梁老师挺风趣的，不像先前那些老师那么死板，也就不觉得紧张了。积极开动脑筋后她随即举手发言了：“梁老师，我觉得如果什么都靠搜索，那工作效率肯定会很低，应该是先系统学习所有相关知识，遇到少数回忆不起来的内容时再搜索，这样才可以高效地完成工作。”“回答得非常棒！”梁老师竖起大拇指表扬了小莲，然后继续问，“那你觉得今天一天可以系统地学完Oracle数据库的所有相关知识吗？”“那肯定不行啊，我看书店里相关的Oracle书籍都厚得超过一块大砖头，没个半年一年的，应该学不完吧？”小莲答道。“既然一天不可能学完所有知识，最终还要靠大家自己平时学习，那还有没有人指望今天上完课后，立即变得精通数据库且在工作中驾轻就熟地解决各类数据库相关问题呢？”

场下摇头、微笑……“下面，我会花10分钟左右的时间给大家介绍一下学Oracle要读哪些官方文档，然后……”梁老师顿了顿，继续说道，“然后，大家就可以回家慢慢研究这些文档，今天的课就可以结束了。”

台下再次沉默了，接下来又爆发出一阵笑声……1.1.2 看似跑题的手机分类“看来大家对可以下课回家真是非常开心啊，我可以回去休息，也很开心，大家都开心，好事啊！”梁老师打趣地说道，“不过为了避免被公司开除，俺还是要在这坚守一天。”

台下笑声不断……“好了，别笑了，我们继续吧！”梁老师开始言归正传了。“既然一天的课程安排不可能覆盖所有的 Oracle 知识，不能让你们立即就可以得心应手地工作，那我就干脆放慢上课的节奏，先和大家谈谈生活如何？”

上课气氛非常轻松，大家都觉得今天非常放松。“其实学习数据库和生活经历是一样的，是相通的，那我和大家说说生活吧，大家都有手机，我就先从手机说起。“大家拿到新手机的时候，首先想了解或者研究什么？”梁老师笑着问大家。“研究怎样接打电话。”“看看都有哪些功能。”“看看能否发短信。”“看看能不能上网。”“看看能不能拍照。”“看看能不能拍视频。”“看看有什么游戏。”

……“呵呵，回答得很热烈，非常好！大家回答了这么多，其实基本覆盖了手机的全部功能，我总结一下，大家最想了解自己手中的新手机有哪些功能，怎么使用，并想快速熟悉它，对吧？”“梁老师，您说的这个和 Oracle 技能培训有什么关系啊？”有些性急的小姑娘晶晶同学忍不住提问了。“你觉得有关系吗？”“梁老师，我觉得没关系啊。”“没关系，也可以有关系。”

小莲看到晶晶一脸迷茫，她也疑惑，这梁老师葫芦里卖的是什么药呢？“我们继续吧，一部中档的智能手机，一般就会提供非常多的功能，刚才大家七嘴八舌地也讨论了不少，那使用最多的、最常用的功能是什么呢？”“接打电话！”台下的回答几乎一致。“很好，那我再说说和手机有关的人群分类，我随意分类，将手机相关的人群分为消费使用者、销售者、维修者、生产设计者四类。大家觉得，如果这样分类，这些人群有什么明显的区别？”“关注的重点不一样！”戴眼镜的小伙子曾祥大声回答。“回答得太漂亮了！”梁老师满意地说道，“确实是关注的重点不一样！消费者关注的重点是手机的各种功能，如何使用；销售者关注的重点是价格、成本和市场；维修者关注的重点是故障的诊断定位；生产设计者关注的重点是手机原理、通信原理、行业技术标准、技术发展趋势等。“现在，我们来做一个总结吧，关于手机我说了三点：“一是了解新手机有哪些功能。“二是讨论这些功能中哪些是最常用的。“三是探讨与手机密切相关的人群如何分类。”“跑题的梁老师，在Oracle培训课上和我们谈手机！”台下窃窃私语、议论纷纷……1.1.3 学什么先了解要做什么“大家安静！现在我要开始说数据库了，欢迎回到Oracle培训现场。”梁老师停顿了一会儿，说道，“大家知道为什么我要说手机吗？”

摇头，还是摇头，台下半晌没人回应。“因为我觉得学习数据库技术和各种生活经历是一样的，所以我才随意举了一个手机的例子。”

疑惑，还是疑惑，台下依然没人回应。“大家都是刚开始接触数据库，好比大家刚刚接触一部新手机一样，面对数据库，你最想了解什么呢？或者说，你觉得数据库应该有哪些功能，请大家踊跃回答。”“数据可以录入。”“数据可以查询。”“数据可以修改、删除。”“不错，还有没有其他答案？”梁老师问。

半晌，没回音了……“没了？如果真没了，那我不是来给你们上Oracle的，而是来给你们上Excel的。好吧，请大家看屏幕，我新打开一个Excel文件，接下来我们进行录入、查询、修改、删除……”

台下爆发出一阵笑声。“笑什么？你们提到的三点，不就是在描述Excel吗？其实数据库和Excel等最明显的差别在于，数据库是有‘事务’的概念的。几笔不同的动作，如果在同一个事务里，要么一起成功，要么一起失败。举个场景来说明一下，好比你给你的朋友转账1000元，这里涉及两个动作，一个动作是从你的账户中扣款，另一个动作是在你朋友的账户中增加款项，两个动作必须同时成功，否则就必须回退。假想汇款成功而收款失败了，整个事务却不回退，那你将平白无故地损失1000元。“好了，现在新增一个支持事务，还有没有其他的？”

台下依旧一片寂静……“看来大家的思路没有被打开，我看还是继续说手机好一些，讨论手机的时候大家更踊跃一些。”

这下不寂静了，传来一片笑声。“这样吧，像刚才我们讨论和手机相关的人群分类一样，我们来聊聊数据库的分类，相信说完这个话题，大家思考数据库有哪些功能的思维就会更活跃一些。“手机的相关人群之所以可以分类，是因为他们的关注点不一样。这里我也是针对关注点的不同对数据库进行分类的。我认为数据库应用可以分为数据库开发、数据库管理、数据库优化、数据库设计4类，各类侧重点如下。“一、开发。能利用 SQL语句完成数据库的查增删改的基本操作；能用 PL/SQL语句完成及各类逻辑的实现。“二、管理。能完成数据库的安装、部署、参数调试、备份恢复、数据迁移等与系统相关的工作；能完成分配用户、控制权限、表空间划分等与管理相关的工作；能进行故障定位、问题分析等与数据库诊断修复相关的工作。“三、优化。在深入了解数据库运行原理的基础上，利用各类工具及手段发现并解决数据库存在的性能问题，从而提升数据库运行效率，这个说着轻巧，做起来其实很不容易。“四、设计。深刻理解业务需求和数据库原理，合理高效地完成数据库模型的建设，设计出各类表及索引等数据库对象，让后续应用开发可以高效稳定。“好了，说到这里，大家在回答数据库功能的时候，还会只回答4点吗？”“梁老师，我还能多说好多！”小莲听完这4个分类后，忍不住举手了。“很好，我们先不回答这个问题了，这个作为培训后的作业吧，带回去思考然后将自己的想法用邮件反馈给我。“大家和我一起分析思索了数据库的功能和基本分类后，也应该明白我为什么要举手机的例子了，你们不觉得它们之间确实有相通之处吗？其实这个相通，本质是因为技术和生活是相通的。还记得我问过大家手机的最主要功能是什么吧，大家都回答是接打电话。为什么要这么问呢？那是因为在生活和工作中，都存在二八现象，也就是百分之二十的功能实现百分之八十的需求。就以手机为例吧，一个传统的手机用户，百分之八十的需求就是接打电话和收发短信。而手机提供的接打电话和收发短信功能只占所有功能的百分之二十甚至更少。那对于比较传统的手机用户来说，他要花的精力是首先了解如何接打电话和收发短信，而不是把手机所有的功能都学个遍。“对于数据库学习而言也是如此，如果你是一名开发人员，就应该首先了解 SQL 语句和PL/SQL语句的编写，而不是数据库的备份与恢复。知识点非常多，但是我们要根据自己的工作性质有选择性地进行学习，这也是我将数据库进行分类的原因之一。手机销售人员首先要了解的是将要销售的手机的品牌、价位、成本、促销策略，而不是手机故障的定位诊断方法。“总结来说，我想表达的就是，你要了解数据库有哪些功能，数据库应用可以如何分类，并且要知道哪些是重点知识，即“二八”现象中的“二”，我们要先学习它们。这里需要大家用心去整理、去体会。”

结合梁老师所说的再回想起自己先前胡乱一把抓的学习方法，小莲猛然觉得有些顿悟，情不自禁地鼓起掌来，其他同学愣了一下，也都跟着鼓起掌来。

突然的掌声让梁老师发愣了一下，不过很快就会心地笑了。

1.2 善于规划分类才有效果

小莲“扑哧”一声笑了，在一片轻松的气氛下，梁老师让大家休息15分钟。1.2.2 角色自我认识有讲究

课间休息时间过得飞快，没一会儿梁老师开始召集大家坐回座位上课了。“大家好，前面讲述的那些不同数据库应用角色所需掌握的知识要点，大家还记得吧？”听到大家肯定的回答后，梁老师开始发问，“大家能否说说我的这个知识要点图有什么特点？”

一小会儿寂静后，晶晶举手了：“梁老师，我发现无论是哪个数据库角色，基本原理都是必学的。”“回答得非常好！”梁老师当即表示肯定。“梁老师，我发现数据库的各个角色中，设计人员最不容易，所有的知识点都需要掌握，而另外三个角色却都只是掌握一部分即可。”胖乎乎的小伙子敬昱粗着嗓音回答道。“完全正确！下面，我来详细描述这4个角色的特点。”梁老师继续说。“从企业需求来说，数据库开发所需人数往往是最多的，学会了SQL和PL/SQL的技巧后，大部分人直接就可以从事产品相关的开发，而无论哪个IT企业，从事产品开发的人员数量总是最多的。不仅是数据库开发，从事Java开发、C语言开发的人员，只要他的应用和数据库有关系，就必然会应用到SQL和PL/SQL，差别仅仅是多了一些封装工具而已。由此可见，数据库开发的学习是受众最广的，但是开发就离不开算法，对从业人员的逻辑思维能力要求比较高，尤其是面对复杂需求的时候。“相比数据库开发来说，数据库管理人员的人数需求在IT 市场要少得多。这是由工作性质决定的。无论生产还是测试环境，搭建数据库都不可能非常频繁。另外，如果数据库崩溃需要恢复、数据需要迁移、紧急故障需要处理的情况频繁出现，那这个企业基本上也无法正常运营下去了。但是一旦出现问题，管理人员无法及时恢复故障，将会受到来自各方面的指责，压力非常大。和开发人员相比，管理人员不需要每时每刻地忙碌着，但是却要时刻注意充电，提升自己的应急处理能力，还需要时刻对系统进行健康检查，以防不测。此外，虽然开发人员在逻辑思维方面的要求要高于管理人员，但是责任和压力却远没有管理人员这么大。“接下来说数据库优化的角色，不少企业没有设置专门的数据库优化角色，它可能被融入资深开发、资深管理和资深设计人员的技能之中。对于有这样角色的企业来说，场景是这样的：生产环境运行缓慢，数据库管理人员通过跟踪诊断，查出问题所在，原来是SQL语句运行缓慢导致的整个数据库性能低下。那这个时候对于数据库管理人员来说，他的工作结束了，然后优化人员介入，利用自己的知识优化这些SQL语句。在没有专门角色的场景下，可能是这个管理人员有着丰富的技能，他优化了这些SQL语句，也可能是资深开发人员或者是资深设计人员优化了这些SQL语句。但是从工作职责划分、从更专业的角度来说，应该设置专职人员。数据库优化所需要的人员是最难估算的，或许很多，或许很少，甚至没有，但是却是最重要的技能之一。其实开发、管理、设计三个角色，对优化相关知识的学习应该多多益

试读结束[说明：试读内容隐藏了图片]

下载完整电子书