知識星球問題起源於在寫一份材料的時候，對於自己的反思。我把自己的觀點發到了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！
organizational charts
（漫畫作者：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://www.oracleblog.org/its-my-life/what-kind-of-quality-should-dba-have/