《DBA修煉之道：資料庫管理者的第一本書》——1.3節DBA的管理準則

本節書摘來自華章社群《dba修煉之道：資料庫管理者的第一本書》一書中的第1章，第1.3節dba的管理準則，作者（美）craig s. mullins，更多章節内容可以通路雲栖社群“華章社群”公衆号檢視

1.3　dba的管理準則

資料庫管理很少被視作一種管理準則。“準則”一詞意味着規劃并按照該規劃實施。當資料庫管理被視作一項管理準則時，公司内部的資料處理就會有所改善了。這就是消極被動和積極主動的差別。

dba組讓需求和問題淹沒是家常便飯。這有多種原因，包括人員缺乏、過度承諾支援新的（甚至現有的）應用程式開發項目、缺少可遵循的流程和缺少預算等。這種情況下，資料庫管理者就會變得消極被動。消極被動的dba更像是名消防員，他集中注意力去解決所關注的最大問題。換句話說，消極被動的dba隻有當問題發生後才嘗試去解決它們。

積極主動的dba在企業内部部署資料庫時，通過制訂并執行戰略藍圖，以避免諸多問題。該藍圖應當針對應用程式開發周期（adlc，詳見圖1-2）的所有階段。積極主動的dba通過執行規範和操作流程，避免問題發生。

積極主動的dba能避免許多問題。

資料專家，通常指dba，應當參與adlc的每一個階段。在項目啟動和需求收集階段，dba就要着手識别出項目的資料成分。他能夠幫助确認所需的資料已在别處存在或者是嶄新的。在分析和設計階段，他要把基本資料需求轉換成一種概念性的、邏輯上的資料子產品。

開始開發前，邏輯上的資料子產品要轉換為一種實體的資料庫設計，它可以用dbms實施，如oracle或db2。同時，樣本資料必須要植入實體資料庫中，用于測試應用程式。除此之外，dba還要通過開發并實施一種流程去重新整理測試資料，進而使得重複的測試能夠進行。

當應用程式開發完畢并開始運作時，dba要確定dbms為新負載做好了準備。包括：執行适當的安全措施，衡量并修改新應用程式對存儲盤和記憶體的需求，預估新負載對現有的資料庫和應用程式會帶來什麼影響。dba也負責新資料庫從測試環境到生産環境的遷移。

應用程式運作時，dba要履行“主機”的職責，包括性能和有效性監控、調試、備份和恢複、權限管理。但沒有程式或資料庫是長期保持不變的，因為業務的需求會改變，支撐業務的it系統也會改變。當需要維護時，dba又要再次忙于從需求收集到應用程式運作的整個過程了。當監控發現了一處性能缺陷時，dba要向開發團隊（如果問題出在程式代碼上），或者向負責存儲的團隊（如果i/o是瓶頸）建議更好的性能方案，或者推薦其他的解決方案，如新的或提升了的标準、替代性的sql代碼，等等。

隐私條款與隐私資料

資料隐私是一個新興的問題，正在成為越來越多的企業的負擔。不僅要管理的資料量增加了，新資料出現的速度也增加了。

在這個網絡化的世界中，我們徹底數字化了。我們有id、位置、操作、采購、關聯、動作，還有存儲的曆史資料。我們不禁要問了：是誰在收集這些資料？他們要用這些資料幹什麼？他們和誰共享這些資料？最重要的是，每個人都會問的是“我怎樣保護我的資訊不被濫用”。這些都是合情合理的問題，我們都想知道答案。

在美國，有超過30種聯邦法規和超過100種國家法規來管制資訊隐私，而對個人隐私卻一直是采用頭痛醫頭、腳痛醫腳的方式。另一方面，歐洲聯盟已經下達了資料保護指令，要求其成員國通過法律實作其職權。該指令為資訊收集的閱聽人賦予了權利，稱閱聽人為“資料當事人”。收集資訊的從業人員必須要向資料當事人說明誰在收集資料？最終誰能夠通路這些資料？為什麼要收集資料？資料當事人也有權限通路和修改他們的資料。

甚至還有資料隐私日，其目的是為了表達對那些通過個人資訊表達自己的人的尊重。

最近破産的borders書店提供了一個隐私政策影響企業資料的例子。borders停止經營的同時，一家競争對手書商barnes & noble收購了borders的部分資産，包括borders的品牌商标和客戶名單。然而，其第一個行動就是提醒客戶他們的權利。我收到的e-mail是這樣說的（部分内容）：

然而，重要的是你要明白，你有絕對的權利選擇退出，不使你的客戶資料轉移到barnes & noble。如果你選擇退出，我們将確定從borders收到的所有有關你的資料會以安全保密的方式處理掉。

這個例子說明了隐私政策是如何影響資料庫管理者和企業資料專家的工作的。當然，也許你工作的公司永遠不會破産，但你的公司可能會由于法律法規、經營狀況或兼并等淘汰一些應用程式和資料。

最後，當應用程式完成它的使命時，dba要确定使用該資料的應用程式的最終狀态。哪些資料不再需要了？其他的應用程式和程序也使用這些資料嗎？是否有規則要求這些資料存儲的時間比該應用程式長？企業是否有任何明确的隐私政策強調了處理資料的特殊規則？

dba負責管理整體的資料庫環境，通常包括安裝dbms和設定it基礎設施，以允許應用程式通路資料庫。所有這些要在開發任何應用程式之前完成。除此之外，臨時資料庫通路也是許多企業的需求。

此外，dba還負責臨時查詢環境的建立，包括查詢和報表工具的評估以及實施，建立工作準則和工作流程以確定臨時查詢的有效性，以及監控調優臨時sql語句。

如你所見，一名優秀的dba和整個應用程式開發生命周期融為一體。dba資料方面的知識以及利用現代化的應用程式管理資料的方式都很受歡迎。

優秀的dba和整個應用程式開發生命周期融為一體。

dba生涯的一天

dba生涯的每一天都是非常忙碌的。他要做好多事情：不僅要維護生産環境和測試環境，同時還要關注現有的應用程式開發項目，參加政策和設計會議，幫助選擇和評估新産品，把一些老舊系統聯網。dba joe剛才送出了“見鬼的查詢又把系統搞崩潰了，你又能怎麼樣呢？”的評論。所有這些對于dba來說都可能在同一天發生。

置身混沌之中，dba要知道所有事情，從技術到商業術語，再到最新的管理和技術的熱門話題，這些他們都要知道。沒有任何私人時間，dba在任何時候都要做好準備來回答任何問題，不僅是關于資料庫的。

每當應用程式出現問題時，人們總是首先譴責資料庫環境。資料庫“有罪，且除了證明它無罪之外别無他法。dba從沒有遇到過某個應用程式開發人員過來請教：“這裡的sql我用得很糟糕，你能幫忙解決嗎？”一般是開發人員闖進dba的工位吼道：“db2（或者指責你最鐘愛的dbms）有個問題，你為什麼不把它解決掉，那樣我很炫的程式就能跑起來了！”

應用程式出現問題時，資料庫是“有罪的，直到證明是無辜的”。

是以，dba不得不去證明那個問題不是資料庫引起的。他必須要知道資訊技術的方方面面，在他所設計的dbms和資料庫架構中跟蹤并排除錯誤。是以，他不僅要是資料庫技術方面的專家，還要知道和dbms關聯的所有it元件：程式設計語言、作業系統、網絡協定和網絡産品、事務處理器、能想到的所有計算機硬體，以及更多。需要了解如此多樣化的知識，dba也就成了非常寶貴的資源。他們的工作也變得有趣且充滿挑戰。

dba的工作是沒有休息的。資料庫程式是全天候運作的，是以dba要時時做好處理問題的準備。dba大多随身攜帶呼機或手機，保證随傳随到。如果資料庫在淩晨2點出了問題，dba也要從床上爬起來清醒一下就去解決問題，讓應用程式重新跑起來。否則會導緻資料庫故障，有可能導緻業務流程完全終止。

dba經常周末都坐在電腦前，在資料庫使用低谷時段維護并重組資料庫。早上9點到下午5點期間維護資料庫，不能讓關鍵的資料庫停止工作。坦白來講，現在越來越多的企業都是24小時工作制，昔日的8小時工作制已經成為神話。

如果這對你還有吸引力，那麼請繼續往下讀。實際上，也并不像聽起來那麼糟啦。這項工作很有趣，總是有新東西可以學，并且如前面提到的，薪水也不錯。問題是，哪個人能20年甚至更多年一直做這種工作而不需要休息的？額，我好像聽到你手機響了，你可能要去看看有什麼事了。