怎样成为明星DBA

内 容 提 要　　本书汇集了作者有关数据库管理的真知灼见，讲述了DBA 的方方面面，有技术的，还有生活的。作者本人不仅专业技术过硬，还当过篮球教练，对人生，尤其是DBA 的生存之道有很独到的领悟。书中语言浅显易懂，生动幽默，还配有多个技术审稿人的精彩评注。这些评注与作者的文字相辅相成，和而不同，因此本书可谓是博采众家之长，绝对值得一读。　　本书为DBA 量身订做。如果你是DBA，那么一定不可错过；如果你有意成为DBA，或者想了解DBA 的生存之道，本书同样适合你。目  录第1章 我是怎样做到的第2章 我要做点什么第3章 基础知识第4章 开发服务器就是开发人员的生产服务器第5章 生产支持第6章 基本的故障检修第7章 该吃点什么第8章 培训，为你加点料第9章 联系、学习、分享第10章 总结第1章　　我是怎样做到的　　你很难向别人解释你是怎样凭着数据库管理工作谋生的。我们在构建服务器的人和希望在这些服务器上存储和检索数据的人之间起着沟通的作用。因此我们需要对很多事情有着很多的了解，而这种要求有时会十分惊人。这么多的要求让我有时会停下前行的脚步，反省自己的生活究竟是什么样的，并扪心自问：“我是怎样做到的？”　　经常有人会问我两个问题，一个是：“你是怎样成为DBA的？”另外一个是：“DBA究竟是做什么的？”这一章会详尽回答前一个问题，而后几章则会解释后者。对大多数人来说，成为DBA是一个很神秘的过程。在这里我会分享我的经历，以及其他人的一些经历，来帮助你们更好地理解一些人最终是如何成为DBA的。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　请多留意自己想得到的信息，因为你很可能能在这里得到这些信息。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　在本章中，我们将会谈到：　　(1) 我的经历；　　(2) 别人的经历；　　(3) 你的经历；　　(4) 保持专注。1.1　我的经历　　我是怎样成为一个DBA的？可以肯定的是，这并不是我小学时候的梦想。那时候我其实更想成为一个消防员或者警察。　　我并没有打算成为一个DBA，至少最开始是这样的，在我职业生涯的开端我并没有打算成为一个DBA。我涉足DBA领域纯属偶然。别人可能说我这是走了狗屎运，但我更愿意将这看成是我的灵光一现。1.1.1　早期的学习过程　　我的第一台计算机？那是Commodore VIC-20。我记得那时靠修剪草坪攒够了钱，然后我姐姐开车带我去了商场，买下那台可以用射频转接器连到电视上的机器。我还买了Datasette磁带机，这玩意儿其实就是台卡带录音机，不过它可以让我保存程序，这一点真的很不错。　　我买了本程序书，然后自己敲程序去运行。但有时书里面难免会有印刷错误。想象一下，如果书里面的程序落下了一些很重要的内容，那该多糟啊。我就不用想象，因为我经历过这样的事情。那时我经常要调试程序。我想这就是我现在会采取迭代式调试的原因，我总是会在写程序的过程中做一些小的修改并检验其效果，而别人则可能更喜欢一气呵成，在做完所有的事情后再来调试。　　我在年少的时候，除了很喜欢计算机，还对数学非常感兴趣。这两个领域都需要做大量分析，为我后来的生活奠定了很好的基础。对了，它们都不需要我连篇累牍地写文章，这点也很不错。事实上，我上大学时学的也是数学专业，就是为了能少写点学期论文。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　多劳多得，从长远来看，更多付出意味着更多回报。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　不幸的是，写作经验的欠缺让我读研究生时碰了钉子。在我第一堂课上，教授就要求我写出解决方法，而且让我使用文字“二”而不是数字“2”。我不能直接用等号，而是必须写出文字“等于”。这对我来说真是个痛苦的调整过程，但这种转变让我受益匪浅。到那时为止，我懂得了另辟蹊径有时会让自己到达一种更理想的境地。　　在研究生院学习时，我们可以选择参与一些硕士项目作为硕士学业的一部分。由于我很早就明白多劳多得的道理，所以就决定参与一个项目。那时华盛顿州立大学的数学部和天文学部合并了，而且我本人对地球以外的事物有着浓厚的兴趣（到现在还是），于是我询问了一个天文学教授能否让我合作一个项目，他答应了。　　项目名叫“星团间的星际辐射场”，而且包括了不少编程的工作。这可不是Commodore VIC-20编程了，而是FORTRAN77、Sun计算机、天体物理方程、数列、望远镜、图表、图形，甚至是LaTeX。我在很短的时间内做了一大堆编程工作，后来我从华盛顿州立大学毕业，拿到了数学学科的理学硕士学位，足够的编程经验帮我顺利找到了一份工作。1.1.2　早期的职业生涯　　我觉得硕士学位会有更多的工作机会，所以没有继续读博士就从研究生院毕业了。我去参加面试，那个面试官是个物理学博士，当时我们主要谈了我在华盛顿州立大学完成的项目。他需要会用PowerBuilder编程的人。我现在还记得他对我说的话：“我能教你要做什么，我知道你能行的。”　　就这样，在没有任何PowerBuilder使用经验的情况下，我被聘用为一个PowerBuilder开发人员。　　我在那儿待了一年半，后来就跳槽去了一家需要PowerBuilder开发人员的软件公司。当然，跳槽的时候我已经有一些PowerBuilder开发经验了，不过我还是没有和现实的数据库打过交道。我所知道的就只有数据会存在某个特定的地方，然后需要时它能回到我身边。在那里工作时我确实有所收获，比如了解了数据库设计、触发器和存储过程，还发现自己对学习更多知识很感兴趣。　　又过了一年，我应聘了一家需要PowerBuilder开发人员的新公司。我得到了那份工作，在差不多一年之后，我开始有了两点认识。第一，我应该学习点PowerBuilder之外的东西，因为总有一天PowerBuilder可能就不足以帮我找到工作了。第二，我想成为一个DBA。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　在生活中找点让你充满热情的事情，这会让你做其他决定变得容易。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　我当时对DBA这个角色的看法是，它不像那种只通晓某种特定语言的开发人员会被技术发展的浪潮淘尽。就此而言，我已经完成了不少PowerBuilder的工作，并且已经开始学习.NET技术。当时，一想到为了让自己立于职场潮头而每隔几年就得学习一种新语言，我就心生畏惧。但是做DBA就意味着我将成为一个“幕后人士”，总有出路，总能找到工作。　　所以我就想尽办法来做一些DBA的工作，当公司想招聘一个全职DBA时，我带着自己的简历去人事经理那儿毛遂自荐。但她当时就告诉我，他们不会考虑招我来做这个工作，因为我没有相关经验。他们要找的是以前有过DBA工作经验的人。我小感失望，然后这个经理就告诉我，公司可能会开展一个“初级DBA”项目，培养一些后备人才以备不时之需。她希望将我列为有意参加这个内部培训的人员，我答应了。Ozar评注：不学怎成才　　如果你想成为一个DBA，而公司又不打算派你去培训，那么问问人事部门能不能让你每周抽出一天去跟着公司的DBA学习。如果他们不答应，可以问他们万一哪天DBA离职或不在该怎么办。难道多拥有几个对公司数据库的运行小有了解的员工不好吗？这一点应该会让他们开展内部辅导活动。1.1.3　运气、准备和机会　　我在从事体育和教练工作的那段日子里明白了一个道理，那就是运气其实是在面对机会时自己有所准备。我抱着这个想法参加了公司组织的初级DBA课程。我不知疲倦地吸取着各种营养，久而久之，我也会请求公司让我去完成一些日常的任务，并能得到些高质量的现场培训。后来，那两个全职DBA需要放上一天假时，他们可以放心地把事情交给我这样的人来完成，而自己可以去休假。　　我已经能越来越熟练地处理大量的日常运行任务，备份、恢复、密码重置、创建登录信息，甚至是一些性能调整和排障工作。我还开始参与到为系统环境配置必要监控措施的工作中，协助构建一个内部监控解决方案，以使我们在解决问题时始终能先行一步。同时我还做着原来的工作，和PowerBuilder、.NET和SQR报表打交道。　　直到有一天，时刻准备着的我终于等来了机会。原来那两个DBA在年末都离开了。其中一个是其他公司外派来的，他有了新的任务，另一个人则是不想在这个公司继续干下去了。他们部门的经理来找我的部门经理谈了谈，然后他们问我愿不愿意去当DBA。我们部门的一个同事当时就说这个职位对我而言是个“巨大的机会”，我走进办公室，去和经理们谈谈这个职位的事情。　　我告诉他们我还需要点时间来好好考虑一下。哈哈，我只是不希望表现得太过热切而已。Gennick评注：有时候运气是自己创造的　　“有时候运气是自己创造的。”在我得到一份对我整个职业生涯而言都至关重要的一份工作后，一个朋友曾对我这么说过。那时我为了混口饭吃，找了个COBOL开发工作，做了两三个月后，客户突然决定中止项目，中止了包括我在内的一干人等的劳动合同。　　那时我喜欢的是SQL，所以我尽各种可能去接触项目的数据库端。基本上整个I/O例程都是我做的，因为我对COBOL和关系数据库都很了解，知道如何将它们结合起来。我工作仔细，有着很好的态度，而且对工作充满热情。回望过去，我做得很不错，我的激情也感染了我的同事们。　　我的一个同事（我们办公室做这项目的一共有三人）对我多有关注，而正是他后来将我带到了一家国际咨询公司。在那里我学习了Oracle，这让我后来写了好几本书，也给我的职业生涯带来了改变（还是因为我的热情和充分的准备），还让我可以住到我梦寐以求的密歇根州上半岛 区域。我在整个职业生涯中有着不少“运气”。但就我记得的这些而言，真都像Tom所说的那样，所有的“运气”都是辛勤工作、时刻准备及个人成长与机会不期而遇的结果。1.1.4　社区　　所有这些都有种恍如隔世的感觉。期间我的两个孩子出世，感觉甚至都是三辈子的事情了。一路走来，我明白了仅凭一己之力是很难成为一名好的DBA的，所以我会和其他DBA打成一片。网站、论坛和会议都是我结识他们的场合。现在我总是对别人说：“你结识的可不只是我，而是结识了我的人际关系网。”　　不久之后，我就开始写些文章，帮助他人并出席一些会议。在2009年，我成为了SQL Server专业协会（PASS）理事会的成员，并成为了SQL MVP。这对我这个靠PowerBuilder开发出道的人来说也算不错了。　　这就是我走上DBA之路的全过程了，包括我在内，很多人都很想知道别人是怎么成为DBA的。很多例子说明，成为DBA都是种机缘巧合，但通常都可以说机会的大门只为有所准备的人打开。我的经历绝非个例，当然，我在这里也不会只介绍自己的经历。我问了我的同事们是否愿意与大家分享他们的经历，下面就是他们的故事。1.2　别人的经历　　条条大道通罗马，成为DBA的过程也是多种多样。迂回前行的人可远不止我一个。我们中大多数人都有着一些技术背景，而且有着不错的组织或分析才能。但事实上这些技能也能应用到其他的领域。例如酒店经理也需要组织能力，也要注意细节，还要能理解和维护记录房客信息的销售点终端软件。　　几乎没有学院或者大学开设数据库管理专业。大多数学校只会开设计算机科学专业，或是某种信息系统专业，但这些都不是为成为DBA服务的。学校可能会开设一两门有关数据库设计或数据库理论的课程，但基本上都不会包含灾难恢复、高可用性、服务器配置等DBA需要了解的知识。所以这也不难理解为什么大多数人的DBA之道都非坦途。事实上，成为DBA之前我们也可能在一些地方遭受挫折，并一度要去决断自己是否热爱那份工作。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　Buck Woody在华盛顿大学开设了DBA课程。如果可能的话，报名参加吧。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－1.2.1　药剂师　　在当了16年药剂师之后（期间她要帮着配置一些Microsoft Access应用），Kathi决定离开她工作的医院，找一份程序员的工作。她学习了一些Visual Basic 4和HTML方面的知识，创建了她的第一个ASP网站，并开始用SQL Server 6.5。在干了半年的编程工作后，她在公司转岗成了一个全职DBA。她现在也已出版过著作，并且是SQL Server MVP。1.2.2　酒店经理　　经历了作为酒店经理的糟糕时光，也接待过一些最无礼的客户，Brent偶然发现了Quattro Pro和电子表格。厌倦了长时间的工作，尤其是在假日还要无休止地工作，他决定去IT界找找机会。工作时长的情况确实略有好转，不过现在他得带着个呼机随传随应，这其实也算是一定的倒退吧。不过他学到了很多有关服务器和数据库的知识。现在他也是SQL Server MVP。1.2.3　估算总监　　其实我也不太能拿得准是不是有这么一个职位，不过这就是Tim很多年前做的工作。这个职位并不很合他心意，于是他的一个朋友开始让他自学T-SQL。那时，即便他知道得去做Access开发工作，也还是毫不犹豫地换了工作。后来公司决定让他去当SQL Server DBA，其实他当时并不是很想做DBA，不过10年后他却为得到这样的机会深感幸运，他现在也成了SQL Server MVP。1.2.4　MUMPS程序员　　Jonathan曾经是一家大型化工公司的MUMPS程序员，他的职责是给用MUMPS编写、运行在DEC VAX/VMS上的工业卫生和医疗系统提供技术支持。有一天他接到通知，公司决定使用关系数据库重新编写这个系统，以实现后端存储。　　公司计划让系统遵循关系数据库标准，所以Jonathan在VMS命令行中输入了“HELP RDB”。他如饥似渴地学习着在线帮助和技术手册，创建了用于实验的数据库。他迷恋上了SQL的强大功能，而且很快便成为他所在部门中的数据库技术高手。此时，他开始想成为一个DBA。　　他没能在当MUMPS程序员时成为DBA，最后还被炒了鱿鱼。　　他在很多短期合同项目中做COBOL程序员时也没当上DBA。　　他在做Visual Basic程序员时还是没成DBA。　　他当PowerBuilder程序员那会儿也差点就没成DBA。　　终于有一天，公司的DBA辞职了，Jonathan总算得到了一显身手的机会。这下他终于能叫自己DBA了。　　要说Jonathan有什么出众的地方，那就是他的坚持，他坚持了5年多。他在各种语言的开发工作中都表现优秀，这让他可以维持生计，不过最重要的是他始终在不断强化数据库技能。　　当DBA走人之日，就是你走运之时（别忘了，机会只会给有准备之人）。Simmons评注：你被选中了！　　这里介绍的似乎都是主动请缨成为DBA的故事。而我一直在等待这样一种情景的出现，那就是经理主动找到开发人员，然后说：“嘿，就是你，你现在是我们的DBA了。”1.3　你的经历　　如果你想成为一个DBA，那应该从何开始呢？你获得了特定的学位吗？你有没有尝试过初级DBA工作呢？在没有DBA工作经验的情况下，要怎么才能做上DBA呢？你有哪些走上职业道路的方式可供选择？　　一如很多专业领域，成为DBA看起来很困难。成为DBA之所以困难是因为大多数时候都需要有人来扶你上马，送上一程。你需要有人给你一个成为DBA的机会，而在这之前，你还得为此做好准备。而你又如何为一个你不甚了解的职位去做准备呢？Ozar评注：多积累生活经验　　就算是接受过正规教育，也没法保证你能得到份DBA的工作。一个公司最宝贵、最具价值、最无可替代的资源便是它的数据。公司必须确定它们的DBA是值得信赖而且经验丰富的，这就意味着它们通常不会让初出茅庐的毕业生来当DBA。回顾一下这一章和其中介绍的一些人成为DBA的过程吧，考虑考虑自己的生活经验如何才能转换成可信度的。1.3.1　做好准备　　如果你已决意成为一个DBA，那么开始做些准备吧，只有这样，当机会来敲门时你才不会错过。如果你自己不主动，而是想守株待兔，等着别人把一份你梦寐以求的工作送上门，那还是省省吧，基本上好事是不会自动找上门的。　　那怎样做才能让自己做好准备呢？首先我建议你从日常工作中找寻能获得一些DBA经验的机会。如果你还不是IT业人士，那么你的选择就更有限了，但倒也不是毫无机会。要是你已置身IT界，那么就多做点数据库设计或者是性能调整工作。　　如果你是一个希望成为DBA的开发人员，我可以教你很多方法来获得有价值的经验。学会熟练完成性能调整工作，而不是哭着喊着让人给你个系统管理员（SA）权限来完成这任务。如果你对系统有着充分的了解，在不得到管理权限的前提下就能对性能细节了如指掌，那么你基本能算得上是“准DBA”了。　　如果你发现其实很多DBA在完成很多日常任务时根本就不用SA权限，你也许会感到非常惊讶。而且现在越来越多的公司对数据访问级别有着更严格的控制，你就会明白，学会用尽可能低的权限去完成自己的工作是很有必要的。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　要学会在不取得系统管理员权限的前提下完成任务。以后这些技能会给你带来不少好处。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　如果你现在的角色决定了你不大可能去完成一些可能和DBA有关的额外工作，那么就去找一个当班的DBA，然后让他来告诉你应该怎么做。大多数DBA都很乐于帮助其他同事更多地了解系统，因为这样做意味着他们在为你们排障时可以更省心。毕竟DBA的工作比较被动，他也想省心，其实我们大家都喜欢找点让自己活得更轻松的方法。　　那要是本职工作对此无所裨益呢？好吧，你可以考虑拿出时间去做志愿者，有很多慈善组织需要义工。有可能当地教会就需要人手来打理他们的计算机，也许还要人来维护一两个数据库。这可能不是有着10TB的大小，每秒要处理15 000项事务的大型数据库，但好歹它也是个数据库，对你而言这是个很好的学习机会，而且将来也可以给自己的简历添上一笔。Simmons评注：当个好管家　　请注意，数据就是数据，即便是志愿者，你也得明白凡事要量力而为的道理，做事一定要谨慎，切不可犯下大错。要知道DBA失误的后果要比编程错误的后果严重得多。就算做志愿者工作，也一定要满怀责任心，要像对待本职工作那样认真对待。　　如果你没什么兴趣将自己的时间花在做义工上，那么你应该有个能让你学到东西的爱好吧。就我而言，我喜欢《梦幻橄榄球》这个游戏。几年前我曾参与过一个定制网站的建设工作，这个网站有着后端数据库，于是我有了很多的学习机会，对我后来成为DBA有不小帮助。　　当然还有一招，那就是在网上找点兼职来锻炼自己。你可能在网上找到一些数据库方面的外包工作。这样的职位是确实存在的，有些不要求应聘者多有经验。多数情况下，被雇用的人都可以直接做初级DBA。当然，我还得提醒你一句，看到那些吹得天花乱坠的广告时，要多长个心眼，天上掉下来的，可不一定是馅饼。1.3.2　参加培训　　想做好准备，不参加点培训是不行的。培训可以是各种形式的，既可以是用参考书培训，也能是课堂培训，或者是在线培训，当然，前文所说的在职培训也是其中一种。其他的培训机会还包括研讨会或是技术会议等。　　选择参加何种形式的培训不是关键，关键是你总算走上DBA之路了。即便是当了DBA的人，也会不时去参加某些形式的培训，当然，如果你也能如此就再好不过了。将参阅网站作为每天的功课，找一些其他人推荐的书籍，每天都给自己留一些用来培训的时间。如果你想找一种最具效率的培训方法来快速成长，那么送你三个字——教别人。　　如果你真想学好某种知识或某门课程，那么不二法门就是把你学的东西教给别人。就拿数据库管理方面的事来说吧，比如索引，你就试着给别人解释索引的工作原理吧。你会发现你越是教得多，你对知识的认识就越深，你就会变得越强。　　经常有人问我，如果他们想成为DBA，应该要取得什么学位。我会告诉他们其实学位这回事远没有他们所想的那样重要。总的来说，学位只是种可以量化的东西，仅此而已。其实如果你本来就没什么动力，那什么教育手段不都是白搭吗？只有当教育遇上动力，你才能如鱼得水，焕发活力。1.3.3　获得认证　　有太多太多人详述过认证的价值了。我相信证书能很好地向别人展示你的价值。不过我不相信这东西能把一个人的方方面面和他的真实能力表现得淋漓尽致。　　如果你敢把一心考认证当作一条成为DBA的捷径，那么千万别指望用人企业只看了你的证书就会聘用你。如果你既有证书，也有一些实际的工作经验，那么你会发现，为你敞开的大门要多了不少。　　麻烦在于认证这个东西也可谓鱼龙混杂，很多公司会开设培训班，可能你去那样的培训班混上一两周，然后就能获得某种特定技术的证书了。这种现象的存在自然会让别的认证跟着掉价，也让想招聘人才的企业很难弄清楚这个认证是不是反映了你的真实水平，也很难知道现在你是不是把这两周学的内容全都还给培训班了。－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　证书加经验威力无穷，就像教育加动力天下无敌那样。－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　还要记住，有很多水平挺高的人根本就不屑于去考证书。实际上很多人只是把认证考试当作铺路砖之类的东西。如果他们本来就没想着更进一步，那干嘛要费事去考认证呢？换句话说，没有经过认证也不一定会拖累你，有实际经验也是不错的。但对那些没有必备经验的人来说，他们最好还是去考考认证吧。其实想想，在用人企业选择雇谁的时候，同等经验下，认证就可能会成为你胜出的王牌。　　我的建议就是，先积累一些经验，然后去考认证。反其道而行是不可取的。你应该不太想在一些只有当你找到工作后才能体现价值的东西上投入太多时间和金钱吧，更何况你又是指望着这东西来帮你找工作，岂不是让自己心里更没底。你最好还是先把时间花在积累实际经验上面。1.3.4　现在去碰碰运气吧　　你已经准备好了，积累了一些经验，参加过一些培训，甚至可能已经通过某种认证了。现在该是时候去找份DBA的工作了，是吧？　　其实不尽然，你开始找一份DBA工作的时机不是你什么都有了的时候，而是应该在你认为万事俱备之前。不要等到你觉得你获得了所有技能后才着手。你可能永远都对自己技能水平不满意，认为这不足以让别人聘用你来当DBA。别这样，马上开始找工作吧。　　很多工作都是通过亲戚朋友那儿的人脉关系找到的。当你开始想成为一个DBA时，你就应该让别人知道，你希望找一份DBA的工作。为什么要这样？其实认真找份工作花的时间可不短。从开始求职到最终得到工作的这段时间，足够给你积累经验并参加一些必要的培训了。　　请马上和身边的人谈起这事吧。告诉他们你在追求什么，告诉他们你想要做什么。你可能发现其实机会就在你身边。当然，如果事情没这么凑巧，那么给他们点印象也是很有用的。因为他们可能遇到你可能会感兴趣的机会，而你一定会希望当机会出现时他们能第一时间想到你。那只有你亲口告诉他们，他们才知道你对这事感兴趣啊。　　积极主动些，要自己主导自己的职业生涯，掌握自己的未来。做好准备，那么当机会为你敞开大门时，你可能就会听到别人说：“嘿，那小子怎么就那么走运当上DBA了呢？”1.4　保持专注　　说是机遇，可得到成为DBA的机会可能要花上不少时间。就拿我来说吧，从我告诉我当时的经理想当DBA，到我最终在另一个公司得到成为DBA的机会，差不多花了5年的时间。在这期间其实我遇到了很多足以让我放弃的事情，不过我知道我就想成为DBA，所以我一直坚守阵地，并最终取得了胜利。　　对我而言，关键在于我会不时地去设想我所想要的工作。我对这份想要的工作考虑得越多，自己每天所完成的与之相关的任务就越多。即便是现在，我也总是会去设想自己梦寐以求的工作该是怎样的。我会不时地反思一下，看看自己都做了些什么，然后就发现自己已经做了很多能让自己充满活力的事情。　　我经常会想起文斯?隆巴迪 说过的一句话：“一旦你学会放弃，你就会习惯放弃。”如果你想换个工作并转换成一个全新角色，不管是在原来的公司还是去了新公司，你都不能够轻易泄气。让所有事情走上正轨是需要时间的。你必须得相信你自己才行。不管怎样，如果连你自己都不相信自己了，那还能指望谁去相信你呢？　　不断学习，不断记些东西，不断说些什么，不断接触不同的人，还得不断看看你的收获。要孜孜不倦地为可能出现的机会做准备，这样以后别人问你：“嘿，你怎么这么走运当上DBA了呢？”你就可以对他们的提问笑而不语。第2章　　我要做点什么　　现在你已梦想成真，正式成为数据库管理员了，那么首先要做点什么呢？如同其他工作那样，你需要知道怎么上手，对吧？你应该在哪方面多多努力，从而向公司展示你的价值呢？了解如何上手是成功的关键，而本章就是要帮你做出最好的决策，来快速走上正轨，在这里我会给出工作之初的“百日计划”，甚至还会说说你应该经常和谁一起共进午餐。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　从这时起别人会经常根据你的实际成果来对你作出评判。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　在本章中，我们要讨论以下内容：　　(1) 整理一份初始清单；　　(2) 你该如何处理收集的信息；　　(3) 应对不熟悉的警告；　　(4) 如何破冰；　　(5) Mr. Right。2.1　你和总统的共同之处　　你真和总统有相同之处吗？当然有啊，而且你肯定很难想到。首先，你身边肯定有不少人质疑你的工作能力，会怀疑你是否够格拥有这份工作。其次就是，每当你做出什么决定，或是计划做点什么的时候，总是难逃被立马批评的厄运，而且这个批判家很可能还是你的支持者。再有就是别人会根据你入职之初的表现来对你做出评判，是好是坏可不由你说了算。　　每隔四年都会选举新总统，而想要坐上位子，就离不开支持率这东西。好吧，其实我们普通人的生活中也有着类似的东西，不过我们这个叫“年度绩效考核”。在考核到来之时，你应该在默默祈祷自己的支持率越高越好吧。　　听起来挺可怕的？其实只要你在开始工作时多多注意，情况应该也没这么糟糕。对你而言，在刚开始工作时，制订个行动计划是最重要的。如果你觉得可以和大家打个照面，然后端杯咖啡轻松入职，那么你不就给自己导演了一场悲剧吗？咖啡可以以后再喝，我们还是先收集一些能让自己高效工作的必要信息吧。　　那到底要什么信息呢？先来点基本信息，比如你负责的是哪些服务器？你需要为哪些应用提供支持？这些应用每天什么时候用？你的客户都有谁？现在有没有正确地备份数据库？你怎样才能知道这些备份是不是不起作用了？要了解的事情其实挺多，你可能很快就会受不了。因此你需要把这些最基本的信息都记在一份清单上，然后再开始着手工作。等到你基本能在新环境中应付自如的时候，就可以制定一些短期计划来完善它。其实这开头一百天不知不觉就过去了，你就能回头看看自己在这么短的一段时间里到底做得怎样。　　相信我吧，其实做起来真不难，你只需要让自己变得有条理。2.2　你的初始清单　　到这儿，你应该已经坐在办公桌旁，开始第一天的工作了。你和HR见过面，也对工作环境有所了解了，确定你有一些开始工作所必需的东西，比如电子邮件之类的。当然，你还得确定你能访问那些需要你来管理的数据库服务器。　　这是你所需要的第一手信息，对吗？我负责哪些服务器和系统？如果没有了解这些信息，那么很不幸，在这种逆流而上的漫漫征途中,你是很难有所进展的。　　你的初始清单应该分成几个部分。为什么呢？因为我习惯把事情都列成清单，可能的话还会给这些清单分门别类。这有利于我记住整体概况，也不用担心漏掉任何细节。我强烈建议你也这样试试，看看这对你是不是有帮助，不过每个人都有不同的组织方式，所以如果你不习惯按我说的做，按自己的习惯来也是没问题的。　　清单有三个主要的部分，一部分是和你有关的信息，一部分是和客户有关的信息，再有一部分就是你的行动计划。理清这三点就是你第一天工作的重点了，搞清楚和自己有关的事情，弄清楚和客户有关的事，再开始制订个行动计划。这样一来，就能制订一个如下所示的清单了。　　(1) 拟一份服务器清单。　　(2) 检查正在运行的数据库备份。　　(3) 抽查并验证，你能从这些备份中还原数据。　　(4) 拟一份客户名单。　　(5) 列出“最重要的”那些数据库。　　(6) 列出即将开始的项目和将要交付的内容。　　(7) 构建环境基准。　　　 a. 服务器配置检查。　　　 b. 数据库配置检查。　　(8) 制定恢复计划（看清楚了，不是备份计划，而是恢复计划）。　　请注意，我的清单里少了几件人们常说的DBA日常必备事项。这里面没有包括例程索引维护、性能调整、事件日志审查等工作。当然这些事项其实是很有必要的，不过我们现在讨论的是工作第一天的事项清单，我这里列出的这些信息就够你花几天去收集了。如果你在第一天就想着去排除某个存储过程的故障，那么你算是给自己挖了个大坑往里跳，而你还来不及去记录你的恢复计划。　　告诉开发人员你来接手写程序，还是告诉客户你能在半小时内搞定数据库的备份和运行工作，你想当哪种英雄呢？入职后我很快就知道自己该如何做出选择了。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　完成这些任务可不是一天的事，不过对清单事项的启动不容耽搁。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　最好是一开始就告诉你的经理你先要收集这些数据并列成一个清单。你一上来就主动地对这些信息表现出了应有的关注，这会使你的上司们觉得你会很认真地维护好这些数据，让大家没有因为事故而丢掉工作的风险。他们可能不会帮你列出这份清单，说不定比你还需要这份清单。之后你还会有不少时间来做点别的，这自然就成了你的环境基准和后续行动计划，因为你的做法很可能成了所在企业的标准。Ozar评注：榜样效应　　在一家公司，当我把前两周的工作计划给老板看时，他惊叫道：“天哪，我们公司的其余服务器居然没有这些信息。”然后他找来了所有系统管理员，让他们马上放下手里的活也来做我在做的事，不过是去处理文件服务器和Exchange邮件服务器等。　　让我们逐个看看为什么清单上的事项都这么重要，而且从第一天起就很重要。如果今天就是你工作的第一天，那么你应该马上开始执行这些任务。2.2.1　拟一份服务器清单　　我不太确定是不是真有必要解释这一条，不过你最好还是能清楚地了解你到底被安排去管理什么。你的初始清单可能并不完备，不过它还是能马上给你提供参考基准。相信我吧，说不定什么时候就会有人过来找你，然后和你谈起一台你根本就不知道的服务器。他们会很不理解为什么你从没听说过那服务器，因为他们一直就在和那服务器打交道，服务器上放着一个数据库，而你是DBA呢。　　尽你所能去收集尽可能多的信息吧。这样你才能对你所要面对的东西有更多了解，也会对你制定行动计划时有所帮助，要知道，处理5个实例和处理500个实例所要做的事情可是有着天壤之别的。　　我知道你心里在想什么，你会想，“哎呀，我该怎样弄清楚我负责干什么呢？”我建议你从顶头上司那儿开始，然后再找应用经理和服务器管理员。你的上司可能要求你负责管理薪金数据库。那“薪金数据库”是什么呢？你也许需要从这一点细微的线索开始，然后一步一步查出这具体指的是哪些数据库。这样一来，你就能对所要面对的复杂程度有个大致的了解。而且这些你不得不做的调查工作对你其实很有好处，它会加深你对所在企业的了解和认知。　　如果你想学点找寻数据库的技术手段，有不少办法为你准备着呢。最简单的一种办法就是使用SQLCMD实用程序的?L参数，以返回在网络中广播的那些数据库服务器的列表。因为使用这个工具有可能查不到一些服务器，所以你在整理清单时最好还是四处问问吧。　　那么你应该把这个清单记在哪里呢？就我来说，我比较喜欢把各种信息记在一个笔记本上。我这里的“笔记本”可不是指笔记本电脑。我说的是那种我可以在上面写写画画的纸质本子。其他人也许会把这些内容记录在一个Word文档中，然后把这个文档保存在自己的电脑里。不过我觉得还是纸质笔记本更适合我，因为我发现用手写比用键盘输入更利于我去记住一些东西。和我用键盘打出来的东西相比，用笔记下的东西能让我记得更牢一些。　　还有一点要说的是，为那些不由你负责的服务器拟一份清单也是很重要的。你的公司里很可能有那种必须由厂商负责维护的系统。要是这种服务器出问题了，你必须明确这事不归你管。而且如果有人要你不必去管某台服务器，那么我建议你最好是得到份书面的文件。相信我吧，只有这样，在出了问题时，你才有证据证明你到底是不是该对这台服务器负责。　　如果你将信息存入电子表格或者类似的文档中，那么你就可以更好地回溯过去发生的事，来看看你的环境是如何变化的。你所管理的服务器是变多了还是变少了？数据库呢？你的工作是不是都在进行？备份是不是起作用？这些信息可都是能为你的表现加分的呢。如果没发生什么意外，你记录下的细节可以向老板清晰地展现你的工作在不断进步，而且你的责任也越来越大。你将能更好地证明你对公司的价值。Gennick评注：如何体现自身价值　　你可能认为老板能认识到你的价值，能了解你每天都在忙些什么。不过就我的经验而言，事实截然相反。我在职业生涯的早期，曾有过被解雇的经历。现在再看那件事，我觉得那次被解雇的一部分原因是我没能以某种方式让老板认识到我对公司的价值。老板只用待在公司就行了。但我的内部客户遍布五湖四海，有些客户甚至身处欧洲。更多时候我会和这些客户走得比较近，并为他们解决问题。不过我的老板却不在我这个关系圈子里，我们之间基本就没什么交流。我们本来也不怎么需要日常交流，所以就真没怎么交流。这下应该能猜到裁员时会先裁谁了吧？　　我从这次被解雇的经历中得到了不少惨痛的教训。其中有一点就是明白了老板们永远都是大忙人。他对你具体做什么可能只是略有所知。你一定要比我那时候做得好才行，要多和老板打交道，让他知道你干得不错。可能有天你的老板要和HR们商量裁员的事，当他考虑要裁谁时，你肯定会希望他能想起你的工作干得多么好，你对公司是多么有价值。2.2.2　检查数据库备份　　现在你已经知道自己该负责哪些数据库了，接下来你最好再看看备份是不是运转良好。千万别自以为一切都是妥妥帖帖的。亲自去查看那些细节，并验证每个实例都做好了备份。哦，那就得去检查系统数据库（master、model和msdb）和所有的用户数据库。检查备份文件是否存在，存储这些文件的目录是不是放在一个具有足够空间的磁盘上，并看看它们最近有没有出故障。　　你可能还想记下服务器和数据库的备份时间安排。之后你可以通过它来验证数据库是不是按照企业需要进行过备份了。你可不希望看到企业期望数据库有point-in-point恢复的能力，而你却对这个数据库每周只备份一次。　　我要说的这一点极其重要：对作为DBA的你而言，如果说有且只有一件你一定得关心的事情，那就是要确保万一出了什么状况，你得有办法恢复数据库。好的恢复计划都始于可靠的数据库备份策略。2.2.3　验证你能否还原数据　　我喜欢时不时地对备份进行抽查，方法就是抽取部分数据然后尝试着进行还原。对我而言，我喜欢尝试本机还原（same-server restore），以及向另一个不同实例的还原。要注意这可不是还原文件头以验证文件是否可读。绝不是那样的，我这里可是要还原整个数据库，这才是我要做的。我通常没时间来验证所有的备份文件，而且可能也不会尝试这么做。我只会抽查某些服务器的一些备份文件来确保没有问题。　　现在我来说说本机还原吧，这里我要明确一点：　　　　在生产服务器（production server）上执行本机还原时请务必小心。　　好了，现在我感觉好多了。只有先确定进行本机还原是安全的，然后，你才能这样做。那你怎么知道这样做到底安不安全呢？当然你总可以去问问别人的。要是你不想去问，那么你可以去看看是不是有人连接到这个实例。再者，要是你的数据库相当小并易于管理，而且还原过程最多只需要花上几分钟，那么做本机还原也应该是安全的。当然，如果这不是生产服务器的话，那你肯定能更放心些。　　你应该去验证哪些数据库可以被还原呢？你可以将注意力集中到任何一组数据库上。这么做的真正目标是为了让你能熟悉新公司的还原流程，还能让你检验这些备份是否有用。要记住，在你去碰那些重要的服务器之前，你一定得了解你所在公司数据恢复流程的各个方面。如果你能发出警告说一种备份无效，那么这会让你在以后的工作中少点麻烦，而且事实也会证明，你的理解和判断是准确的。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　练习还原的另一个好理由是这样做你可以在连续熬了三夜后，当凌晨3点来电话找你还原的时候，你能做好这项工作。你会很累，你也许不能仔细思考。而之前你所进行的练习都应该形成一种大脑“肌肉记忆”了。练习可以让你在重压或者疲惫的情况下也能更好地胜任工作。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－2.2.4　拟定客户名单　　如果你知道你该负责哪些服务器了，就得去弄清楚那些服务器的客户都是谁。要注意这样的调查工作会产生很臃肿的名单。对共享的系统而言，每个人都可能使用到所有的服务器。　　拥有一份客户名单是至关重要的。比如说，如果需要重启服务器，那么你最好是能知道需要联系谁，来告诉他们服务器在重启时可能会离线5分钟。在整理客户名单时，你也应该去了解一下哪些人是行政人员，并记住他们常用的是哪些服务器。　　你在列出客户名单时，应该也问问这些人使用的是什么应用程序和系统，这些应用程序和系统在一天的什么时候用得最多。你这么做了之后可能会发现一些让你感到不可思议的结果，比如说人们认为并不重要的系统可能整天都在用，但一些看起来很重要的系统可能一个月也就只是用上一次而已。　　拟这样一份名单还有另一个好处，那就是你可以借此机会和你的客户建立联系。如果你尽心尽力地找到他们，他们很可能会非常高兴。这样一来，你就很有理由去与这些客户接触了。你可以把这种做法看作一种人际关系破冰器，一个你约见客户的好理由。Simmons评注：不常用的数据库也可能很关键　　Tom在上文提到了“应用程序和系统在一天的什么时候用得最多”这个问题，也让我想起了以前管理数据仓库时的事情了。当时我们有个数据库每月可以离线三周都无人问津。但它是一个有着特殊作用的关键数据库。不过比较巧的就是尽管第一周时确实要用这个数据库，但剩下那三周就没人去用它了。这样一来，只要在第一周能保证它是每时每刻在线的状态就行了。剩下那几周？其实没什么大碍吧。我想告诉你的道理就是，别觉得某件物品的使用频度和它的重要性一定是成正比的。2.2.5　列出那些“最重要的”数据库　　你在收集重要客户的名单时，还得进一步了解对他们而言哪些数据库是最重要的。你要么问问他们，要么问问别人，然后再对比下那些名单。不过你肯定会发现这两种名单肯定是对不上的，而且你会惊讶于很多人可能遗漏了一些他们所使用的系统，因此需要善意地提醒他们这些遗漏的系统也很重要。作为DBA，我们会将所有数据库都视为同等重要，不过我们会在工作中发现其实有些数据库确实比其他数据库更重要，尤其是在一天、一周或一个月中的某段特定时间内。　　例如你可能打理着一个对项目至关重要的数据仓库。公司的每个人都告诉你这个系统非常关键。不过他们可能不会告诉你，其实这个系统一个月也就只用三天。所以这个数据库就算在另外21天里天天都离线，也没有人会多说你半句。　　还有一个例子是交易平台。这个系统可能在每个交易日中有9到10个小时会频繁使用。不过一天中的另外那些时间里却根本没人用它。难道这能说明这些系统在没人使用时就不重要？当然不能。这种情况表明的真正含义是，你要收集更多和这些系统有关的细节。如果有17个不同的小组都提到了某个小型数据库，而且都认为这数据库不太重要，那你就得认为它非常重要，因为这个数据库关系到如此之多的人。　　另一个因素是可恢复性。如果企业要求你能将某个数据库恢复到过去任意一个时间点，那么你也应该想到这个数据库是很重要的，即便客户告诉你“这个数据库不是很重要”。我都记不清多少次客户不假思索地如此对我说：“这个系统确实不算什么，虽然我们需要恢复的时间点不超过5分钟，而且我们整天都在使用这个系统，但你真没什么可担心的。”嗯，好吧。没出问题当然好，可一旦真是出了问题，那么你会发现自己可算是中了着，你得恢复所有数据，还得快！2.2.6　列出即将开始的项目和可交付的内容　　如果你身边有人可以帮你了解到当前的和即将开始的项目，那么这能让你了解到将会有多少问题推到你身上。你应该希望等着自己的“惊喜”越少越好吧，了解现在正在计划的各个项目可以让你明白每个项目需要分配多少时间。而且请记住，除了项目支持外，你还可能要进行一定程度的产品支持，这是你将要编制的行动计划中还得添上的事情。　　你还要知道哪些服务器在最近不会有任务，这样你就不会浪费宝贵时间来给这些暂时根本没用的服务器作性能调整了。也关注下这个方面吧。2.2.7　构建环境基准　　基准化你的工作环境，这件事通常会被忽视。为工作设定一个起始点再重要不过了，如果没有这样一个起始点作为参考，久而久之你就会很难把你的进度用图表或报表表示出来。　　想要收集和你要管理的服务器有关的基准信息，其实就是看看服务器的实际状况和理想状态究竟有多大的差距。你已经搞定一个基准项了，还记得吧，你已经评估过数据库备份了。由于初始清单上的这一项会在很短时间内变得有些繁冗，因此请将精力集中在那些基本内容上。　　例如在一台有着直接附加存储的独立数据库服务器上，数据文件应该会和日志文件出现在不同的驱动器上。有多少服务器有着相同的配置呢？那些磁盘驱动器又如何？是否存在标准RAID配置？（你可能会惊讶于这些服务器的实际构建是不尽相同的。）这些实例的内存设置或处理器数量又是何种情况呢？数据文件和日志文件有多大，CPU的平均使用率是多少？　　在收集基准信息时最好将精力集中在少数很有价值的项目上，并且要保持信息不断更新。随着时间推移，你也可以按照自身需求添加一些额外的项目。　　我还建议你尽量简化自己收集信息的方式，例如，如果你有一百台服务器要处理，你当然不希望远程控制所有服务器并一一检验它们的内存设置。这样你就需要学习如何高效收集信息了，这些信息大多可用System Center Configuration Manager（SCCM）和Operations Manager之类的工具来收集。如果你的工作环境中没有这些工具，那么你可能需要用PowerShell、T-SQL或其他工具来自己编写基准查询。　　除此之外，你可以使用SQL 2008中定义的中心管理服务器同时对多个实例执行查询。或者你可以试着使用政策性管理来报告和强制执行配置选项。不过不管你选择何种方式，目标都别无二致：随时间跟踪记录变化。一旦了解了整个工作环境的现状，你就可以着手记下服务器出问题时将其恢复至原始状态的方法。2.2.8　制定恢复计划　　千万注意我这里说的是“恢复计划”而不是“备份计划”。到目前为止，你验证过数据库备份是否正常运转，也已开始抽查你可否从备份还原数据，并对重要的数据库有所认识了。现在是时侯把这些东西整合在一起，做成一份灾难恢复（DR）计划了。对每一个列在重要数据库清单上的数据库而言，你都应该记下数据库出问题时需要采取的具体恢复步骤。　　你一定得弄清楚：万一灾难出现了，你的工作饭碗就危险了。如果你因为准备不足而没法恢复数据，那么你很可能还要去做重新分派的“特别项目”，并一直忙到下周末。避免这种状况发生的最好方法就是演练，演练，再演练。正所谓有备无患嘛。你所在公司应该会有定期的DR测试，可能是一年一次吧，但是这并不影响你自己以更密集的频度做一些更小规模的DR测试。　　记下每个系统，以及执行恢复需要的所有步骤。数据库是否处于完全恢复模式？你多久进行一次事务日志备份？最好是写下备份时间安排，这样就能明确还原点都在哪里。如果客户希望恢复能精确到分钟，而你却很不凑巧地使用了简单模式，那么你真是倒大霉了。　　而且别忘了该怎样恢复数天或数周前的数据。如果有客户需要两个月以来的数据库备份，请确定你知道完成这一工作所需的所有步骤。如果你的公司使用了异地磁带存储服务，而且从外地取回磁带需要花上两天，那么你就需要把提前告知用户这一情况列入你的DR计划。.3　信息都收集到了，现在该做什么　　上面讨论的内容至少能让你在入职第一天忙到吃午饭了。好吧，也许你要花上几天才能收集到你清单上列出的所有信息。你可能有很多现成的信息，当然也可能没多少现成信息，所以收集所有信息所需的时间取决于你所在部门的现有结构。（顺便友情提示一下，要习惯“这取决于”的说法，后面会经常遇到的。）别担心，当你还在继续收集数据时，就可以过渡到下一阶段了。2.3.1　约见经理　　在收集数据时，你还应该去见见经理，与他讨论一下你的初步结果，并和他一起安排这些工作的优先级。如果你发现有一台服务器没有进行任何备份，或者是备份不起作用，那么这台服务器应该最先得到处理。我不管到底是哪些“最重要的”客户在你入职第一天便嚷着叫你去修复他们写的、塞满了70GB容量的日志驱动器的那条查询，你必须确保自己能完成灾难恢复的工作。　　继续和经理谈谈你的清单，看看清单上哪些项目需要完成，哪些项目需要最多的资源和人力，以及哪些项目现在并不着急做。有一点很重要，就是在你开始工作之前，你要和经理就这些任务的内容和优先级达成一致意见。这样对你和经理都有好处，同时也给了你一个从此开始接受考验的机会。　　但假如你和经理意见相左，那么最好把你心目中的优先级记录成文档。这样如果有人来问你为什么没完成某项指定的任务，这个文档就派上用场了，你能礼貌地向对方解释为什么你去干别的事情了。如果还有其他不能达成共识的地方，你、客户和你的经理可以重新评估你提出的优先级。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　让你记下不同意见并不代表让你和上司对着干。不要顶撞上司，不要拿他之前发给你的电子邮件来说事。把这些邮件当做是对他的一种善意提醒吧，用它们来表明你是按照上司安排的优先级来完成工作的。如果你这样做的话，那么至少你上司会认同你的努力。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　在和经理见过面之后，你就得经常去接受考验了。每个人都希望或需要你做这做那的。你和每个人的交流都可以算是某种形式的考验，可由你所做的实事来验证。如果你拟出了清单，你的经理也注意到了这个清单，那么你从第一天起就算是做了点实事。　　考虑下这对你而言有多重要吧。你上了三四周的班之后，可能有人会问经理你这个新来的DBA活干得怎样。你的经理可以迅速肯定你所取得的成绩（当然这里我假设你是有所作为，而不是在公司混世度日）。你可以轻松记录自己的进展，最终就能用简报或演示文稿把你在开头数月所取得的成绩详尽地展示出来。2.3.2　约见开发人员　　如果你的公司有内部开发团队，那么最好还是花点时间和他们交流一下吧。他们是决定你在接下来的数月中能否取得成功的关键之所在。了解一下他们正在进行的项目以及当前所面临的障碍，看看你有没有机会能帮得上忙。　　毫无疑问，开发人员会让你非常忙碌。他们总喜欢天马行空地将技术应用到极限。最终结果就是有很多让你得到锻炼的机会。填写事务日志？让我再看看你想要干嘛。装满整个日志驱动器？你的远程查询性能低下？那个有着27个嵌套光标的存储过程慢如蜗牛？让我来告诉你该怎么办吧，也许我们能找到一种更好的方法来把这些事都搞定了。　　所有开发人员都想和你成为朋友？做你的春秋大梦去吧，很少有地方的人能自始自终友好相处。如果你在公司里遇到一些不可一世的开发人员，那么你还是躲一旁偷笑吧，因为你明白DBA才是最聪明的，不然那帮开发人员怎么会整天留下无法应付的残局而找你去解决呢？2.3.3　约见服务器管理员　　很多DBA只需要专门管理服务器实例即可，而不需要插手操作系统管理的事，当然，需不需要管理操作系统完全取决于公司的安排。如果你正好就属于这种情况，你就需要努力了解服务器管理团队，这些服务器管理员了解整个公司的最新动向。他们知道哪些系统是最重要的，而且当你处于紧要关头时，他们知道可以在哪儿找到一些额外的硬件。Gennick评注：系统管理员是你的朋友　　如果你和管理服务器的系统管理员关系很好，那真是件好事。如果DBA能和系统管理员默契配合，一起来解决问题，那么我觉得这真是件再好不过的事情了。　　系统管理员还是为你构建基础设施的人。知道自己正在使用什么硬件以及将要使用什么硬件是很重要的。如果你的公司想实现存储区域网（Storage Area Network，SAN），上司和同事们可不会问你如何配置该网络，他们会问服务器团队的成员。由于SAN对数据库服务器有着重大影响，所以你也有必要参加相关的讨论。最理想的情况是一开始就有人邀请你一起讨论，你和服务器团队交流得越频繁，就越有可能了解到自己将要应对的变化。　　你还可能经常需要充当开发人员和服务器管理员的沟通桥梁。为什么是这样呢？你就把自己当作一个无所不知的翻译员吧。开发人员通晓代码，而且对公司业务的很多方面都有所了解，因为他们每天都把注意力集中在这些事情上，所以不会花时间去做架设服务器、安装路由器、换硬盘、在SAN上分配空间之类的工作。而这类工作正是服务器管理员的职责所在，但他们没办法像开发人员那样迅速编写或构建能推动公司业务向前发展的应用程序。　　不巧的是这两群人很少有机会互相交流，除非出了什么问题（或是双方要互相指责）。这就是你的用武之处了。出了问题，开发人员就能先找到你，告诉你现在他们遇到了什么障碍，而你就可以用一种服务器管理员能理解的语言来向他们转述这些情况。如果没有你，大家就无法坐下来促膝而谈，麻烦会越来越大，然后你的公司可能要在硬件上花很多钱来解决一些问题，而这些问题本来只需修改几行代码就能解决。　　通过和这两群人会面，你可以不断提高自己的语言水平，并能帮他们维持和谐的关系，而且最终还能帮公司节省开支。2.3.4　约见客户　　到现在为止你几乎已经和除了实际客户之外的所有人见过面了。事实上当你身处DBA之位时，每个人都算得上是你的客户，不过这里我们还是将注意力放在那些应用程序和服务器的最终用户身上吧。因为与之前说到的那些人相比，他们给你的印象截然不同。　　为什么和他们会面如此重要呢？我们先来看看下面这个故事吧。　　一天，John按着广告租了Steven家车库上方的一间卧室。John外表整洁而且有一份工作（但没人知道他究竟是做什么的），但他基本成天都在家里。不过他性格很好而且从来不拖欠房租，所以Steven这家人也很乐意他租住在这里。不过这家人从来没注意到John总是喜欢搭他们的顺风车，而且他从来不考虑目的地是哪儿，他只会问这家人“能让我搭个便车吗”，而他们通常都不会拒绝John。　　每次他坐车时都会问几个和车子有关的问题，但又不至于多到让这家人发现什么异样。他只是将这些问题融入平常的对话中。问句“汽车里有足够的茶杯托架吗”就足以引出各种与汽车设计和汽车功能有关的话题。　　最后John告诉Steven一家他找了个新公寓，所以得搬走了。在他离开之前，他终于告诉这家人他是靠什么谋生的，其实他是为那家汽车公司工作的。之所以他会问那些问题，就是为了获得客户对轿车设计的最真实反馈。Steven一家所提供的反馈信息要比通过其他任何调查所得到的信息更加可靠和真实，John的职责其实就是观察实际使用他们公司产品的家庭。　　听完这个故事，你应该能明白和最终用户多接触有多重要了吧，其实你也可以像John这样做。多多了解他们是怎么使用工具的、他们会遇到哪些困难，以及有哪些小细节能让他们（当然也会让你的公司）提高效率、增加收益。你也可以去问问你的客户你能否搭搭他们的便车，你会对你所能了解到的事情感到惊讶的。2.4　那条警告严重吗　　现在你已经收集好所需信息，也和各种人打过了照面。你回到自己的办公桌前，发现有大概1500封电子邮件来等着处理。你该做什么呢？这些邮件中可能有一部分是数据库警告。最好是看看这些数据库警告吧。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　最好是为电子邮件设置规则来自动归档这些警告，但千万要小心谨慎，确保所有设置都是正确的。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　某个特定的警告是否很严重？这个我可真不好说，只能说它可能很严重。当然也可能很安全，可以直接忽略。如果这个警告真的很严重，那么很快就会有人指着你大喊了，对吧？严格说来会是这么个状况，但我觉得你可能不希望事情会变成这样子吧。下面是当你遇到这些警告时所要遵守的基本规则：　　　　如果你不知道这些警告到底是说什么，那么你需要弄清楚为什么你会得到这些警告。　　很好记吧。不过遵守这条规则也可以是很不同的，关键在于你是积极地看待它还是消极地看待它。考虑下面这个场景吧，那是一个星期天下午，你正慵懒地在家休息，你的黑莓手机收到了一条你没法理解的晦涩消息，你认为别人肯定也收到了相同的消息并知道该怎么处理，你觉得明天就能弄清楚这消息到底说了些什么。不过当你第二天早上来到公司开始时，就会发现有用户抱怨某个重要的数据库出了问题。报表和批量装载应该在几小时之前就完成了，但到现在都还没有要停下来的意思。用户想知道到底出了什么问题，还问你需要花多久才能修复这些问题。你都不知道到底出了什么问题，但你想起昨天收到的那条晦涩消息了。你稍微研究了一下，找出警告从何而来，找到这条消息，逐渐明白了这条消息究竟在说什么，最终找到了问题。不过等你差不多弄明白并着手修复时基本上一天也就过去了。要知道除你之外根本没人收到这条警告消息，因此你得承担所有责任，而且是独自承担。　　听起来很好？才不是呢，这就是我刚开始工作那几周所遇到的事情。从那之后，我就把确定警告系统提供的消息是否有价值当成自己的任务了。我不止一次听到别人被海量电子邮件困扰的事情。有些是警告，而有些则是普通信息。而我总是寻求办事高效，因此就只想要那些确实有必要处理的警告。　　那么我们假设你遇到的每个警告都需要你来亲自处理。请注意我并没有将这个记在初始清单里，不过这只是因为和前面所提到的任务相比，处理警告是相对次要的。花上不少时间去处理那些非关键系统的警告，却让那些最关键的系统少了一天的数据库备份，你说这有意义么？　　但现在是时侯去问问别人：“嘿，我们的警告系统是怎样的？”如果可能的话你应该熟悉下各种类型的警告，以了解它们到底是重要问题的反映还是一般的警示消息。　　你怎样才能判断警告的严重程度呢？你怎么才知道它是不是真的很严重呢？其实很简单，要是遇到的警告和某个你所负责的数据库或用户有关，那么毫无疑问，你需要认真地检查一下这条警告消息。如果警告不符合之前所记下的情况，那么你也应该毫不犹豫地去看看。换句话说，如果你拿不定主意的话，那么就一定得看看。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　记住，如果你不知道某条警告是否严重，那就把它当成是很严重的警告。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－2.5　我该不该检查一下那条警告　　既然你已经知道，所有来源不明的警告都应该被当作严重警告来对待，除非能证实该警告并不严重，那么真正的问题就变成了接下来该怎么办呢？如果你组里还有其他人，那么你最好先问问他们。不过如果没有团队支持的话，那么你可以问问你的经理。要是这两条路都走不通，那么你还有一些其他的处理方法可供选择。2.5.1　检查警告系统　　深入探究一下警告系统，看看你能不能找出产生警告的原因。在这样做的过程中，你可以对警告系统有更多的了解，让你在以后遇到警告时更容易理解它们。如果你所想了解的警告是类似Database Mail那样直接给你发送基于SQL Server Agent故障的电子邮件，那么你要做的研究工作会很简单。而如果你所要了解的警告系统是类似Operations Manager那样更复杂的系统，那么你可能要多花一些时间来确认细节，不过你多付出的努力还是会在以后的工作中为你带来很多好处的。　　除了研究警告系统，还得保证你不是只把警告邮件发到你的邮箱，而是要使用通讯组列表。除非你想时时刻刻都为这些事情操心，不然最好是一直使用通讯组列表来发送警告通知。不过如果你不知道这些邮件是怎么发送的，那该怎么办？2.5.2　问问开发人员　　如果你已经收集到警告中所提及服务器或数据库的细节信息，那么去问问开发人员是不是对警告的性质有更多了解。他们也许能看出点端倪，或许是批量载入失败，或者是他们在进行某些测试。最坏的情况是，如果这个警告预示着某个重大情况，那么开发人员会很高兴你能在通知别人之前先通知他们。　　不过如果开发人员没法提供更多细节，那该怎么办？2.5.3　问问服务器管理员　　按自然逻辑，接下来就该去问问服务器管理员了。他们中应该有人对警告系统或是警告的性质比较熟悉。也许他们还配置过一些可能对你有利的邮件规则。　　问了所有服务器管理员之后，你照样有可能发现更重要的信息，而且服务器团队会很高兴你先找了他们，而没有先去联系客户。2.5.4　问问客户　　如果其他所有努力都不奏效的话，那么就去问问客户吧，看看他们此刻有没有注意到系统有什么异常。你可能会发现他们已经遇到一些麻烦了，而且他们很高兴你来帮忙了。通过帮助他们解决问题，你可以了解到警告的性质。而且即使他们此时没遇到什么问题，你也可以事先提醒他们如果之后出了问题可以随时联系你，这样也还是有好处的。　　每当警告出现时，你其实也算是得到了学习新知识的机会。要学会适应这种情况，并试着逐渐对它产生好感，因为如果你不这样的话，那么这些警告就会成为你的祸根，会让你有想把手机往墙上砸的冲动。　　当出现那种情况时，你还需要与一些人进一步沟通来分担不幸，一起进餐就是种不错的手段。2.6　一起吃个午饭怎样　　说到这里，你已经对系统进行了基本的运行状况检查，你对你的客户有所了解，而且知道哪些系统是最重要的，现在是时侯开始去更深入地了解那些在接下来的日子里要与你朝夕相处的同事了。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　对你而言，在刚开始工作时，每个人都是陌生的。你需要知道如何和其他人打交道，以建立一种互惠互利的关系。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　其实直到现在，我骨子里都是个比较腼腆的人。虽然很多人不相信这种说法，但这确实是真的。正因为这样，我曾经很难与生人打交道，即便是和同事。这让别人很难了解我，也让我很难了解别人。这样一来，想要拥有很稳定、很成功的工作关系也是很难的。如果说在这段艰难时期内我学到了什么，那就是与自己的上司和下属搞好关系是非常重要的。2.6.1　“饭桌外交”　　那些比较腼腆或是内向的人该怎样和他人建立关系呢？这并不是件容易的事。事实上，有时这看起来就是让人无法应付。不过我发现了每个人都有个共同特征：每个人都是要吃东西的。　　这是真的，从某种意义上讲，每个人都是要吃东西的。你可能看到他们坐在一起吃午饭。你可能发现他们会在早上去买杯咖啡。不管什么时间，你都可能看到你的同事在吃东西。你也是要不断吃东西的，这不就是很好的机会吗？是什么让你一再错过和别人共同进餐的机会呢？要破开这层冰，还得靠你亲自出马才行，快到午饭时间时，去新同事的办公室或工作间，先自我介绍一下，然后问问他们知不知道公司附近有什么好吃的。　　每天早上我都会加入出去买咖啡的队伍。不过我偶尔只是去走走而不买咖啡，不过这群人中总有人会买咖啡的。那为什么我总去呢？正是因为我和他们一起去买咖啡，让我有机会和他们多一些工作之外的交流，要是我稳坐工作间，就不会有这些机会了。　　很多时候，我不在和别人吃午饭，就在和别人去吃午饭的路上。直到觉得自己和同事吃饭次数够多了，我会和另外一些同事一起去健健身。换句话说，我总能换着法子和不同的同事交流，以逐渐增进我们彼此之间的了解。这意味着我们总是很合得来？当然不了。不过这说明我们在努力去和睦共处。2.6.2　不要拉帮结派　　我必须要警告你，千万别深陷“办公室政治”中。不然会造成“数败俱伤”的局面。还是和同事们建立起和谐健康的关系吧。健康的关系不是让你去和一帮人结伙打败另一帮人，而是要相互协作共同提高。－－－－－－－－－－－－－－－－－－－－－－－　　不要和流言蜚语或是办公室政治扯上关系。－－－－－－－－－－－－－－－－－－－－－－－　　不要无端猜忌他人，不要说人闲话，也别散播谣言。只相信自己亲见的事实，而不要相信那些道听途说的东西，而且一定不要故意传播虚假信息。办公室政治很容易打击士气、造成隔阂，并让生活变得痛苦不堪。2.6.3　外向一些　　并非所有技术人员都是内向的人，不过很多技术人员都比较内向。技术工作的性质决定了，这些工作需要注重细节的人单独工作很长时间而又能做到悠然自得。而这和那些外向的销售人员是截然不同的，给上他们10分钟，他们能和15个陌生人搭上话，并能和他们成为无话不说的朋友。而我们这些技术人员呢，就算和100个不认识的人一起参加大会，在会议结束时也没能和其中的任何一个人认识一下。　　要想在职场取得成功，就不能让自己成为“透明人”。有时我们需要站出来带头组织点什么活动，或是展示下自己了解的知识。当然，我们需要在不违心的状态下来做这些事情。2.6.4　尊重个性　　如果你真的只想自己一个人吃午饭，那么也不要绝望。你首先要认识到的是：　　　　每种个性的存在都是有其道理的。　　是的，就是这样的。如果全社会的人都变成了空心萝卜，东奔西走、醉心应酬，那我们也会痛苦不堪的。我们需要那些性格外向的人，例如你的公司就需要一群外向的销售力量。但我们也需要具有其他个性的人。想想看，销售人员也得有产品和服务销售才行啊。　　关键是要做到了解自己，了解自己的舒适空间，发挥自己的长处，提升自己不足的技能。你其实可以把“变得外向”当作自己需要掌握的另一项技能。这样做可以让你的生活和工作都更加舒心。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　推荐一本介绍个性特征的好书，Please Understand Me，作者是David Keirsey和Marilyn Bates（Prometheus Nemesis于1984年出版）。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－2.6.5　照顾好自己　　内向的人的特征有时可以概括为：　　　　内向的人在独处的过程中获得能量，在交际的过程中耗尽能量。　　这好像就是在说你？如果是的，那么不要担心自己偶尔也会画地为牢，不愿与人交流。例如每次我们出差去开会时，我的编辑都会独自一人去吃早餐。这是他的“独享时间”，可以让他积蓄这一天所需要的能量。而他在午饭时间又会进入这种状态。如果你从Apress出版社存书的展台经过，那么他肯定会主动去和你聊上一会儿，不过到了午饭时间他就会关闭“销售模式”，然后一个人独自享用美餐。　　当你和同事一起出差时，不要觉得自己有义务每时每刻都和他在一起。告诉他你需要点独处时间，告诉他你不会和他连续一个一个酒吧地喝酒到凌晨2点的，这些都无可非议。请坦诚说出你这样做的原因。我相信你的同事是能理解你的。有时候你的同事说不定也和你一样呢。　　我前面是不是说过要和同事一起吃午饭的？当然说过，不过现在我又告诉你如果需要点私人空间就一个人吃饭，是不是有点自相矛盾呢？其实不然，没错，和同事一起吃饭是与他们沟通、深入了解他们的一种好方式，但你也用不着每顿饭都和同事一起吃啊。还是先照顾好自己吧。如果你需要独自吃午饭从而给自己充充电，那么就一个人去吃吧。2.6.6　为人坦诚　　不要尝试伪装自己。不要介意让人知道你并不是个很外向的人。当我想去和别人谈谈时，我就直接走过去告诉他们我想和他们谈谈。这种是一种非常直白的方式，为什么不行呢？如果你真的对那些人比较有好感，还想和他们交朋友，那么其实很多人都会给你积极的回应，而不太在意你究竟是用什么方式来表达这种情感。2.6.7　加入某些组织　　组织提供了结构性，这种结构性可以让你很容易跳出自己的舒适空间。正因如此，SQL Server专业协会这样的组织才如此有价值。他们为这些技术人员提供了一个安全的社交场合，让他们有机会进行专业上的交流。而其他的会员也应该是怀揣相同目的才加入这个组织的。　　组织能为你提供带领他人的机会，还能给你带来提高演讲和演示技巧的机会。你一开始不需要在一个能容纳千人的大厅里做演讲。在本地用户组里面开始吧，随着讲话次数的增多，你会发现你会越来越得心应“口”了。　　当然也别光想着和工作有关的组织。从社区或教会组织的活动中积累的技能和信心也能转移到你的专业领域。如果你能通过与他人一起工作而在社区中获得信心，那么你也肯定能在职场中做到这一点。2.6.8　尊重个性　　我们不是讲过具有同样标题的一节了吗？没错，不过这一点确实很重要，所以我想在最后再重复强调一下。有个不争的事实，那就是人们更喜欢那些开朗外向的人，而对那些比较安静内向的人不怎么上心。很可惜，这种做法是错误的，千万别这样！　　之前所说的那些和提升人际交往能力有关的那些事，都只有一个目的：那就是提升你的人际交往能力。不要试着伪装或彻底改变自己。你的个性对你在工作中取得成功是很重要的。不要丢弃这些好的个性，要懂得发挥自己的长处。同时要努力去提升其他领域的能力。这两方面是不矛盾的，所以你都可能试着去做到。Gennick评注：搭话和闲聊　　对我而言，在社交场合和他人闲谈这种能力并不是与生俱来的，也不是很容易就可以具备的。即便在上小学时，我就注意到有的人坐在午餐桌旁，然后几乎马上就和他身旁的人聊了起来。而且他们谈论的话题变来变去的，我很少能跟得上他们的思路。偶尔他们谈到我感兴趣的话题了，我很想多说上几句，不过就在这时，他们又讨论到另一个话题了。我总是慢上半拍。　　在工作中，知道一些搭话的技巧是很有用的。我最喜欢的方法就是通过问问题来和别人搭上话。如果你在某个会议（比如PASS）上看到我在Apress出版社的展台，那么我很可能会问你“有没有我们出的书”。这样的问题通常会让我们反复谈到某些特定的书，谈谈它们好在哪里，差在哪里。　　我的问题是一种很好的搭话方式，而且它也带着我的诚意。我真的希望知道读者们到底喜不喜欢我们出的书。我想知道哪些主题最能引起读者的共鸣，哪些主题很难引起共鸣。我真的非常渴望得到读者的帮助，希望他们能让我把工作做得更好。　　我也可能会问其他的问题。有时也许某个公司的名称就会让我很感兴趣。而有时我可能看到我曾经旅游过或者居住过的城市的名字。有时提问是一种进行对话的好方法。不过一定要坦诚，不要只是让人觉得你感兴趣，而是要真的感兴趣。2.7　记录你的进展　　还记得那个清单吗？好，现在你需要用它来编制接下来数周的工作进度表了。作为DBA，你的大量工作都是在幕后完成的。实际上人们经常想知道你每天都在做什么，因为最终用户很难直接见到你所干的那些活。当你想把所取得的实际成果展示给别人看时，这个清单就能很好地派上用场了。　　不管你在接下来的几周里见过多少人、和多少人打过招呼，除非你能有证据向经理和其他人展示自己的实际成果，否则人们是不会知道你每天都做了些什么的。如果你的初始清单显示你掌管着25台服务器，其中有6台服务器的数据和日志是存放在C盘上的，另外还有两台服务器没有备份，而现在25台服务器都做了备份而且进行了恰当的驱动器配置，你之后不就很容易报告你的工作了吗？最后要说的是，人们不会记住你付出努力的过程，他们只会记住你所取得的结果。要确定你自己能很好地记录下工作取得的进展，因为你所记下的这些事实能够让人们了解到你究竟取得了哪些成果。2.8　主动一些　　现在你的很多调研工作已经做完了，你应该对接下来所要面对的工作有个清晰的印象了。随着时间的推移，你会在自己的新角色上构建属于自己的特性。多数DBA要么会成为Mr. Right，要么会成为Mr. Right Now。　　以下两种描述中，哪一种能最恰当地描绘出你处理工作任务的方式？或者说你希望别人把你归为哪一种呢？　　　　Mr. Right Now：他总等着给人解决各种问题，他的角色是非常显见的，人人都知道他的名字，人人都知道他做的是什么。他要完成各　　种修复工作。不管白天还是黑夜，他都在等着解决问题。不管出了什么问题，只要出了问题，你就可以给Mr. Right Now打电话，然后他就　　会帮你想出办法解决问题。他基本能解决所有问题，每个人都赞扬他所作的努力。但不管什么时候，他解决问题都只是治标不治本。　　　　Mr. Right：人们很少注意到他。当问题出现时，他只是在一旁默默关注，不过因为问题确实很少，所以人们也真的很难注意到他的存　　在。实际上人们经常会问他：“你都在那里做些什么呢？”不过Mr. Right解决问题是标本兼治，能确保服务器不会再出同样的问题。接着　　他会在遇到类似问题之前对他管理的所有服务器进行同样的修复工作，这样就做到了防患于未然。　　你想做哪种人呢？你想抛头露面，总能帮最终用户解决问题并因此而受到他们的喜爱呢；还是想很少露面，不让他们知道你在做什么呢？　　回答一下这个问题：你觉得Mr. Right和Mr. Right Now中，谁更像初级DBA，谁更像高级DBA？－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－做点亡羊补牢的活并不能让你成为高级DBA。想成为高级DBA，就必须要做到防患于未然。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　Mr. Right Now所付出的那一切会让最终用户很支持他，不过最后还是得问一句：他所修复的那些问题，是他上次修复的问题所引起的吗？　　有些人想成为Mr. Right Now无非是因为两点。第一点就是很多问题其实是积弊，他们得花上特别长的时间才能将“火势”控制住。第二个原因在于他们是初级管理员，只懂得解决眼前的问题。　　但Mr. Right不止是“救火”队员，他可以凭借他所拥有的知识和经验来控制局面，让发生问题的概率变得更小。所以他们不仅知道如何解决眼前的问题，而且知道如何根治问题。他们所提供的解决方案不会让事情变得更复杂，他们所做的有助于减轻工作负担。　　在你刚开始工作时，你可能在比较长的一段时间内都需要担任Mr. Right Now的角色，即便你达到了高级DBA的水平。因为可能有太多的工作，一个人根本处理不过来。当然，你列好清单，并把一切都打理得井井有条，所以你知道一开始应该把注意力放在哪里。不过随着时间的推移，你需要不断思考解决方案，而不是去找一种快速修复方法。　　久而久之，你真的应该成为Mr. Right，而且对系统进行配置，使其能够自我修复。即便你觉得你没太多机会向别人展示你对公司的价值，也千万不要绝望。事实上只要你继续做好本职工作，而且更积极主动地去防止那些潜在的麻烦出现，你就会发现别人会通过其他不同的途径了解到你的成果。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－工作上要多施巧劲，而不是多施蛮力。找出一些方法让自己在解决问题方面显得更主动。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　你到底是想整个周末都待在服务器机房里，还是希望帮助他人提高编写T-SQL代码的能力？你到底是想在工作日解决问题然后尽快重启系统，还是想帮助财务人员学会怎样使用SSRS配置和生成他们的报表？相信我，就算不当“救火”队员，你也有很多方式来展示自己的价值。　　回想大学时代，我们也经常接受“要巧学活用，不要死记硬背”之类的教诲。当然工作上我们也需要多施巧劲，而不要多施蛮力。