问题起源于在写一份材料的时候，对于自己的反思。我把自己的观点发到了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！
