現實中，單實例的數據庫往往用的不多，生產環境往往需要高可用性，因此你必須了解各種高可用的架構，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是希望能借助公司這個平臺更好的展示自己的能力，獲取更多的經驗，來提升自己。