DBA應該具備什麼樣的素質？

問題起源於在寫一份材料的時候，對於本身的反思。

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