我们究竟要成为一个怎么样的 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 是希望能借助公司这个平台更好的展示自己的能力，获取更多的经验，来提升自己。