問題起源于在寫一份材料的時候，對于自己的反思。

　　我把自己的觀點發到了 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，另一方則努力把對方變成一個普通人。

it知識庫：DBA應該具有什么樣的素質？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。