连线文艺IT男：机遇偏爱有准备的头脑

大家好，我是主持人皮皮，欢迎做客第93期名人堂。这是美好的时代，也是糟糕的时代，有些人功成名就，有些人还前途未卜。狄斯累利说过，人生成功的秘诀是当好机会来临时，立刻抓住它，而难点在于，大数据时代里，我们怎么做才有一双抓住机遇的慧眼？提起大数据无人不晓，而谈起它的前世数据仓库却一直不温不火，貌似数据仓库这个前浪被大数据给拍死在沙滩上了，我们是否应该成为大数据的追随者？大数据到底是昙花一现还是会引领一个时代？本期名人堂我们连线北京蓝色曙光信息技术有限公司副总经理兼数据库技术总监史跃东（社区ID：caunique），为大家分享下他的传奇人生。

皮皮（A1）：  史总，您好！非常欢迎您做客我们名人堂， 请简单介绍下自己，谈谈参加我们的名人堂栏目有哪些收获？

史跃东（Q1）：大家好，小弟史跃东，06年毕业于吉大计算机学院，之后去天津做数据仓库相关的工作。在工作中遇到问题的时候，通过百度知道了ITPUB，自此与ITPUB及Oracle结下了不解之缘。07年底我到北京，就一直在帝都工作到了现在，先后为N多客户和公司提供过技术服务。然而时至今日，始终觉得技术之路漫漫无极，固然在Oracle圈子里面已经混了八年之久，却一直不敢认为自己是高手，反倒是越学越心虚了······

去年下半年至今年年初，先后考取了PMP，以及Oracle 10g、11g双料OCM。今年七月份，加盟北京蓝色曙光信息技术有限公司，与两位志同道合的朋友开始共同创业，从而在IT技术培训和外包服务领域蹒跚起步，筚路蓝缕，以启山林。虽不敢说公司将来一定能如何如何，然事在人为，尽心尽力便无怨无悔了。

ITPUB是国内Oracle高手聚集之地，名人堂更是众家宗师华山论剑之所。跃东何德何能，竟能蒙盛总及皮皮美女抬爱，与诸位名家前辈同列，实在惭愧。然各人经历皆不相同，所学所长亦是如此。跃东也就趁此机会，谈谈自己的经历，和自己对Oracle以及大数据的一些看法，希望各位网友能够有所借鉴。倘若是有一二网友能够在我的这次访谈中有所收获，则欣慰至极。

皮皮（A2）：这是美好的时代，也是糟糕的时代，有些人功成名就，有些人还前途未卜。回顾您的DBA之路，您觉得这是一种机缘巧合，还是努力与坚持的选择？能否和我们分享下您的心路历程？

史跃东（Q2）：  其实于我而言，甫一毕业，就接触到了Oracle。不过当时只是用Oracle的owb以及BIEE做数据仓库相关的东西。底层的数据库，用的就是Oracle 10g。到了06年底，我买了老盖版的深入浅出，开始认真看数据库相关的东西。不过当时的重点，依然是在数据仓库上。

    到北京后，开始参与到联想全球供应链系统的运维工作中。08年四月份，公司请来一位DBADBA来为我们做技术讲座。这个时候，我才真正接触到了DBA的DBA，了解了这个行业的一些情况。于是就觉得，既然自己现在空闲时间挺多的，那就研究研究Oracle呗。接下来，我花了半个月的时间，把10g的concepts认认真真的看完，之后决定把DBADBA作为我未来的职业发展方向，随后便开始翻阅administrator's guide、backup and recovery、performance tuning等等。后来公司原来的DBA离职，忽然就发现原来整个公司研究Oracle的，居然只有我一个人······于是乎，我就硬着头皮咬着牙顶上去了，然后苦逼悲催的DBA生涯，就这样开始了······

    多年之后，再回顾这段经历，觉得也挺有意思的。如果自己当初没有去研究Oracle，没有去翻看它的各种官方文档，那么公司肯定是要从外面招聘DBA过来，我自此可能就不会去接触DBA这行了。我相信有些同仁也有类似的感觉，想做DBA，但是苦于没有机会。可是我想说的是，恩格斯曾经说过：机遇，偏爱有准备的头脑。往往有很多时候，我们会觉得自己就差个机会，可是一旦机会真的降临，我们就一定能抓的住么？我们所能做的，就是认认真真、踏踏实实的磨练自己的技术和能力，然后，静静的等待机会的到来。天道酬勤，我相信，机会女神，一定会光临那些愿意付出，愿意一直努力前行的人。有时候，我们总觉得老天爷为什么不帮我们。可是，你想让人家帮你，你总得给个理由不是？勤奋，显然是一个极好的理由。

    无论如何，我的DBA之路就这样开始了。在联想忙的时候，我曾经连续两周，工作连续超过四十个小时！失眠严重之如我者，也能达到困得坐在办公桌前闭上眼睛就能沉沉睡去这样的程度。后我们合作方的项目经理都看不下去了，直接发邮件说，以后谁要想让我们的跃东同志做DBA方面的一些工作，请提前预约好嘛！不过熬过这段时间后，接下来的就好多了，不管遇到多么困难的事情，多么棘手的case，我基本都已经可以做到面如止水了。

    后来离开联想，辗转来去，又做了几年外包。13年7月决定辞职，专心考了10g、11g的ocm。在这期间认识了咱们伟大的盛总，一起研究攻克11g ocm upgrade的相关技术。接下来因为恩墨要准备开设11g直考的培训，我又忝为恩墨11g ocm教研组的负责人，负责整个培训相关的技术和文档整理与工作分配等任务。虽然我确实是去年6月份考了PMP这种项目管理的东西，可是我一直觉得，能做这个教研组的负责人，大原因是我比较闲，我当时是个无业游民嘛：）。

    如果说，在联想接手当时离职DBA的工作，算是我的个机遇，随后在恩墨成为11g 教研组负责人为第二个机遇的话。那加盟蓝色曙光，踏上创业之路，则是我的第三个机遇了。可是再回想起来，在联想的时候，整个公司只有我一个人坚持学习Oracle；在恩墨的时候，我被一位学员评价为他在恩墨认识的人当中，认真的人并且没有之一；当初和蓝色曙光其他两位创始人共事的时候，我认真负责的做事态度让他们印象深刻·····如果没有这些，这些机遇，会降临到我的头上么？

我并不是想说冥冥之中自有天意。只是，我们的品行，我们待人处事的方式，我们始终以来一直坚持为之奋斗的目标与梦想，所有的这些，都在有意无意的，影响着我们的将来。我并不否认这其中会有运气的成分存在，可是，努力、向上、认真、坚持，这些，可能才是我们能够把握，并且做到的东西。我的座右铭是天道酬勤，愿与大家共勉。

皮皮（A3）：相比很多高富帅，IT男这一曾经被社会笼罩光环的职业男性，现在已经被很多人戏称为“屌丝”，您发表过10万字的长篇小说，作为一名文艺青年，能否分享为我们IT男代言？分享下如何抱得女神归的经验。

史跃东（Q3）： 关于发表小说这件事情，是去年九月底的事情了。当时是因为准备10g OCM已经学习的差不多了，可由于考试时间是在10月底，就想找点事情来做。恰好自己脑海里面也一直在构思一部小说，既然如此，那就写出来呗。于是从9月22开始，一连敲了十二天键盘，完成了这部《受害者自白》，然后，发表在腾讯旗下的云起书院上。

  自己从小时候开始，就特别喜欢看书，作为一个理科生，我的文学功底，已经远远超过了不少我认识的文科生。我是吉林大学在北京的一个超级群的群主，里面经常有不少文科校友就说我：群主，你作为一个理科生，为什么文章写的比我们文科生都好，你让我们还怎么混嘛！我说，没办法，哥当年高考的时候，是文理大综合·····

  至于追女生这件事情吧，我也不是什么泡妞高手，委实也没什么太多的经验可以分 享。不过我觉得，DBA是个相对纯粹的技术职业，有些爱好和特长，会让自己的生活更有味道，更丰富多彩一些。我们IT行业的男生，一向都让女孩子们为难不是？我们认真可靠，踏实努力，我们工资也不算太低，可是就是太闷，缺少幽默，缺少乐趣。 女孩子有几个不喜欢温柔浪漫的？你若是能够偶尔为你喜欢的女孩子写首文采飞扬含情脉脉的小诗，或者弹奏一首宛转悠扬的曲子，还怕人家不到你的碗里来？

    毕竟，生活不是只有Oracle的。要说为IT男代言，这个这个这个这个······我这种无长相无身材无口才无背景的家伙，还是算了吧。

    ps：至于发表在云起书院上的小说，其实后来的故事是这样的：云起书院那边此后不久就发了合同过来，想让我成为他们的驻站作家，每月定期发表连载小说。我考虑了一下，觉得写小说终究是我的爱好，倘是因此而失去了舞文弄墨的自由，怕也未必是什么好事。于是我决定不签那份合同，然后云起书院那边，直接就把我的小说删除了······

   皮皮（A4）：俗话说，不积跬步无以至千里。您曾先后为天津电力、联想电脑、方正集团、上海百事、四川电力、建行北数等单位提供技术服务或技术支持，积累了长期的数据库性能诊断与优化经验，在项目维护中会遇到哪些常见的故障诊断？能否结合案例和我们分享下数据库性能诊断与优化的技巧？

史跃东（Q4）：性能诊断与优化方面的案例，目前网上和相关的书籍资料都已经相当的多了。诸多高手珠玉在前，我还是少献丑为妙。我就当时在联想做DBA的时候，遇到的一个例子，做一个简单的描述，及相关的问题阐述吧。

    在实际的项目维护中，一段sql或者存储过程运行速度过慢，然后客户要求对此进行优化，这种情况可能是为常见的。而我要说的这个case，就是这样的问题。那天，联想深圳有用户报告，说一个天天都运行的存储过程今天忽然就特别的慢，跑了将近一个小时都没有结束，让我们解决一下。我们起初以为是有其他用户也在进行相关操作，锁住了其中的某一个表，结果发现没有。然后去察看执行计划，看表连接的方式，索引的状态及使用情况，也都没发现什么可疑的问题。于是我们就想，这段存储过程每天至少运行四次，是生成联想的深圳生产基地每天每次生产线运行时的相关物料数据的。后来就有人提到说这次物料特别多，可能数据量比较大造成了存储过程运行缓慢吧。然后我们就有了疑问。因为联想这边很多的存储过程，其每天的运行次数都和工厂的排班次数相关。为满足每次运行时的数据都可能不一样的情况，我们特意对一些表的统计信息进行了手工收集的设置。总不至于是这块出了问题吧······

    我们去查了下统计信息的收集时间，是新的。然后我们又去看收集的统计信息跟实际表中的记录对比，发现收集的表的记录数，跟实际表中的记录数不一致，这显然是有问题的。于是我们去看了收集这个表的统计信息语句，是采用了Oracle提供的默认值进行收集的。也就是说，DBMS_STATS. GATHER_TABLE_STATS中的estimate_percent参数，我们在收集统计信息时，将其值设置成了AUTO_SAMPLE_SIZE。

    当时问题拖的时间已经比较长，于是我们直接把这个参数设置成了100，也就是让Oracle完全收集这张表的统计信息，结果问题解决。但是我把问题记录了下来，开始研究，AUTO_SAMPLE_SIZE在10g中，它的值到底是多少。

    当然现在这个问题已经不重要了，我这里只把测试这个值的方法说出来，各位可以自己测试（例子中的数据库版本，为12.1）：