問題起源於在寫一份材料的時候，對於自己的反思。我把自己的觀點發到了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！
（漫畫作者：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，Capacity Management，Service Level Management，Security Management……這些都不是技術上的項目，都是流程上的。上述雖然只是一個詞組，但是任意一條展開了都有可能變成5000字的論文，呵呵。
所以，公司需要的是一個遵守制度，沒有破壞力的DBA，並且這樣的DBA又能在它的框架之下，運用他的能力和經驗，幫他維護好系統，並且留下文檔， 歸入知識庫中，以便作為為後一代的DBA的操作指南。而DBA是希望能借助公司這個平台更好的展示自己的能力，獲取更多的經驗，來提升自己。
博弈在繼續……一方認為自己是黑客帝國中的Nero，另一方則努力把對方變成一個普通人。
轉載地址：http://blog.jobbole.com/15499/
