### 1.5　數據庫管理、數據管理和系統管理 一些企業分別為數據的商業方面和技術方面定義了不同的角色。數據的商業方面與數據管理是保持一致的，而更多技術方面都由數據庫管理員DBA掌控。并不是每一家企業都有數據管理的職位，而許多企業都將數據管理并入數據庫管理了。 有時企業也將數據管理的技術方面進行分離，DBA 負責使用 DBMS，而其他角色（系統管理或系統編程）負責安裝并升級 DBMS。 #### 1.5.1　數據管理 數據管理（Data Administration，DA）把數據資源管理的商業方面和用于數據管理的技術分離開。DA 存在于一家企業，與數據的實際商業用戶聯系更加密切。數據管理員（DA） 會更多地參與需求收集、分析和設計階段。而 DBA 參與設計、開發、測試和運作階段。 DA 和 DBA 的另一個有區別因素是他們工作的重點。 DA 負責以下問題： ● 確定并編寫商業用戶需要的數據目錄； ● 概念化產品并邏輯化數據模型，準確描述業務流程中的數據元素之間的關系； ● 產生企業數據模型，它要整合所有企業 / 業務流程使用的數據； ● 為企業設置數據政策； ● 確定數據擁有者和管理者； ● 為數據的控制和使用設置標準。 總之，DA 可看作企業的首席數據官。盡管 DA 的職位和技術沒什么特別的關系，但依我看來，DA 根本不是一個行政職位。實際上很糟糕，許多IT企業聲稱它們把數據看作公司的財產，但當你審視它們的行為時便會發現此聲明的虛假。數據政策的責任常移交給一些技術專家，但他們不能專注于非技術性的、商業方面的數據管理。這些專家可以很好地保證數據的可用性、性能和可恢復性，但通常不能保證數據的質量，也不能設置公司的數據政策。 **數據管理員可看作企業的首席數據官。** 實際上，數據很少被視作真正的企業資產。看看每家企業都有的資產吧：資金、人力資源、設備和原材料，每一種都是模式化的：賬戶一覽表、企業組織圖和層次報表、建筑藍圖和辦公室布局及材料賬單，每一種都可跟蹤、都受保護。企業還請來專業會計師確保資產賬目沒有任何差池。 我們能說大部分公司也這樣對待數據嗎？ 一個成熟的DA組織負責規劃并指導整個企業的數據使用需求。這個角色圍繞數據是如何記錄、共享和實施的展開工作。DA 的一個很大的責任是確保將數據元素在數據字典或數據存儲庫中予以準確地記錄。這是 DA 和 DBA 之間另外一個關鍵區別，DA 關注存儲庫，而 DBA 關注物理數據庫和 DBMS。 > 此外，DA 處理元數據，這與處理數據的DBA 截然相反。元數據稱作“數據的數據”， 更準確地說，元數據是對數據和業務所需要的數據的描述。數據管理負責業務和元數據策略。 這里舉幾個元數據的例子，它可以包括數據元素的定義，某個數據元素的業務名稱，該元素的任何縮寫形式，該元素的數據類型及長度。沒有了元數據，數據就難以使用。 元數據為數據提供了得以理解的上下文，因此也就成為數據的信息。在許多企業，元數據沒有系統地捕獲和編目，而大多存在于商業用戶的腦子里。元數據在系統中捕獲的位置遍布文件定義中的多個程序，以及準確性參差不齊的文檔中，或長時間不用的程序定義中。當然，其中一些位置在 DBMS 的系統目錄中。 綜合的元數據策略使得企業知道所控制的資產信息并衡量這些資產的價值。 > DA對公司數據資產的最大貢獻之一是創建數據模型。概念化數據模型能夠非常高水平地概括出數據需求。邏輯化數據模型為數據類型、長度、關系及基數提供了深入的細節。DA 采用標準化技術提供能夠準確描述企業的數據需求的完善數據模型。 很多DBA 會把數據管理當做單純的數據模型摒棄，因為有人要從終端用戶那里獲得數 據庫需求。但真正的DA 的作用遠不只是單純的數據模型，而是一種面向商業管理的、為企業數據資產服務的準則。 為什么在一本關于數據庫管理的書中花這么多時間來討論數據管理呢？為數不多的企業實現并雇傭了DA。企業做得越大，越有可能設置DA 職位。然而，當一家企業里DA的角色沒有確定時，DBA 就要承擔數據策劃與建模的職責了。 而由于以下原因，DBA 通常不能夠承擔 DA 所有的職責。 ● DBA 要履行許多其他技術方面的職責，這占用了他大部分的時間。 ● DBA 團隊的經理一般沒有行政職務使他決定策略。 ● DBA 一般不具備與商業用戶有效溝通并達成共識的技巧。 ● 坦率地說，大部分的DBA 更愿意處理技術問題及與技術專家打交道，而非碰觸業務問題及非技術人員。 > 當 DA 和 DBA 在企業共存時，這兩個團隊要非常密切地合作。當然，沒有必要要求他們有共同的經理，不過若有，可能更容易促進他們的合作。無論如何，重要的是兩個團隊之間要有一定程度的技術交流。因為DA 永遠不會像 DBA 那樣了解物理數據庫，而DBA 也不會像 DA 那樣了解數據的業務問題，每種工作都借鑒其他工作的知識就會更有效率。 總之，企業若真正關心數據的質量、完整性和再利用時，都會安排DA 的職位。 #### 1.5.2　數據庫管理 數據庫管理是整本書的重點，本節就不花太多時間來定義它了。本書以后的部分會給出詳細的定義。本節將快速概括當 DA 也存在時，DBA 團隊所起的作用。  如圖1-3 所示，DBA 管理數據而 DA 管理元數據，現在就更深入了解一下吧。 DBA 的首要職責就是理解DA構建的數據模型并能夠與應用程序開發者以及其他相關技術人員討論該模型。邏輯數據模型是DBA用來創建物理數據庫的映射。DBA 要把邏輯數據模型轉換成一種有效的物理數據庫設計。重要的是， DBA 結合DBMS中用到的知識，根據邏輯模型創建一個有效且合適的物理數據庫設計。 #### 1.5.3　系統管理 一些較大的企業會設置系統管理（SA）或系統程序設計的職位，有助于 DBMS 的實施和運行。當SA 和 DBA 共存時，SA 負責DBMS 的安裝和設置。他們一般不負責數據庫的設計和支持。而DBA 負責數據庫，SA 負責DBMS 的安裝、修改和支持。如果你不清楚這種區別，請參閱附錄 A 中數據庫術語的明確定義。 此外，SA 還負責IT 基礎設施的實施，配置DBMS 與其他授權系統軟件一起運作。SA 可能需要和其他技術人員合作來配置事務處理器、消息隊列、軟件、網絡協議以及操作系統參數，使DBMS 有效地運行。為了開發數據庫，SA 還要通過合理地設置DBMS，向DBMS 供應商申請持續維護，以及升級 DBMS 版本來確保 IT 基礎設施正常運作。 為了開發數據庫，系統管理員還要通過合理地設置DBMS，向DBMS 供應商申請持續維護，以及升級 DBMS 版本來確保 IT 基礎設施正常運作。 與 DA 一樣，SA 和 DBA 之間也要交叉培訓技能。SA 永遠都不會像DBA 那樣了解物理數據庫，但DBA 也不太可能像SA 那樣懂得系統軟件的安裝以及它們之間深入的技術關系。 了解一些其他的知識，每種工作都能更有效地發揮它的作用。 當沒有獨立的 SA 團隊或沒有專注于 DBMS 的 SA 時，DBA 就要承擔系統管理和編程的責任了。  圖 1-4 中對 DA、DBA 和 SA 的職責提供了簡短的描述 ### 1.6　DBA 的任務 DBA 要能勝任多種任務以保證企業的數據和數據庫是有用的、可用的、有效的、正確的。任務包括：設計、性能監控及調節、保證有效性、授權的安全性、備份與恢復、保證數據的完整性，還有和公司數據有關的一切。 #### 1.6.1　數據庫設計 人們認為 DBA 的首要任務就是建立設計完美的數據庫。要想設計并建立合理的關系數據庫，DBA 就要懂得并遵循合理的關系設計原則。他們必須要懂得相關理論及用于建立數據庫的 RDBMS 的具體實施細節。設計數據庫要充分理解概念的和邏輯的數據模型知識。具備建立及解釋實體關系圖的能力對于設計關系數據庫是必不可少的。 此外，DBA 要能夠把邏輯數據模型轉換成物理數據庫。DBA 要保證設計和實施的數據庫對應用程序及使用它的客戶端是有用的。 **DBA 要能夠把邏輯數據模型轉換成物理數據庫。** 數據庫設計確實是 DBA 要擁有的一項重要技能，而 DBA 的工作常與數據庫設計不太相干。盡管設計最優的數據庫很重要，但這只占據DBA 工作相當小的一部分。相比最初的設計和搭建數據庫，DBA 在管理和調整數據庫上花費的時間有可能更多。 #### 1.6.2　性能監控和調優 與 DBA 密切相關的第二種任務是性能監控和調優。但什么是數據庫性能？暫且用我們 熟悉的供需概念來考慮一下吧，用戶對于數據庫的需求信息，DBMS 對這些需求所提供的信 息。DBMS 提供信息需求的速度就可以叫做數據庫性能。但不會那么簡單，有 5 種因素可以 影響數據庫性能：工作負載、吞吐量、資源、優化和競爭。 對 DBMS 請求的工作負載（workload）定義了需求。這結合了在線交易、批量作業、隨機查詢、數據倉庫、分析查詢，和在任意給定時間內直接通過系統的指令。工作負載可以每天、每小時、每分鐘甚至每秒鐘都大幅波動。有時候工作負載是可以預估的（比如，月底大量的結算過程，或下午七點半大部分用戶下班后對數據庫訪問減少），但其他時間不可預估。 整體工作負載對數據庫性能有著重大的影響。 吞吐量定義了計算機硬件和軟件的整體能力。這整合了I/O 的速度、CPU 的速度、機器的并行能力、操作系統及系統軟件的效率。由系統支配的硬件和軟件工具稱為“系統資源”。 例如，數據庫內核、磁盤空間、高速緩存控制器和微代碼。 數據庫性能的第四個定義元素是優化。所有類型的系統都可以優化，但在這些優化中關系查詢都是獨特的，主要在 DBMS 內部完成。然而還有許多其他因素有待優化（SQL 表述、 數據庫參數、有效的程序設計等），從而使數據庫優化程序能夠創建最有效的訪問路徑。 當對某一特殊資源的需求（工作負載）很高時，競爭就產生了。競爭產生的條件是：兩個或多個工作負載元件試圖以一種沖突的方式（例如，對同一數據段進行雙重更新）使用單個資源。隨著競爭的增加，吞吐量隨之降低。 因此，數據庫性能可以定義為資源利用的優化以增加吞吐量并減少競爭，從而最大可能地處理工作負載。 每當使用數據庫的應用程序遇到問題時，DBA 常常會首先被叫過來解決問題。當然， DBA不能憑空管理數據庫性能。應用程序會定期與其他應用程序、系統和IT 基礎設施組件 進行通信。一種有效的性能監控調整策略不止需要DBMS 專項技術，還需要數據庫管理以外的知識。許多性能管理任務需要DBA 和其他技術專家共同完成，換句話說，處理性能問題真的是種企業范圍的努力。 DBA 要在監控系統、數據庫和應用程序性能中保持警惕，這通過自動化軟件和腳本可 以盡可能地實現。輪詢系統表并構建基于臨界值的警報可以主動識別這類問題。當性能指標不在期望范圍內時，設置的警報可以發送電子郵件給 DBA。 許多任務和能力的實現都要求DBA 要保證數據庫的有效訪問。 這些能力包括：建立恰當的索引，指定足夠大的緩沖區和高速緩存，使數據庫實現和IT 基礎設施相符，對數據庫和應用程序的持續監控，數據庫重構，以及適應業務的改變（更多的用戶、更多的數據、附加的過程、改變需求和規則）。 #### 1.6.3　保證可用性 數據和數據庫的可用性常與性能密切相關，但實際上是分開考慮的。當然，如果 DBMS 處于脫機狀態，性能表現將很可怕，因為沒有數據能夠訪問。但保證數據庫的可用性是個多方面的過程。 可用性的第一要素是要保持DBMS 持續運行。警惕監控與自動警報可以用來報告 DBMS 中斷并要求補救措施。 個人數據庫也必須維護，使得其中的數據可供應用程序和客戶端調用。這樣不僅需要 DBA 設計數據庫，使得能以最小的中斷去維護它，還要幫助設計應用程序，在需要并發訪問時把沖突降到最低。 可用性的另外一個要素是要降低執行管理任務的停機時間。DBA 執行需要數據庫脫機的管理任務越快，數據可用性就越強。越來越多的 DBMS 供應商和獨立軟件開發商（ISV）提 供不間斷的實用程序，在數據庫上執行它們，而應用程序通過它們對數據庫進行讀寫。 但這些通常需要更多的技巧和前期規劃才能實現。 DBA 必須了解所有這些方面的情況，并確保每個應用程序的需求都接收了正確等級水平的可用性。 #### 1.6.4　數據庫安全和授權 數據庫一旦設計好并部署，程序員和用戶就需要訪問并修改數據庫中的數據。但為防止安全漏洞和不當的數據修改，只有得到授權的程序員和用戶才能夠訪問。 DBA 的職責是要確保數據只提供給授權用戶。 盡管并不盡然（詳見“安全的集中化”），但DBA 不僅要與DBMS 的任意組授權功能打交道，還要通過“SQL GRANT”和“REVOKE”語句與 DBMS 內部的安全功能打交道。要為數據庫環境請求的許多行為進行安全管理： ● 創建數據庫對象，包括數據庫、表、視圖和程序結構； ● 變更數據庫對象的結構； ● 訪問系統目錄； ● 讀取并修改表中的數據； 創建并訪問用戶定義的功能和數據類型； ● 運行存儲過程； ● 開始并停止數據庫，關聯數據庫對象； ● 設置并修改 DBMS 參數和說明； ● 運行數據庫實用程序，如 LOAD、RECOVER 和 REORG。 數據庫安全也可以用其他方式強制執行，例如，創建視圖以防止敏感的列與行被終端用 戶和程序員查看。當外部的安全方法影響數據庫安全時，DBA 也經常和這些安全方法打交道。 DBA 必須了解并能夠實施影響數據庫訪問的任何安全方面。 **安全的集中化** 一些企業已經采取措施，將所有的安全和授權任務、政策和程序，都集中在一個IT 安全組。這并不容易實現，正因為如此，相比規模較小的企業，它多見于較大型的企業。 受到嚴格監管的行業可以選擇集中的安全操作。此外，擁有大型計算機的企業往往比那些沒有大型計算機的企業更傾向于集中安全。 要成功地將數據庫安全的職責從數據庫管理團隊轉移到一個集中的安全團隊，這需要給安全人員培訓數據庫安全有關的技術。此外，許多商家使用的軟件從DBMS 刪除了一些安全操 作，并在一個更加傳統的安全包（比如，大型計算機上的 RACF 或ACF2）內模仿相同的功能。 即使考慮所有這些問題，大多數的企業仍然依賴 DBA 來管理數據庫安全。 #### 1.6.5　治理與合規性 確保符合行業和政府法規的要求是數據庫管理的一項附加任務，至少在部署適當的控制方面。DBA 必須要與管理人員、審計人員和業務專家一起合作來了解適用他們行業的法規及處理數據的方式。 > 合規性的某些方面是關于標準的DBA 作業程序的。例如，法規可能包含執行特定安全和授權程序使用的語言、審計要求、數據備份規范和變更管理程序。然而，要確保合規可能需要嚴格的文檔，或者更高程度的盡職調查或自動化（比如，更深層次的審計跟蹤）。 合規性的其他方面，可能需要DBA 采用不同的技術、戰術和技巧。例如，數據保留法規可能要求數據在使用后仍能存儲在一個生產數據庫中以長期保留，這就需要數據庫有歸檔的能力； 或某些數據可能需要得到保護以免被查看，這就需要數據屏蔽，或在某些情況下設置數據加密。 DBA 不應該負責深入地理解任何法規，也不應該設置企業遵守法規的標準。然而，他們會幫助合規項目設置適當的控制及程序，特別是數據處理方面。 #### 1.6.6　備份和恢復 DBA 必須做好準備在問題發生時恢復數據。“問題”可能意味著任何系統故障或程序錯誤或者一場自然災害而導致一家企業關閉。現在，大部分數據恢復是應用軟件錯誤和人為錯誤導致的，硬件故障并不像從前那樣普遍了。事實上，分析師的估計表明，80% 的應用程序錯誤是由于軟件故障及人為錯誤。不管什么原因，DBA 必須時刻準備著盡快將數據恢復到一個可用的點。 面對一次重大停機，通常想到的第一種數據恢復是恢復到當前。數據恢復的最終結果是，該數據庫被恢復到發生故障前的狀態。在恢復完成之前，應用程序完全不可用。 另一種類型的傳統數據恢復是時間點的恢復。時間點的恢復通常用來處理應用程序級別的問題。常規技術執行時間點的恢復將刪除指定的時間點以后的所有交易帶來的影響。如果在該時間范圍內一些有效的交易仍然需要，就會出現時間點后的交易不能恢復的問題。 事務恢復是第三種類型的恢復，解決了傳統恢復類型停機時間和有效數據丟失的弊端。 因此，事務恢復是一種應用程序恢復，即在指定時間內刪除數據庫中特定交易所帶來的影響。事務恢復有時也稱為“應用程序恢復”。 大多數技術人員認為數據恢復是為了解決硬件故障等災害。雖然硬件故障仍時有發生， 但技術人員要做好從這樣的故障中恢復的準備，當今大多數數據恢復是源于人為錯誤或程序自帶錯誤。 DBA 必須準備應付所有這些類型的數據恢復。這涉及制訂備份策略，以確保數據在軟件、硬件或手動操作的錯誤事件中不丟失。策略必須適用于數據庫處理，所以它必須包括數據庫文件的映像副本以及數據庫日志的備份/ 恢復計劃。它需要考慮同樣能影響數據庫應用程序的任何非數據庫文件的活動。 #### 1.6.7　確保數據完整性 數據庫必須能夠以正確的方式存儲數據并且不會使數據損壞或破壞。在此過程中，DBA 需要利用 DBMS 的功能實現完整性規則。完整性的三個方面和數據庫的討論相關：物理的完整性、語義的完整性和內部的完整性。 物理問題可以使用DBMS 的功能，如域和數據類型處理。DBA 為每張表的每一列選擇適當的數據類型。此操作可確保只有該類型的數據存儲在該數據庫中，即 DBMS 強制執行數據類型的完整性。A 列定義為整型，則該列只能包含整數。試圖在定義為整型的列中存儲非數字或者非整數值都將失敗。 DBA 也可以使用約束來進一步劃定可以存儲在數據庫列中的數 據類型。大多數相關的 DBMS 產品提供了以下類型的約束： ● 參照約束，用于指定定義了表之間的任意關系的列。參照約束用來實現參照完整性， 從而確保一張表的一列數據（或一組列）的所有預期的參考，相對于相同或不同表的另一列中的數據是有效的。 ● 唯一約束，確保表中的一列或一組列的值只出現一次。 ● 檢查約束，用來在表中的一列或一組列中放置更復雜的完整性規則。檢查約束通常使用 SQL 定義，并可以用來定義一列或一組列允許的數據值。 語義完整性更加難以控制且不易定義。DBA 必須準備要執行的策略和方法，以確保他們在數據庫中存儲的數據是準確的、合適的且可用的。舉一個有關語義問題的例子，如數據庫中的數據的質量。僅存儲任何符合數據庫定義的物理完整性的數據是不夠的，還要有策略和方法以確保數據的質量。例如，一個客戶數據庫，其中 25% 的客戶數據含有錯誤的地址或電話號碼，這就是一個質量很差的數據庫。沒有系統的、物理的方法保證數據的準確性。數據質量要通過適當的應用程序代碼、健全的商業慣例和特定的數據政策來保證。冗余是另一個語義問題，如果在整個數據庫中數據元素都有冗余，DBA 應該如實記錄這些問題并找出保證冗余數據同步和準確性的方法。 完整性的最后一個方面是DBMS 內部的問題。DBMS 依賴內部結構和代碼來維護鏈接、 指針和標識符。在大多數情況下，DBMS 會很好地維護這些結構，但DBA 也需要知道這些情 況，以在 DBMS 失敗時知道如何應對。在以下幾個方面，內部 DBMS 的完整性是必不可少的： ● 索引的一致性。 索引是數據庫表中數據的有序指針列表。如果由于某種原因，索引與數據不同步，索引訪問可能無法返回正確的數據。DBA 有檢查和糾正這些類型錯誤的工具。 ● 指針的一致性。 有時大型多媒體對象并沒有和其他數據一起存儲在同一個物理文件 中。因此，DBMS 需要指針類型的結構，以保持基表數據與多媒體數據同步。強調一 下，如果不遵守適當的管理程序，這些指針可能會不同步。 ● 備份的一致性。 有些DBMS 產品偶爾會接收不恰當的備份副本，實際上這些副本對恢復作用不大。關鍵是要識別這些情況，并采取相應改正措施。 總而言之，確保數據完整性是 DBA 的一項必不可少的技能。 ### 1.7　DBMS 版本遷移 DBA 也負責管理DBMS 的版本遷移，DBMS 產品變更相當頻繁，通常每年都會有新版本發布。保持DBMS 運行和更新是一項持續的工作，將占據DBA 工作的大部分時間。要降低停機幾率和減少應用程序需求變化，無論采用何種方法都必須與企業的需求相符。 保持 DBMS 運行和最新是一項持續的工作，將占據 DBA 工作的大部。 #### 多面手 數據庫是現代應用程序的核心，如果 DBMS 失敗，應用程序隨之失敗，進而整個業務 也被迫停止；如果數據庫和應用程序經常失敗，整個業務也可能會失敗。因此數據庫管理員對現代商業的持續成功至關重要。 此外，幾乎 IT 基礎設施的每一個組成部分都與數據庫交互，當今的 IT 基礎設施包括： ● 編程語言和環境，如 COBOL、Microsoft Visual Studio、C/C++/C#、Java 和 PHP； ● 軟件框架，如 .NET 和 J2EE； ● 數據庫和流程設計工具，如 ERwin 和 Rational Rose； ● 事務處理系統，如 CICS 和 Tuxedo； ● 應用程序服務器，如 WebSphere、JBoss、Oracle Application Server 和 EAServer； ● 消息隊列軟件，如 MQSeries 和 MSMQ； ● 網絡軟件和協議，如 SNA、VTAM 和 TCP/IP； ● 網絡硬件，如網橋、路由器、集線器和布線； ● 多種操作系統，如 Windows、z/OS 和 MVS、UNIX 和 Linux，以及其他系統； ● 數據存儲硬件和軟件，如企業級存儲服務器、Microsoft SMS、IBM DFHSM、SAN 和 NAS； ● 操作系統安全包，如 RACF、ACF2 和 Kerberos； ● 其他類型的存儲硬件，如磁帶機、料倉和固態存儲（內存）； ● 非 DBMS 數據設置和文件存儲技術，如 VSAM 和 b-tree； ● NoSQL 產品，如 Hadoop 和 MongoDB； ● 數據庫管理工具以及它們如何與其他系統管理解決方案交互； ● 系統管理工具和框架，如 HP OpenView 和 CA Unicenter； ● 操作控制軟件，如 batch 調度軟件和作業控制子系統（Job Entry Subsystem，JES）； ● 在整個網絡中實現系統軟件新版本的軟件分布解決方案； ● 互聯網和基于 Web 的數據庫和應用程序； ● C/S 開發技術（多層式、胖服務器 / 瘦客戶端、瘦服務器 / 胖客戶端等）； ● 面向對象和基于組件的開發技術 / 技能，如 CORBA、COM、OLE/DB、ADO 和 EJB； ● 普遍計算技術設備，如平板電腦和智能手機。 盡管要成為所有這些技術的專家不太可能，但是DBA 也應該了解這些領域的知識，以 及它們是如何關聯的。更重要的是，DBA 要有那些專家的電話號碼，以防任何一種相關的軟件和硬件導致數據庫訪問或性能出問題。 ### 1.8　DBA 的類型 有些DBA 專注于邏輯設計，有些則專注于物理設計：專注于搭建系統的DBA 以及專注于維護和調整系統的 DBA；專業的 DBA 和通用的 DBA。誠然，DBA 的工作包含了許多角色。一些企業選擇將DBA 的職責細分成獨立的工作。當然，這大多是在較大的企業，較小的企業往往付不起請多個專業的 DBA 的費用。 還有一些公司干脆雇傭DBA 來執行所有的任務：設計、創建、歸檔、調整及維護公司的數據、數據庫、數據庫管理系統。 下面介紹一些比較常見類型的 DBA： #### 1.8.1　系統DBA 系統 DBA 專注于技術而不是業務問題。特別是在系統管理領域，系統DBA 專注于技術而不是業務問題。 典型任務主要是 DBMS 軟件的物理安裝和性能，包括： ● 安裝新版本的 DBMS 并應用 DBMS 供應商提供的維護補丁； ● 設置并調節系統參數； ● 調節操作系統、網絡和事務處理器，使它們與 DBMS 協同合作； ● 確保 DBMS 的適當存儲； ● 使 DBMS 與存儲設備和存儲管理軟件協同工作； ● 配合數據庫應用程序所需要的其他技術； ● 安裝 DBA 工具和實用程序。 系統DBA 很少參與數據庫和應用程序的實際部署。當操作系統參數或復雜的DBMS 參數需要修改時，他們可能會參與應用程序的調優。 事實上，通常只有在企業沒有真正的系統管理員或系統程序部門的情況下，系統DBA才存在。 #### 1.8.2　數據庫架構師 > 一些企業為設計和部署新數據庫設立了一個單獨的職位，簡稱數據庫架構師。數據庫架構師只參與新的設計和開發工作，不參與搭建數據庫及應用程序的維護、管理和調優工作。數據庫架構師為新應用程序或者現有的應用程序設計新的數據庫。 數據庫架構師只參與新的設計和開發工作。 設立這樣一個單獨的職位是由于設計新數據庫所需要的技能和維持現有的數據庫運行的技能有所不同。數據庫架構師的數據管理和建模技術可能比通用DBA 更專業，因為DA 技能在初始數據庫設計時更加有用。 數據庫架構師的典型工作包括： ● 創建邏輯數據模型（如果沒有 DA 或數據建模師）。 ● 將邏輯數據模型轉換為物理數據庫設計。 ● 部署有效的數據庫，包括物理特性、索引設計和映射數據庫對象到物理存儲設備。 ● 分析數據訪問和修改需求，確保 SQL 的高效性以及最佳的數據庫設計。 ● 為新的數據庫創建備份和恢復策略。 大多數企業都不會安排單獨的數據庫架構師職位，而是要求DBA 兼顧新的和已有的數據庫項目。 #### 1.8.3　數據庫分析師 另一種常見的職位是數據庫分析師。數據庫分析師根本沒有一個通用的定義，有時高級 DBA 稱作數據庫分析師，有時與數據庫架構師所做工作類似，有時 DA 要扮演數據庫分析師或數據分析師，有時數據庫分析師只是一些企業對數據庫管理員的另一種稱呼。 #### 1.8.4　數據建模師 沒有定義或配備DA 角色時，可能會定義一個數據建模師。數據建模師通常負責部分 DA 工作，數據建模的任務包括： ● 為開發項目收集數據需求； ● 分析數據需求； ● 設計基于項目的概念和邏輯數據模型； ● 建立企業的數據模型并隨時更新； ● 與 DBA 合作，以確保他們充分了解該數據模型。 #### 1.8.5　應用程序DBA 與系統DBA 直接對比的是應用程序 DBA。應用程序DBA 專注于數據庫的設計和管理， 以及對特定的一個或多個應用程序的持續支持。應用程序DBA 可能擅長編寫和調試復雜的 SQL 語句，并懂得在應用程序中做數據庫請求的最佳方式。他們還必須能夠執行數據庫的變更管理、性能調優以及DBA 的大多數其他工作。所不同的是，應用程序DBA 關注應用程序的特定子集，而非整個 DBMS 的部署和數據庫環境（詳見圖 1-5）。  應用程序DBA 專注于數據庫的設計和管理，以及對特定的一個或多個應用程序的持續支持。 并非每個企業都配備了應用程序DBA。有該職位時，通用DBA 仍需要支持數據庫的整體環境和基礎設施；沒有該職位時，通用DBA 很可能在維護企業數據庫環境的同時還要支持特定應用程序。 有人贊成配備應用程序 DBA，也有人反對。贊成的理由如下： ● 應用程序DBA 可以更好地專注于單個應用程序，這就可以更好地服務于該程序的開 發人員。 ● 應用程序DBA 常被視作開發團隊不可分割的部分，因此可以更好地了解新的開發計 劃以及計劃的改變。 ● 因為應用程序DBA 一直從事于某些特定的應用程序，他們可以更好地把握每個應用 程序運行的狀況，從而可以給開發人員更好的支持。 ● 有了對應用程序的全面了解，應用程序DBA 會更好地理解應用程序是如何影響整體 業務的。這方面的知識更有助于他們為企業提供更好的支持。 但并不是所有人都支持應用程序 DBA，反對的理由如下： ● 由于應用程序 DBA 只專注于單個應用程序，他們可能會忽視企業整體的數據需求。 ● 缺乏與集中的 DBA 團隊的溝通導致技能共享減少，應用程序 DBA 會變得孤立。 ● 應用程序DBA 實現有用的程序（procedure）時，需要付出更多的努力和其他DBA 分享。 ● 應用程序DBA 以應用程序為中心，他們可能會忽視DBMS 團隊交付的新特性和 功能。 一般情況下，配備了應用程序DBA，也一定要配備一個集中的DBA 團隊。應用程序 DBA 雖然主要負責特定的應用程序，也應該被視作集中的DBA 團隊的一員。這樣將會發揮 應用程序 DBA 的正面作用，同時打消其負面作用。 #### 1.8.6　面向任務的DBA 較大的企業有時會有專注于某個特定任務的專門的DBA。但面向任務的DBA 在較小的 IT 企業里很少存在，他們整天致力于確保企業數據庫的備份和恢復。 大多數企業都無法負擔這種水平的 DBA，但如果可能，則能確保重要的任務都有專人處理。 #### 1.8.7　性能分析師 性能分析師是一種典型的面向任務的DBA。比其他面向任務的DBA 更常見的是，性能分析師只專注數據庫應用程序的性能。 性能分析師必須了解 SQL 性能編碼的細節和微妙之處，以及有能力設計數據庫的性能。性能分析師在技術層面非常了解在用的DBMS，從而能夠在需要時對DBMS 和系統參數作出適當的改變。 但性能分析師不應該是一個系統DBA。性能分析師能夠和程序開發人員有效溝通，從而幫助他們為了得到更好的性能而相應地改變程序。 性能分析師通常是技藝精湛的 DBA 高級成員。成為一名高級 DBA 很有可能歸結于他的經驗以及在以往的調優工作中獲得的尊重。 #### 1.8.8　數據倉庫管理員 企業為了進行深入數據分析而部署數據倉庫，通常會特別配備DBA 來監控并支持數據 倉庫環境。數據倉庫管理員必須是有能力的DBA，并且完全了解支持在線事務處理（OLTP） 的數據庫與數據倉庫之間的差別。 常見的數據倉庫管理員的任務和需求包括： ● 使用商業智能、數據分析、查詢和報表工具； ● 只讀訪問權限的數據庫設計； ● 數據倉庫的設計事務，如星型模式； ● 數據倉庫技術，如聯機分析處理或 OLAP（包括 ROLAP、MOLAP 和 HOLAP）； ● 數據變換和轉換技能； ● 了解數據質量問題； ● 處理用于加載和卸載數據的數據格式； ● 中間件的實施和管理人員注意事項。 ### 1.9 人員配備的考慮 配備 DBA 不是一件簡單的事情，有幾個有待解決的重要的考慮，包括 DBA 人員的規模 和 DBA 報告結構的規模。 #### 1.9.1　需要多少DBA 最難確定的事情之一是保證企業數據庫在線并高效運作的DBA 的最佳數量。許多企業都試圖將DBA 人員規模降到最低，本想著人員減少了成本就降低了，但這種假設一般是不正確的。一個過度勞累的DBA 可能會犯錯，而導致的停機時間和操作問題的成本遠遠超過 一個額外的 DBA 的薪資成本。 但確定 DBA 的最佳數量不是一門精確的科學，它取決于多種因素，包括： ● 數據庫的數量。需要支持的數據庫越多，數據庫管理的工作就越復雜。每一個數據庫都需要設計、部署、監控可用性和性能、備份以及管理。而一名DBA 能夠控制的數據庫數量是有限的。 ● 用戶數量。隨著更多的用戶聯機作為訪問數據庫應用程序的客戶端，確保數據庫的最 佳性能變得更加困難。此外，隨著用戶量的增加，問題量與調用量增加的可能性也隨 之增加，進而增加了 DBA 工作的復雜性。 ● 應用程序的數量。一個單一的數據庫能被多個應用程序使用，實際上，DBMS 的主 要好處之一是使數據可以在整個企業內共享。隨著更多的應用程序聯機，對數據庫的 性能、可用性和需要的資源等方面都施加了壓力，相同數量的數據庫可能需要更多的 DBA 來支持。 ● 服務水平協議（SLA）。SLA 越嚴格，DBA 越難提供滿意的服務。例如，需要1 秒響 應時間的 SLA 比需要 3 秒響應時間的 SLA 更加難以支持。 ● 可用性需求。當數據庫具有可允許的計劃停機時間時，數據庫管理就變得更加容易， 因為一些DBA 任務要么需要中斷運行，要么在中斷時更加容易進行。一些考慮（諸 如要支持電子商務交易和網絡），推動了對 24/7 數據庫可用性的需求。 ● 停機時間的影響。數據庫不可用對財務的影響越大，DBA 就越困難，因為有人會施 加壓力以確保數據庫更佳的可用性。 ● 性能需求。隨著對數據庫的訪問需求變得更加面向性能、更加快速，而要求的訪問也 更加頻繁，DBA 變得更加復雜。 ● 應用程序的類型。企業部署各種類型的應用程序，必須要支持的應用程序的類型對需要什么DBA 服務有所影響。DBMS 和數據庫對關鍵任務的應用程序的需求與對非關 鍵任務的應用程序的需求是不同的。關鍵任務的應用程序可能更需要持續地監控和更多的警惕，以確保其可用性。同樣，OLTP 應用程序與OLAP 應用程序會有不同的特 點及管理需求。OLTP 處理事務的時間可能比OLAP 查詢時間更短；OLTP 應用程序執行讀取和寫入操作，而OLAP 應用程序通常只有讀取操作。每種應用程序都有管理挑戰，都施加了不同的 DBA 程序與需求。 ● 波動性。數據庫變更需求的頻率是需要額外的DBA 與否的重要因素。一個很少需要 變更的靜態數據庫環境，與一個不穩定的、經常變更的數據庫環境需要DBA 付出的 努力是不同的。遺憾的是，大多數據庫和應用程序波動性水平往往會隨著時間的推移發生巨大的變化。很難確定整體的數據庫環境將在其生命周期內如何波動。 ● DBA 人員的經驗。現有DBA 人員的技能將對是否還需要額外的DBA 產生影響。一 名技術嫻熟的DBA 人員能夠做到的要比一個新手團隊多。且技能比經驗更能決定所 需要的DBA 人員的水平。一名有兩年工作經驗的、非常積極的DBA 可能輕松超過 一名具有十年工作經驗卻筋疲力盡、無心工作的老手。 ● 開發人員的經驗。從事數據庫和SQL 編程的開發人員越不熟練，在開發過程、執行 復雜的SQL 任務、分析、調試、調優、確保連接性中需要DBA人員介入的就越多。 隨著開發人員經驗的增加，DBA 工作的復雜性也相應減少。 ● 終端用戶經驗。當終端用戶試圖通過隨機SQL 語句直接訪問數據庫時，他們的技能 水平將直接影響 DBA 工作的復雜性。 ● DBA 工具。DBMS 供應商和為數不少的ISV 都提供自動執行DBA 任務的工具，從 而使得管理數據庫變得更容易。工具的可用性越高且介入度越深，DBA 的工作將會 變得越簡單。行業分析師預估一旦沒有了 DBA 工具，DBA 的需求量將兩倍于現在的 數目。 盡管羅列了以上復雜的問題，但要想把所有這些因素都合并成一個公式而得出需要雇傭 的 DBA 最佳數量還是非常困難的。盡管研究或許有些過時，但 META 集團 的行業分析師還是創造了一個寬松的公式計算DBA 努力的水平（Level of Effort，LOE）。公式并不嚴謹，但是通過六種因素得出 DBA LOE ：系統復雜性、應用程序不成熟度、終端用戶水平參差不齊、 軟件功能、系統可用性和人員不成熟度。通過盡可能地評估表示每種因素高或低的分值，將這些值代入公式得出一個數字，再將該數字轉換成所需的 DBA 數量的預估。 * * * * * P28