DB2 數據庫分區是 DB2 企業版 DPF(Data Partitioning Feature)選件提供的，它主要用來為大規模數據處理、高並發數據訪問提供支持。DB2 數據庫分區采用 Share-nothing 體系結構，數據庫在一個非共享的環境中被分解為獨立的分區，每個分區都具有自己的資源，例如內存，CPU 和磁盤以及自己的數據、索引、配置文件和事務日志。數據庫分區有時稱為節點或數據庫節點。如下圖所示：
圖 1. DB2 數據庫分區示例圖
數據通過 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 操作都可以通過上述的並行處理能力來顯著提高其性能。如下圖所示：
圖 2. DB2 數據庫分區並行處理示例圖
為什麼采用數據庫分區
采用數據庫分區，可以為您帶來如下好處：
查詢擴展性
這是采用數據庫分區最主要的原因之一。將一個大的數據庫分成多個小的數據庫可以提高查詢的性能，因為每個數據庫分區擁有自己的一小部分數據。假設您想掃描1億條記錄，對一個單一分區的數據庫來講，該掃描操作需要數據庫管理器獨立掃描一億條記錄，如果您將數據庫系統做成50個分區，並將這1億條記錄平均分配到這50個分區上，那麼每個數據庫分區的數據庫管理器將只掃描200萬記錄。
架構限制
在DB2 V8和以前版本，非分區數據庫的最大的表取決於頁面大小，4K頁最大支持64 GB，32K頁最大支持512 GB數據量。表和表空間大小限制是每個分區上的限制，因此將數據庫分成N個分區可以將表的最大尺寸增加為單個分區表最大尺寸的N倍。內存也可能是個限制，特別是在32為操作系統環境，因為每個數據庫分區管理並擁有自己的資源，因此通過數據庫分區可以克服這個限制。
數據庫裝載性能
數據庫分區可以並行裝載數據到所有數據庫分區，極大減少單表的裝載時間，這對於像實時商業智能系統那樣對數據裝載的時間要求特別高的系統特別重要。
數據庫維護性能
將數據庫分散到多個數據庫分區服務器可以加快系統維護，因為每個操作都運行在分區所管理的一個數據子集上面，這樣可以通過數據庫分區進一步減少創建索引的時間，減少搜集統計信息的時間，因為runstats僅運行在一個數據庫分區上面，減少表重整(reorg)的時間。
備份/恢復性能
將數據庫分區到不同的數據庫服務器上可以大大減少數據庫備份的時間，這往往是決定是否使用數據庫分區很重要的一點。DB2 通過為每個表空間分配獨立的進程或線程來實現備份和恢復操作的並行處理的。在分區數據庫環境的備份中，每個分區的備份是獨立的，通過並行備份數據庫分區可以大大減少備份整個數據庫的時間。
日志
在高度活動的系統中，數據庫日志的性能可能會限制系統的整體吞吐量。在分區數據庫環境中，每個分區有自己一套日志。當大量插入、更新、刪除操作時，多個數據庫分區可以提高性能，因為日志是在每個數據庫分區上是並行寫的，且每個單一的分區需要記錄的日志更少。
DB2 隨數據量或處理器和分區的增加，提供近線性的擴展能力，可是，數據庫分區是否提供最多的益處依賴於處理的工作負荷、最大表的大小及其他因素。
什麼時候采用數據庫分區
設計數據庫分區的基本原則是，盡量將大表分布在所有的分區上，提高並行處理能力;將小表放置在盡量少的分區上，一般是建議放在單一分區上;盡量減少分區間的通信。對於是否采用數據庫分區，除了考慮上一節提到的分區的優勢之外，我們也要根據分區設計原則來考慮：
選擇數據庫分區的一個比較理想的場景是執行一條像 ” select count(*) from big_table”這樣的語句。如果將這個表放在所有分區上，則每個分區都可以計算該表在其上的行數，並將這個局部總數(subtotal)發送到協調分區，以便計算總和，而這裡的通信成本比起每個分區上所做的工作來可以忽略不計。
另一個非常合適的場景是， 一個大表與幾個非常小的很少更新的表相連接。大表是分區的，小表則被復制到每個分區上，這樣就可以並置連接。
不適合使用分區的是那些在連接時涉及很多大表和各種各樣的表和列的 ad hoc 查詢環境。在那些情況下， 很難或者不可能選擇表的分區鍵，使得所有大的查詢執行起來沒有很多的分區間通信。
同樣不適合使用分區的是那些有多條不能在單個分區內處理的非常小的語句。在這種情況下，分區間通信的開銷比起這些語句的本地執行來就相當高，而如果使用分區的話(尤其是跨多個物理系統)，響應時間就會大大惡化。
大多數工作負載和一些特定的任務都處於剛才討論的這兩種極端之間，這些地方都需要通過原型來研究使用分區所帶來的影響。
DB2 數據庫分區是 DB2 企業版 DPF(Data Partitioning Feature)選件提供的，它主要用來為大規模數據處理、高並發數據訪問提供支持。DB2 數據庫分區采用 Share-nothing 體系結構，數據庫在一個非共享的環境中被分解為獨立的分區，每個分區都具有自己的資源，例如內存，CPU 和磁盤以及自己的數據、索引、配置文件和事務日志。數據庫分區有時稱為節點或數據庫節點。如下圖所示：
圖 1. DB2 數據庫分區示例圖
數據通過 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 操作都可以通過上述的並行處理能力來顯著提高其性能。如下圖所示：
圖 2. DB2 數據庫分區並行處理示例圖
為什麼采用數據庫分區
采用數據庫分區，可以為您帶來如下好處：
查詢擴展性
這是采用數據庫分區最主要的原因之一。將一個大的數據庫分成多個小的數據庫可以提高查詢的性能，因為每個數據庫分區擁有自己的一小部分數據。假設您想掃描1億條記錄，對一個單一分區的數據庫來講，該掃描操作需要數據庫管理器獨立掃描一億條記錄，如果您將數據庫系統做成50個分區，並將這1億條記錄平均分配到這50個分區上，那麼每個數據庫分區的數據庫管理器將只掃描200萬記錄。
架構限制
在DB2 V8和以前版本，非分區數據庫的最大的表取決於頁面大小，4K頁最大支持64 GB，32K頁最大支持512 GB數據量。表和表空間大小限制是每個分區上的限制，因此將數據庫分成N個分區可以將表的最大尺寸增加為單個分區表最大尺寸的N倍。內存也可能是個限制，特別是在32為操作系統環境，因為每個數據庫分區管理並擁有自己的資源，因此通過數據庫分區可以克服這個限制。
數據庫裝載性能
數據庫分區可以並行裝載數據到所有數據庫分區，極大減少單表的裝載時間，這對於像實時商業智能系統那樣對數據裝載的時間要求特別高的系統特別重要。
數據庫維護性能
將數據庫分散到多個數據庫分區服務器可以加快系統維護，因為每個操作都運行在分區所管理的一個數據子集上面，這樣可以通過數據庫分區進一步減少創建索引的時間，減少搜集統計信息的時間，因為runstats僅運行在一個數據庫分區上面，減少表重整(reorg)的時間。
備份/恢復性能
將數據庫分區到不同的數據庫服務器上可以大大減少數據庫備份的時間，這往往是決定是否使用數據庫分區很重要的一點。DB2 通過為每個表空間分配獨立的進程或線程來實現備份和恢復操作的並行處理的。在分區數據庫環境的備份中，每個分區的備份是獨立的，通過並行備份數據庫分區可以大大減少備份整個數據庫的時間。
日志
在高度活動的系統中，數據庫日志的性能可能會限制系統的整體吞吐量。在分區數據庫環境中，每個分區有自己一套日志。當大量插入、更新、刪除操作時，多個數據庫分區可以提高性能，因為日志是在每個數據庫分區上是並行寫的，且每個單一的分區需要記錄的日志更少。
DB2 隨數據量或處理器和分區的增加，提供近線性的擴展能力，可是，數據庫分區是否提供最多的益處依賴於處理的工作負荷、最大表的大小及其他因素。
什麼時候采用數據庫分區
設計數據庫分區的基本原則是，盡量將大表分布在所有的分區上，提高並行處理能力;將小表放置在盡量少的分區上，一般是建議放在單一分區上;盡量減少分區間的通信。對於是否采用數據庫分區，除了考慮上一節提到的分區的優勢之外，我們也要根據分區設計原則來考慮：
選擇數據庫分區的一個比較理想的場景是執行一條像 ” select count(*) from big_table”這樣的語句。如果將這個表放在所有分區上，則每個分區都可以計算該表在其上的行數，並將這個局部總數(subtotal)發送到協調分區，以便計算總和，而這裡的通信成本比起每個分區上所做的工作來可以忽略不計。
另一個非常合適的場景是， 一個大表與幾個非常小的很少更新的表相連接。大表是分區的，小表則被復制到每個分區上，這樣就可以並置連接。
不適合使用分區的是那些在連接時涉及很多大表和各種各樣的表和列的 ad hoc 查詢環境。在那些情況下， 很難或者不可能選擇表的分區鍵，使得所有大的查詢執行起來沒有很多的分區間通信。
同樣不適合使用分區的是那些有多條不能在單個分區內處理的非常小的語句。在這種情況下，分區間通信的開銷比起這些語句的本地執行來就相當高，而如果使用分區的話(尤其是跨多個物理系統)，響應時間就會大大惡化。
大多數工作負載和一些特定的任務都處於剛才討論的這兩種極端之間，這些地方都需要通過原型來研究使用分區所帶來的影響。
數據庫分區實現
下邊，我們以 IBM InfoSphere Balanced Warehouse E7100 為例，介紹一下DB2 分區數據庫在AIX下的基本管理方法及應用實踐。DB2 分區數據庫在 Windows 環境下的管理方法和 AIX 略有不同，具體請參閱相關手冊。
IBM InfoSphere Balanced Warehouse 是IBM針對客戶數據倉庫系統提出的一整套完整的解決方案。當用戶實施一個數據倉庫系統時，對用戶來說，一個非常大的挑戰就是未來的數據倉庫系統應該選擇什麼樣的服務器，服務器的配置是什麼，選擇多少台服務器;選擇什麼樣的存儲設備，存儲容量要多大，存儲設備配置是什麼;選擇什麼樣的網絡設備，它的配置是什麼才能保證系統性能高效、穩定。同時，隨著系統的應用，數據量會急劇增長，如何在保證系統性能的前提下，提供更好的系統擴展能力也是用戶非常關心的問題。為了解決上述問題，IBM 結合自己多年實施客戶數據倉庫系統的經驗，並協同IBM軟件部門、服務器部門、存儲部門及實驗室，共同推出了 InfoSphere Balanced Warehouse 解決方案，有時也稱為 BCU(Balanced Configuration Unit)。InfoSphere Balanced Warehouse 是一個包含服務器、存儲、數據倉庫軟件在內的完整解決方案，它基於 IBM 最佳實踐並得到充分驗證，是一個預先配置好的、可立即使用的解決方案，客戶無需靠猜測或假象去配置並驗證，實現開箱即用。InfoSphere Balanced Warehouse 采用平衡的理念，每個組件(數據庫、服務器和存儲)提供均衡的性能確保整體方案性能最優。同時，它采用可擴展的模塊化設計，數據倉庫系統在整個生命周期中，可以以增量的方式進行擴展，達到的性能可預見、可度量。
InfoSphere Balanced Warehouse主要由以下幾個模塊組成：如下圖：
圖 3. InfoSphere Balanced Warehouse 模塊組成
Foundation Module: 有時也稱為 administration BCU。該模塊主要包括編目分區、協調分區以及單分區表。系統必須要有 1 個 Foundation Module。
Data Module: 有時也稱為 data BCU。該模塊主要保存分區表數據。根據數據量，可以有 1 個或多個 Data Module。
User Module: 如果系統有大量用戶訪問，我們可以考慮增加 User Module。
Failover Module: 用於滿足 HA 的需求。
Application Module: 用於運行應用程序，比如說 ETL 應用就可以配置在 Application Module 上。
本次配置環境包括一個 administration BCU 和 2 個 data BCU，如下圖所示：
圖 4. InfoSphere Balanced Warehouse 配置圖
創建實例及配置通信連接
使用db2icrt命令創建實例
/opt/IBM/db2/V9.1/instance/db2icrt -u bcufenc bcuaix
配置TCPIP通信服務
db2set DB2COMM=tcpip
修改DBM CFG 中的 SVCENAME參數
db2 update dbm config using svcename xbcuaix
在實例級禁用fault monitor
db2fm -i instance_name -f no
創建診斷文件目錄
缺省的情況下，db2diag.log 文件創建在 ~/sqllib/db2dump 目錄下，這個目錄是 NFS-mounted，我們一般建議要將 db2diag.log 文件放在非 NFS-mounted 目錄下。在 E7100 實施中，我們建議將該文件放到外部的存儲上。
Administration BCU:
mkdir -p /db2path/bcuaix/NODE0000/SQL00001/db2dump
Data BCU 1:
mkdir -p /db2path/bcuaix/NODE0001/SQL00001/db2dump
Data BCU 2:
mkdir -p /db2path/bcuaix/NODE0009/SQL00001/db2dump
Administration BCU:
ln -s /db2path/bcuaix/NODE0000/SQL00001/db2dump /db2path/bcuaix/db2dump
Data BCU 1:
ln -s /db2path/bcuaix/NODE0001/SQL00001/db2dump /db2path/bcuaix/db2dump
Data BCU 2:
ln -s /db2path/bcuaix/NODE0009/SQL00001/db2dump /db2path/bcuaix/db2dump
db2 update dbm config using diagpath /db2path/bcuaix/db2dump
定義數據庫分區
在數據庫分區環境下，數據庫被分為多個分區，分區之間彼此獨立工作，實現並行操作。數據庫分區可以是物理分區也可以是邏輯分區。在一台物理機器上部署的一個分區，我們稱為物理分區，如果是在一台 SMP 機器上部署多個分區，這些分區我們稱為邏輯分區。我們可以選擇物理分區，也可以選擇邏輯分區。通常，如果決定采用大的 SMP 機器，有更多的 CPU、內存及硬盤，我們會采用邏輯分區;如果決定采用多台物理機器，我們會通過非共享的體系結構采用物理分區;如果決定采用多台 SMP 機器，我們則會采用物理分區和邏輯分區結合的方式。
