dba（database administrator ）資料庫管理員，我每次和公司其他非技術部門的同事解釋我的工作的時候都要頗費口舌，直到最後如果他還是不明白的話，我只好說我們的工作其實和倉庫管理員沒什麼區別，都是管理乙個倉庫。更多的時候，我還要解釋資料庫和資料倉儲的區別（因為在公司裡，我們是兩個部門），一般我給出的解釋是：dba雖然是倉庫管理員，但是裡面的資料不是我們的，你如果需要資料的話，還得找資料倉儲。
我把dba分為三類：第一類：顧問型，他們屬於dba中的高階人才，經驗豐富，技術全面，提供專業的資料庫諮詢服務或培訓，擅長用偏門的技術解決問題。第二類：技術支援型，他們屬於各整合商或者專業的資料庫維護公司，最擅長搭建各種環境，從主機，儲存到os和資料庫都很熟悉，經常troubleshooting各種資料庫問題。第三類：運維型，他們維護自己公司的資料庫系統，穩定是對他們的唯一要求，他們經常要和整合商或者應用開發人員打交道。這三類dba中都有牛人，而且很多dba並不侷限於其中的一類，他們既是運維dba，也提供資料庫諮詢或培訓服務。
我們屬於運維型dba，但不同於其他公司的是，我們的資料庫每天都要上大量的專案，資料庫承受著巨大的壓力。由於資料庫的可用性基本上決定了**的可用性，所以必須有人能夠對應用加以控制，保證資料庫被正確的使用，所以我們的dba又分為產品dba和開發dba，其中產品dba負責產品資料庫的維護，包括主機儲存等，而開發dba則主要與開發人員打交道，為他們提供資料庫方面的支援，並參與到專案的設計過程中，開發dba的權力很大，當乙個專案設計不合理，可能會對資料庫造成危害時，我們有權力say：no！
我是公司的第乙個開發dba，在我沒進公司之前，那時的硬體比較差，流程和規範也沒有，經常上乙個專案就把整個資料庫搞宕機，dba總是手忙腳亂的四處救火。開發人員只關注sql是否能得到正確的結果，根本不關心sql的效能，而如果當專案上線後再發現問題，代價非常高，所以當時的dba老大就想到了開發dba這麼乙個角色（感謝rudolf）。我第一階段的工作，主要是優化每個專案的sql，保證每條sql是最優化的，通過建立適當的索引提高sql的效率。剛開始優化sql時，都是採用嘗試的方式，就是不斷調整執行計畫並一次次測試，直到測試的結果滿意，到後來就變成了先了解表和索引的狀況，看到sql後，最優的執行計畫就在腦海中出現了，然後再去驗證是否和我的想法一致。在這個階段，通過不斷建立流程和培訓開發人員來簡化我的工作。但我逐步發現，如果乙個專案在前期設計時就不正確的使用了資料庫，即乙個不合理的設計，後期很難通過優化sql來提高效能。第二階段，我開始逐步參與到專案的設計中去，基於我對資料庫的理解，給產品設計人員甚至需求方提供更好的建議。在這個過程中，最難的一件事就是如何說服別人作改變，我覺得最重要的就是信任感。雖然我經常say：no！但同時我一定會給出我的建議，通過乙個個專案的證明，使得設計和開發人員越來越信任我並依賴我，後來的所有重大專案，設計人員都會找我商量並聽取我的建議，這樣我的工作就變得越來越簡單。不過同時我也面臨著乙個問題：就是如何在專案開始時，就評估出對資料庫產生的影響。首先你必須非常了解應用，哪些功能會被頻繁使用到；第二你必須非常了解資料庫，表，索引以及相關的sql等等；第三你必須非常了解整個系統，當前的負載，邏輯讀和事物數等等，根據這樣一系列的資訊，並結合以往的專案，給出乙個綜合的判斷，事實上這是乙個非常困難的事，很多時候我們也是憑藉經驗來判斷。第三階段，dba開始與架構部門合作開發一些系統優化的專案，以前我們都是通過statspack發現一些top sql，可能是執行計畫不正確或者sql不夠優化，我們會要求開發人員修改。後來dba就開始主動推動一些資料庫優化專案，這些專案往往需要其他部門的協助，比如搜尋引擎和架構部門，所以現在我們的很多專案，都是由dba和架構部門共同來完成，比如今年我們的分布式資料庫（amoeba 變形蟲）專案。
後來，我轉向了產品dba方向，在這段時間內，我接觸到了各種主機和儲存，學習了很多硬體和os的知識，同時對兩種dba的角色也有了更深的理解，產品dba和開發dba對於資料庫的關注點是不同的，產品dba更關注執行維護，troubleshooting，備份恢復等方面，而開發dba更傾向於應用開發，效能優化等方面。
資料庫未來發展的方向，智慧型化自動化一定是個趨勢，各資料庫廠商也為dba提供了更方便更強大的管理和診斷工具。並且隨著大家使用資料庫的不斷成熟，低階的錯誤越來越少見，我們不可能再通過調整某個「引數」就讓系統效能大幅度得到提公升，尤其是我們管理的資料庫，引數基本上都已經是最優化了，調整的機會很少。那是不是都資料庫都自動化了，就不需要dba或者dba的重要性降低了，我倒不這麼認為。但是如果dba只具備資料庫的知識，應該是不足夠了。未來的dba不僅僅要了解主機，儲存，作業系統，並時刻關注硬體發展趨勢和資料庫新特性以外，還應該朝著da（data architect 資料架構師）的方向發展，從database到data就說明以後資料不一定在資料庫裡面了，從administrator到architect說明我們要懂架構，雖然我們不一定要懂得coding（pl/sql不算）。對於開發dba和產品dba來說，只是工作職責上的側重點不同，未來的環境肯定是要求dba掌握更多方面的知識。另外，好的溝通能力和團隊合作能力對於乙個優秀的dba也是必不可少。
出自:http://www.hellodba.net/2009/03
DBA的價值及其發展方向
看看時間大概已經有半年沒有來了,最近半年好像一直都忙碌著.也不知道忙些什麼.最近偶然間在思考乙個問題 dba的價值及其發展方向?圈子裡面也應該有好多dba吧,或者有志於做dba方面的工作,我也在想弄清楚dba的價值及其發展方向.前幾天看過一篇帖子說dba的價值不僅僅在於維護資料庫本身,而應該在資料儲...
未來軟體行業的發展方向
不知不覺已經工作很久了。從在校參加軟體設計大賽第一次寫專案 到現在已經6年7個月了。工作也足足5.5年了。從一開始不知道如何就業，到第一次軟體設計大賽後，決定寫 為生。從在校實習工作的不順心，到明白技術的重要性。事實證明3個月的實習，給我後來的工作也帶來不少幫助。後來去實習，大四一整年都在企業內度過...
未來資料庫發展方向
今天看了一篇文章 覺得比較有啟發 關係型資料庫已經用了差不多 30多年了 應該說比較成熟了 但是這片文章從新的角度分析了關係型資料庫的不足 結合當前軟硬體發展的趨勢 提出了新的資料庫設計的概念。1。傳統的關係型資料庫，包括 sql server oracle db2 都從system r 進化或者吸...