DBA应该具备什么样的素质？

问题起源于在写一份材料的时候，对于本身的反思。

我把本身的观点发到了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！

除了上述的素质，公司也会考察咱们其余方面的东西。这些东西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，Capacity Management，Service Level Management，Security Management……这些都不是技术上的项目，都是流程上的。上述虽然只是一个词组，可是任意一条展开了都有可能变成5000字的论文，呵呵。

因此，公司须要的是一个遵照制度，没有破坏力的DBA，而且这样的DBA又能在它的框架之下，运用他的能力和经验，帮他维护好系统，而且留下文档，纳入知识库中，以便做为为后一代的DBA的操做指南。而DBA是但愿能借助公司这个平台更好的展现本身的能力，获取更多的经验，来提高本身。

博弈在继续……一方认为本身是黑客帝国中的Nero，另外一方则努力把对方变成一个普通人。