题起源于在写一份材料的时候，对于自己的反思。我把自己的观点发到了twitter和各大微博上，有不少朋友纷纷回复我。这这里，先感谢各位，因为有各种思想的交锋，观点的交流，让讨论变得很有意义。
我们究竟要成为一个怎么样的DBA，公司究竟需要一个怎么样的DBA？作为一个DBA应该须有怎么样的素质？
首先作为一个DBA，数据库的基本功很重要，了解数据库的内存结构，物理结构，了解数据库由物理文件到内存是怎么运作的，怎么联系的，靠什么进程来 进行管理，虽然说人人都知道oracle有SGA，里面有shared pool，db cache等等，但是并不是所有人都知道他们和操作系统是怎么发生联系的？从操作系统物理文件层面，到操作系统内存层面，到oracle的内存层面，到 latch，到cache，到lock，到transaction，到data block，之间是怎么发生联系的，了解了其中的关系，才能对oracle有个大致了解。
上面说的只是单实例的数据库，而现实中，单实例的数据库往往用的不多，生产环境往往需要高可用性，因此你必须了解各种高可用的架 构，RAC，dataguard，stream，cdc等等，了解这些架构中常见的等待事件是什么，是因为哪个主键引起了这些等待，了解HACMP，HP MC-SG，最好能了解一些他们的切换是如何进行的，依赖的组件（资源）是什么，是有哪个脚本来控制的，你是否可以修改脚本来控制切换的行为。在这一方 面，可能更多的不是了解oracle的知识，而是主机层面的知识了。
当你有了主机层面的知识，你是否还应该考虑一下架构方面的，数据库是生产系统的核心，上连应用下连物理设备，你所处的环境中，是一个怎么样的网络拓 扑图？应用服务器几台？哪些是在防火墙外哪些在防火墙内，应用服务器通过中间件连接数据库（这里你最好也懂中间件中关于数据库的配置），后面是否四层交换 机做负载均衡？连接了数据库之后，数据库主机上有几个网卡，哪个是做冗余，哪个是做备份，哪个是做inter-connect，数据库后面还有什么，连接 光纤交换机的存储是什么，什么型号的，读写速度如何？做raid几，有做存储的同步（BCV/CA）进行容灾吗?除了SAN，还可能接的是NAS，每个卷 分给了几个服务器？是否共享？数据库的备份是用哪家的备份工具，TSM？NBU？LEGATO？DP？是走网络还是lanfree？另外数据库肯定有监 控，监控用的什么工具，触发的条件如何，监控工具得到的数据是用什么命令获得的？如何设置不同应用系统的不同告警等级？如何设置不同故障的告警等级？如数 据库宕了和偶尔报一个ora-1555的错肯定不是一个等级。
另外，作为一个有经验的DBA，你是否心目中有一套常用的性能数据，如开异步IO之后，主机的wait IO多少是正常，不开异步IO的如何？数据文件的db file sequence read的average read time多少毫秒内是一个大致正常的值等等。这在调优的时候，会很有用。因为statspack谁都会做，但是不是人人都能看得懂的。
上述是维护DBA要知道的事情，开发DBA有另外的，这里不展开了。
上面说的可能都是干货，很多时候，DBA还需要一些其他的素质，从我个人角度讲，一个高质量的DBA需要具备以下意识。
能抗压，因为在故障处理的时候，你面临着大量的压力，领导盯着你，客户催着你，你在做故障诊断的时候，还有每隔一段时间汇报你的进度，告诉他们你的想法，如果你没有一定的抗压能力，在troubleshoot的时候，肯定会垮掉的。
反应迅速，在troubleshooting的时候同样也需要反映迅速，面对不断弹出来的对话框要能快速的回应，时间就是金钱，当你和你客户签订SLA的时候，你的数据库起不来，每一秒钟都是迈向SLA的脚步，反应慢，不行。
会猜，DBA不可能遇到过所有的问题和故障，在同等的知识水平下，DBA会猜的能力就能重要，他会中一些线索中找答案，从已知推断未知。打个比方， 在一个沙漠机房里面，没有互联网，你没法google，没法metalink，一个会“想办法”的DBA可能会耗费一定的时间，但是最终找到解决办法，但 是一个“不会想”、“不敢想”的DBA，就算给他再多的时间，最终浪费的还是一趟出差的机票钱。
团队协作的能力，很多情况，DBA面临的问题不仅仅是数据库的问题，刚刚说了数据库是业务核心，上连应用下连物理设备，DBA的知识结构往往是T 形，即深入于一方面的内容（T的那支脚），而对其他的知识只是了解，是广度，即T上面的那一横。对于不熟悉的内容，就要表达给别人，请别人帮忙一起看。注 意，这里是大家一起解决一个问题，而不是把问题推给别人。小公司的团队不太会出现这样的问题，他们往往人数少，流程少，配合紧密，效率极高；大公司里面， 分工很细。不是一个团队的可能老板也不是一个人，大家就会互相踢皮球。
强大的自信心和表达能力，在客户那边，如果你诊断出一个问题，但是没有把握，此时如果你表现的是自信满满，那么就比较容易说服客户去证实你的猜测，另外，也会比较容易去推行一些做法。相反，如果没有自信，客户怎么会相信一个连自己都说服不了自己的人？
关注行业行情，我觉得作为一个DBA，我们不能太“书呆子”，我们还是要了解一下行业八卦，这在和行业内的朋友交谈交流的时候，很有好处。说oracle有着非常强大法务部门（相信不少人看到过下面这幅漫画，《从组织结构图看Google、Facebook、微软等大公司的企业文化》）。一天，拉里开着他的跑车回公司，一路飚车，被路边的警察看到超速了，追了上去，拉里一路飙回自己的公司，把车钥匙往法务部门老大的桌子上一放：You deal with it！
organizational charts （漫画作者：Manu）
除了上述的素质，公司也会考察我们其他方面的东西。这些东西DBA可能觉得不重要，但是公司很看重，为什么？因为它关系到公司的存亡。流程观念，大公司为什么能生存的久，因为他有一套完整的流程保证所有的人做同样的事情都是同样的效果。这听上去挺好，但是，当你身处其中的时候，你 就会觉得你的技能被压制的。遇到一个故障，你接手，如果是小问题，如tablespace 满，ok，你开一个change去增加对应的大小，change会让所有相关的人员来审核，并且有2个DBA来review change，有第三者来部署change（因为部署的时候已经是你处理该问题之后的好几天了）；如果是大问题，如坏块或者ora-600，那么这个时候 就要提交SR，让oracle来做分析，你完全不需要做什么思考，就算你思考出来的结果，那也是不标准的，必须在SR中让oracle确认之后才算。那么 这种情况下，你还愿意去做所谓的troubleshooting么？
刚刚只是说了流程中的Incident Management，其他类似的还有好多，如Configuration Management，Change Management，Release Management，Problem Management，Availability Management，Asset Management，service Continuity，CapacityManagement，Service Level Management，Security Management……这些都不是技术上的项目，都是流程上的。上述虽然只是一个词组，但是任意一条展开了都有可能变成5000字的论文，呵呵。
所以，公司需要的是一个遵守制度，没有破坏力的DBA，并且这样的DBA又能在它的框架之下，运用他的能力和经验，帮他维护好系统，并且留下文档， 归入知识库中，以便作为为后一代的DBA的操作指南。而DBA是希望能借助公司这个平台更好的展示自己的能力，获取更多的经验，来提升自己。
博弈在继续……一方认为自己是黑客帝国中的Nero，另一方则努力把对方变成一个普通人。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/linux/118341.html