記得我在1999年在某網站第一次擔任DBA工作後不久，公司一位新來的財務總監（CFO）看到我的一份述職報告之後問我：“請問DBA代表什麼意思？”

我想現在別說CFO了，整個IT界都應該無人不知資料庫管理員（DBA）這個職位了，更深深理解這個崗位對企業的重要性。DBA，即企業最重要的資料資源管理者！俗稱“褲頭”啊，呵呵。

相比應用開發人員一般承擔具體應用模組開發，工作職責、工作範圍比較明確，而DBA卻給人感覺好像平時無所事事，而只有資料庫系統出問題了，才看到DBA救火的身影，給人一種“養兵千日，用兵一時”的感覺。“DBA究竟應該幹什麼呢？”身為Oracle原廠服務團隊，也是為廣大DBA提供服務、共同合作最多的我們，經常面臨客戶領導、技術人員這樣的問題。

以下就是我摘錄Oracle官方聯機文件之一，也是DBA應該最常備的手冊《Oracle® Database Administrator’s Guide11g Release 2 (11.2)》第一章中描述的DBA的11大職責：

我想上述11大職責是老外根據國外DBA經驗總結歸納而來，不僅體現了國外IT行業分工明確、細緻的特點，而且也有一定的學究氣。而國內IT行業DBA們都在幹什麼呢？可能有的國內DBA對上述11大職責不以為然：“我的工作內容比這還要多得多，不僅管資料庫，還管中介軟體和應用，甚至管硬體、作業系統、網路、儲存呢。”也有的DBA會感到汗顏：“我們在資料庫管理方面還真沒有這11大職責這麼細緻，比如我們可能從來不打補丁。”

以本人的感覺，無論是前者一樣面面俱到的通才，還是後者菜鳥一樣的初級入行者，其實就DBA本身工作職責而言，國內DBA們都或多或少有缺失，而最大的缺失就是DBA們對應用的缺失，甚至完全不關注。也許原因很多：有國內企業運維和開發兩大部門分工和職責過於明確的因素，也有DBA們自身認識偏差的因素。

總之以我的觀察，國內絕大多數DBA更專著於資料庫系統層面、甚至硬體等，而忽略了對應用的關注。換言之，國內各企業的DBA們其實更多扮演了系統級DBA角色，各企業明顯缺乏應用級DBA。我想這也是導致國內IT系統應用級和系統級脫節、IT系統整體質量不高的重要原因。

再介紹一個案例：在我們Oracle服務團隊為某外企提供應用優化和架構優化等服務過程中，我發現與國內大多數企業DBA一樣，該外企DBA也是一個標準的系統級DBA，因為他明顯缺乏對應用的深入瞭解，這種狀況在一定程度上影響了整個專案的實施質量和實施進度。於是，我感慨和建議道：“你們公司其實非常需要設定一個應用級DBA崗位。”

沒想到這條建議當天就被彙報到該企業的CTO，CTO深受啟發，第二天就給我反饋：“請羅老師告訴我們應用級DBA崗位的資質、工作職責、工作範圍，我們企業應該如何培養一名合格的應用級DBA？如果我們暫時培養不了，請你們原廠提供有資質的應用DBA專家。”

是啊，應用級DBA究竟做什麼？其實多年來，我也一直只是有這種感覺和建議而已，並沒有深入思考過這些問題。國內企業也鮮有這種角色可供參考，而且無論系統級還是應用級DBA的工作職責和範圍都是需要結合各企業、各單位具體情況進行定製的。儘管如此，本人今天還是斗膽提出如下一些拙見，拋磚引玉，供大家參考。

• 應用級DBA一定要有多年應用開發經驗

首先，應用級DBA一定要有多年應用開發經驗，我想這一條大家一定苟同。否則，他無法從應用層面，尤其從IT系統整體視野去看待問題。多年的應用開發經驗，更能讓他/她能以易於理解的語言與廣大應用開發人員溝通。

• 應用級DBA也一定要具有系統級DBA能力

其次，應用級DBA也一定要具有系統級DBA能力甚至實戰經驗，我想這一條大家也一定不會有疑義。當然，他/她可能不如一個真正系統級DBA那樣對系統層面的細節如此精通。但他/她至少應懂得RAC、Data Guard等技術原理，更能結合應用去看待系統層面的關鍵問題。

例如他/她應該知道在RAC環境下確保高效能、高擴充套件性的關鍵點是儘量減少RAC之間的資料訪問衝突，合理的應用部署和資料訪問分離是RAC實施成功的重要策略。他/她也應該知道Data Guard的關鍵因素是日誌檔案的產生量，他/她考慮的不僅是網路頻寬、主機和儲存對日誌檔案的傳輸和處理能力，他/她更應該考慮如何通過應用優化降低日誌檔案產生量，從而從源頭就確保Data Guard的成功實施。

• 應用級DBA = 系統架構師 + 資料庫設計師 + 應用設計開發專家 + 應用質量控制師

這一條實際上更細化了應用級DBA的工作範圍和定位。

從架構層面而言，他/她的確是資料庫採用集中式還是分散式架構的重要決策者，他/她還是RAC、Extended RAC、Data Guard、Active Data Guard、Golden Gate等技術架構方案的決策者和總體方案設計者。

從資料庫設計角度而言，他/她應該精通資料庫邏輯設計基本原則和規範化設計理論，甚至對PowerDesigner、E-R Win、Oracle Date Modeler等模型設計工具都非常熟詣。在資料庫物理設計方面，他/她更是對不同資料庫平臺的物理細節非常熟悉，例如深入瞭解Oracle表空間、表、索引、Sequence、物化檢視等各種型別資料物件的原理和物理屬性，還需要了解ASM事例、ASM引數、ASM磁碟組、ASM磁碟檔案等諸多系統層面細節。

在應用設計開發和質量控制方面，更應該是他/她的老本行。雖然他/她可能已經不再承擔具體應用模組開發工作了，也就是不再是烹製美味佳餚的廚師了，但他一定是位美食家，對各種SQL分析和診斷工具輕車熟路，並能準確定位各類SQL質量問題。更進一步，他/她還應該是應用設計開發規範的編制者和執行者。總之，他/她應該是最關係到IT系統質量的應用設計開發專家和質量控制師。

• 極強的組織、協調和溝通能力

應用DBA不僅應具備上述全面的知識架構和技能，更應具備極強的組織、協調和溝通能力。他/她不僅是應用開發團隊的領導者、組織者，而且也是與客戶、測試、運維等不同層面和角色的協調和溝通者，他/她的職責不是隻考慮區域性利益，而是真正能站在IT系統整體和全域性高度，去組織和協調IT系統建設、運維等各階段的工作，有效處理各階段、各部門存在的問題、矛盾和紛爭。

“羅老師，你這麼描述應用級DBA的資質和職責，這樣的人太難找了，你們原廠恐怕都沒有這樣完美的人吧？”是的，世界上很難找到具有這麼完美知識結構的通才，那我們還是要從實際出發，特別是從應用級DBA與系統級DBA的分工和合作角度出發，去追求IT 系統更高的目標和境界。

• 開發和運維是個整體

無論是國企還是外企，無論職責如何劃分，我們的確發現大多數企業的開發和運維兩個部門都存在著一定矛盾，甚至在某些企業達到了劍拔弩張的程度。這種局面對整個企業的IT系統建設是非常不利的，相互指責、相互推卸責任，甚至相互拆牆無濟於事，更是置企業IT系統整體質量於不顧。

• 應用級DBA與系統級DBA緊密合作的場景

我想還是舉幾個應用級DBA與系統級DBA緊密合作的具體場景，來加深大家對這種合作重要性的理解吧，也是為各企業開發和運維兩大部門如何進行具體合作提供一些參考。

在資料庫設計領域，如果系統級DBA也能參與其中，或者至少讓系統級DBA知曉資料庫邏輯設計和物理設計結果，一定可以充分發揮他/她的技術優勢和經驗。例如，系統級DBA非常熟悉磁碟系統的劃分情況，他/她就可以根據應用情況，提出ASM磁碟組劃分原則和實施建議，比如將最主要的交易表儲存在效能最好的磁碟組裡面，甚至根據ASM最佳實踐經驗，將這些交易表資料儲存在ASM磁碟的最外道，從而更充分滿足對這些最核心交易資料的訪問效能需求。

如果系統級DBA更能瞭解應用特徵，對他/她的各項運維工作也一定是大有幫助的。例如，當他/她知道主要業務表的訪問特徵，他/她就可以合理制定分級資料壓縮方案了，比如，當月頻繁訪問資料不壓縮；2-3個月訪問頻度比較低的資料採取OLTP壓縮演算法；更久遠的幾乎不訪問的資料採取歸檔壓縮演算法等。

再比如，當他/她瞭解了資料變更情況，就可以為資料碎片整理、歷史資料遷移和管理、資料備份/恢復等制定出更有針對性、更經濟合理、投入產出比更高的技術方案了。例如，我們就會發現國內Oracle系統不會都採取最簡單的“全庫備份+歸檔日誌備份”策略了，不僅會有“全量 + 增量”，而且還會有快速增量備份（FIB），甚至不僅在庫級，而且會根據業務資料分佈情況在表空間級、資料檔案級設計備份方案了。

反過來，應用級DBA如果能更深入瞭解系統層面的知識和技術，特別是掌握IT行業最新發展趨勢，就更有助於他/她設計更完美的IT技術架構，讓應用軟體設計更充分發揮新技術的特點和優勢了。比如，若他/她瞭解Oracle 12c推出了In-Memory Option技術了，他/她就可以指導其統計分析和報表開發團隊去深入瞭解這種技術併合理加以運用。若他/她瞭解Oracle 12.2即將推出水平分散式的Oracle Sharding技術，也知道這種技術主要適合於OLTP交易系統，因此他/她就可以指導其團隊將核心交易表設計為Sharded表，並通過Sharding Key進行水平分庫了。

其實寫到這兒，我自己都有點寫暈了，因為雖然各有側重，但是應用級DBA和系統級DBA其實是你中有我、我中有你的關係。也許在一個企業內部設定兩種DBA職位不盡合理，也不一定適合中國國情，但重要的是設計、開發、測試、運維等各階段和各部門的確是一個整體，只要各個部門、各種角色真正協調合作、良性迴圈起來了，IT系統整體質量就一定有保障了。

文章出處：DBAplus社群