此文章主要向大家講述的是DB2 9.5分區管理以及其應用實踐，以及對為什麼采用數據庫分區，並且以 Balanced Warehouse E7100 為例對數據庫分區管理的基本方法及應用實踐進行介紹。
DB2數據庫分區是 DB2企業版 DPF(Data Partitioning Feature)選件提供的，它主要用來為大規模數據處理、高並發數據訪問提供支持。DB2數據庫分區采用 Share-nothing 體系結構，數據庫在一個非共享的環境中被分解為獨立的分區，每個分區都具有自己的資源，例如內存，CPU 和磁盤以及自己的數據、索引、配置文件和事務日志。數據庫分區有時稱為節點或數據庫節點。
數據通過 Hash 算法均允地散列到不同的分區內，每個分區只負責處理自己的數據。當用戶發出 SQL 操作後，被連接的分區被稱為 Coordinate Node，它負責處理用戶的請求，並根據 Partition key 將用戶的請求分解成多個子任務交由不同分區並行處理，最後將不同分區的執行結果經過匯總返回給用戶，分區對應用來說是透明的。
在 DB2中，數據庫分區可以部署在集群或 MPP 環境下，也就是說數據庫分區分布在不同的機器上;數據庫分區也可以部署在同一台 SMP 機器上，在同一台機器上的分區我們稱為邏輯分區。同時，我們還可以在集群或 MPP 環境下部署多個分區，在集群或 MPP 每一個節點上部署多個邏輯分區。
DB2數據庫分區提供了強大的可擴展能力。由於采用 Share-nothing 體系結構，每個分區(節點)只處理它那一部分數據，分區之間盡可能獨立，這就減少了節點間共享資源的爭用，允許數據庫有效地伸縮以支持更大的數據規模及更多的用戶訪問。DB2數據庫分區提供 scale up (垂直擴展)及 scale out (水平擴展)能力。
垂直擴展是通過增加機器的物理資源如 cpu、磁盤、內存來實現的;水平擴展是通過增加物理機器來實現的，DB2中，最多可以支持 1000 個分區。在規劃 DB2數據庫分區時，我們需要考慮是通過增加邏輯分區還是物理分區來實現擴展能力。
如果一台物理機器上有多個 CPU，其物理資源可以允許多個分區共享該資源，我們可以通過增加邏輯分區來實現擴展;如果一台物理機器上的物理資源不能滿足應用需求，我們就需要通過增加機器，也就是物理分區來實現擴展能力。
DB2數據庫分區還提供了強大的並行處理能力。首先，它提供了 inter-partition parallelism 分區間的並行機制，通過hash算法將數據庫請求分成多個任務在不同的分區上並行執行，同時，提供了 intra-partition parallelism 分區內的並行機制，將任務分解成不同的子任務，在不同的 CPU 上並行執行，另外，我們還可以同時利用 inter-partition parallelism、intra-partition parallelism 來實現完全的並行處理能力。DB2數據庫的查詢操作、backup/restore/load 等實用程序及 I/O 操作都可以通過上述的並行處理能力來顯著提高其性能。
為什麼采用數據庫分區
采用數據庫分區，可以為您帶來如下好處：
查詢擴展性
這是采用數據庫分區最主要的原因之一。將一個大的數據庫分成多個小的數據庫可以提高查詢的性能，因為每個數據庫分區擁有自己的一小部分數據。假設您想掃描1億條記錄，對一個單一分區的數據庫來講，該掃描操作需要數據庫管理器獨立掃描一億條記錄，如果您將數據庫系統做成50個分區，並將這1億條記錄平均分配到這50個分區上，那麼每個數據庫分區的數據庫管理器將只掃描200萬記錄。
架構限制
在DB2V8和以前版本，非分區數據庫的最大的表取決於頁面大小，4K頁最大支持64 GB，32K頁最大支持512 GB數據量。表和表空間大小限制是每個分區上的限制，因此將數據庫分成N個分區可以將表的最大尺寸增加為單個分區表最大尺寸的N倍。內存也可能是個限制，特別是在32為操作系統環境，因為每個數據庫DB2 9.5分區管理並擁有自己的資源，因此通過數據庫分區可以克服這個限制。
數據庫裝載性能
數據庫分區可以並行裝載數據到所有數據庫分區，極大減少單表的裝載時間，這對於像實時商業智能系統那樣對數據裝載的時間要求特別高的系統特別重要。
數據庫維護性能
將數據庫分散到多個數據庫分區服務器可以加快系統維護，因為每個操作都運行在分區所管理的一個數據子集上面，這樣可以通過數據庫分區進一步減少創建索引的時間，減少搜集統計信息的時間，因為runstats僅運行在一個數據庫分區上面，減少表重整(reorg)的時間。
備份/恢復性能
將數據庫分區到不同的數據庫服務器上可以大大減少數據庫備份的時間，這往往是決定是否使用數據庫分區很重要的一點。DB2通過為每個表空間分配獨立的進程或線程來實現備份和恢復操作的並行處理的。在分區數據庫環境的備份中，每個分區的備份是獨立的，通過並行備份數據庫分區可以大大減少備份整個數據庫的時間。
日志
在高度活動的系統中，數據庫日志的性能可能會限制系統的整體吞吐量。在分區數據庫環境中，每個分區有自己一套日志。當大量插入、更新、刪除操作時，多個數據庫分區可以提高性能，因為日志是在每個數據庫分區上是並行寫的，且每個單一的分區需要記錄的日志更少。
DB2隨數據量或處理器和分區的增加，提供近線性的擴展能力，可是，數據庫分區是否提供最多的益處依賴於處理的工作負荷、最大表的大小及其他因素。
什麼時候采用數據庫分區
設計數據庫分區的基本原則是，盡量將大表分布在所有的分區上，提高並行處理能力;將小表放置在盡量少的分區上，一般是建議放在單一分區上;盡量減少分區間的通信。對於是否采用數據庫分區，除了考慮上一節提到的分區的優勢之外，我們也要根據分區設計原則來考慮：
選擇數據庫分區的一個比較理想的場景是執行一條像 ” select count(*) from big_table”這樣的語句。如果將這個表放在所有分區上，則每個分區都可以計算該表在其上的行數，並將這個局部總數(subtotal)發送到協調分區，以便計算總和，而這裡的通信成本比起每個分區上所做的工作來可以忽略不計。
另一個非常合適的場景是， 一個大表與幾個非常小的很少更新的表相連接。大表是分區的，小表則被復制到每個分區上，這樣就可以並置連接。
不適合使用分區的是那些在連接時涉及很多大表和各種各樣的表和列的 ad hoc 查詢環境。在那些情況下， 很難或者不可能選擇表的分區鍵，使得所有大的查詢執行起來沒有很多的分區間通信。
同樣不適合使用分區的是那些有多條不能在單個分區內處理的非常小的語句。在這種情況下，分區間通信的開銷比起這些語句的本地執行來就相當高，而如果使用分區的話(尤其是跨多個物理系統)，響應時間就會大大惡化。
大多數工作負載和一些特定的任務都處於剛才討論的這兩種極端之間，這些地方都需要通過原型來研究使用分區所帶來的影響，以上的相關內容就是對DB2 9.5分區管理以及其應用實踐的介紹，望你能有所收獲。
