概要介紹
今天，不管是出於戰略考慮還是因為財務原因，許多公司正在將多個單獨的數據服務器固化到一個共享數據服務器上。每個新的數據服務器出現時，它都有可能向這個帶有不同系統交互的混合體添加一個非常不同的工作負載類型。這個固化的服務器現在必須支持各種不同的並發工作負載。良好的工作負載管理實踐對實現這種環境中的業務承諾至關重要。
當您的數據庫系統遇到由於在該系統上執行的不同的（有時是矛盾的）資源需求所導致的性能下降時，那麼您需要 DB2 工作負載管理器來幫助您阻止、探測和解決這些沖突。
本文向您介紹目前針對您的 DB2 Version 9.5 for Linux, UNIX, and Windows 數據服務器上的 DB2 工作負載管理器的最佳實踐，這些最佳實踐可以用於幫助您實現在 DB2 數據服務器上執行的工作的業務目標。這裡介紹的最佳實踐的依據是基准測試和概念證明中的 IBM 領域體驗和來自采用 DB2 Version 9.5 的客戶的反饋。
本文涵蓋以下領域的最佳實踐：
設計領域的最佳實踐
實現領域的最佳實踐
監控領域的最佳實踐
本文附錄還提供以下參考資源和指南：
展示如何在數據倉庫環境中使用 IBM 工作負載管理器滿足業務優先權的一個特定場景；
對 CPU 使用實施最大硬性限制時在 AIX® Workload Manager 中用來實現動態處理器分配的一個示例腳本；
關於如何從 Query Patroller 和 DB2 Governor 升級的指南。
如果您已經熟悉 DB2 工作負載管理的一些基本概念，那麼您能夠更好地利用本文。如果您想先閱讀一些背景信息，那麼請您參閱本文末尾推薦的參考資源。
最佳實踐：設計
工作負載管理背後的工作原理總是相同的：
理解需要在您的數據服務器上運行的工作及其如何與您的業務目標相關聯。
確定您的系統是否可以運行這個工作而沒有任何限制；您在任何時段執行的工作量必須是您的系統能夠處理的工作量。
在需要時對系統上運行的工作采取“分而治之” 的方法，以便根據工作的業務優先權執行它們，同時避免超出您的系統的處理能力。
本小節討論有關任何工作負載管理實現中的調查和設計部分的當前最佳實踐。
理解現有系統
這些原理適用於正准備發布到生產中的數據庫，其適用程度與已經得到部署的數據庫相同。現有系統的優勢在於它們能夠被監控和挖掘，以便幫助您理解將要在目標系統上運行的工作。
理解將要在您的數據庫上運行的工作對設計適當的工作負載管理實現很關鍵，這些信息告訴您將遇到什麼類型的爭用和交互，這反過來幫助您確定應該關注 DB2 工作負載管理的哪些特性和功能。要更好地理解可用的信息類型，請參見“DB2 最佳實踐 : 性能調優和問題診斷最佳實踐”。
要收集關於在現有 DB2 系統上運行的工作的信息，利用新的監控功能（如本文監控部分所述）從默認 DB2 工作負載和 DB2 V9.5 安裝後立即可用的用戶服務類收集信息。
如果您在現有系統上使用 Query Patroller (QP) ，可以首先通過使用存儲在 QP 控制表中的信息尋求答案。這些表顯示正在提交的工作的類型和來源。
向數據庫工作分配業務優先權
與知道將要執行什麼工作一樣重要的是要知道工作的業務優先權和系統上的其他工作如何相關聯，該工作有什麼性能目標（如果有的話），這些業務優先權如何映射到已提交的數據庫請求。有時，業務優先權（或預期）的表達方式為一個正式的服務級別協議（SLA ）；有時，優先權完全不可知，或者以非常隨意的比較詞匯表達（如應用程序 A 比應用程序 B 更重要）。
首先將應用程序映射到業務優先權：談到業務優先權，很容易想到一個簡單的分類系統，比如高、中、低優先權。然後您開始檢查提交工作並將它們按照優先權級別分類的不同業務流程。有些業務流程中包含多個級別和路徑，並不是所有的級別和路徑都共享針對主流程的相同的高級別分類。例如，一個高優先權在線應用程序可能擁有一些輔助報告或維護路徑，它們不與主應用程序共享相同的高優先權。應用程序通過業務流程被惟一標識的程度在很大程度上決定您是使用直接映射到一個應用程序的簡單業務優先權映射，還是必須分析由一個應用程序提交的請求來將不同的優先權分配給那些請求。
業務優先權通過擁有一個為每個不同的業務優先權類定義的 DB2 服務類很好地反映出來。服務類是數據庫工作實際執行的地方，也是控制分配給該工作的優先權的最好位置。為傳入的工作分配業務優先權，即將傳入的工作分配給不同 DB2 服務類，最好使用 DB2 工作負載定義和 DB2 工作負載操作集完成。
在您可以將業務優先權直接應用到一個特定應用程序提交的工作的情況下，將工作負載映射到反映分配到該應用程序的業務優先權的 DB2 服務類。要映射工作負載，創建一個 DB2 工作負載以表示該應用程序產生的連接，將該工作負載直接指向表示針對該應用程序的適當的業務優先權的 DB2 服務類。
在其他情況下，比如處理一些中間件應用程序時，您可能無法將一個業務優先權分配給一個特定的應用程序，因為該應用程序同時服務多個優先權不同的流程，而且並不是總能區分接受服務的不同用戶。在這些情況下，檢查正在提交的單個請求，並使用一種可行技術將業務優先權應用到每個流程（或用戶）。可以通過將那些請求導向適當的 DB2 服務類來在單一的請求級別映射業務優先性，最好的實現方法是使用可作為 DB2 工作操作集機制的一部分的映射機制（因為它在 DB2 服務超類中使用）。
一種映射業務優先性的替代方法：如果您沒有適當的關於正提交到數據庫的工作的信息級別，您可以選擇使用一種替代方法將業務優先性映射到數據庫工作。從一個純粹的數據庫角度著手處理優先性分配問題。為此，使用一個 “短 - 中 - 長” 分類系統，根據服務器上的預期影響（或生命期）對工作分類。在這個系統中，您將短期請求視為最重要的請求，長期請求視為最不重要的請求。這個模式的想法是：可以穿過您的系統的短期查詢越多，向整個企業提供的服務也就越好。換句話說，這裡的原理是：作為一個整體，系統稍微降低長時間查詢的運行速度要好於短時間查詢遭受性能下降。
但是，即使在這種模式中，相同的問題也會出現。一個應用程序只提交一個請求類的程度決定您是使用簡單映射還是必須基於具體情況對請求分類。同樣，確定已提交工作的相對影響的方法將在您選擇的工作負載管理機制中反映。一個只提交一種類型工作的應用程序可以通過使用普通的 DB2 工作負載到 DB2 服務類的映射機制直接映射到一個針對該類工作的服務類。同樣，對工作的分類和根據請求的既定影響將單個請求映射到適當的 DB2 服務類也最好使用 DB2 工作操作集映射機制實現。
顯然，將這兩個分類系統組合在一起是可能的，就像組合任意數量的其他系統一樣。可以得出的關鍵結論是，不管使用哪種分類系統，單獨的應用程序和正在使用的業務優先權分類系統之間的匹配程度決定哪一種 DB2 工作負載管理機制能夠最好地告知數據庫優先權。
利用您的經驗
如果您有一個現有系統，那麼您就擁有關於系統如何運行和系統以前經歷的問題的重要知識。您對導致這些困難的根本原因了解得越少，那麼您在實現一個新的工作負載管理方法中就越被動。如果是這樣，計劃一個良好的初始實現（如下一節將介紹的）並計劃多次重復監控和調優，直到系統變得穩定和可控。
另外，利用您的經驗確保您的系統上的所有活動因素都受到考慮。將系統視為一個整體，只使用 DB2 工作負載管理的功能並不會解決所有問題。考慮您可以使用的所有 DB2 特性和功能。進行 DB2 工作負載管理時，可以且應該利用您的 DB2 數據服務器的其他特性和功能來確保您的性能目標得以滿足。
一個可預測的、穩定的數據服務器需要滿足以下條件：
良好的邏輯和物理設計。參閱以下文檔了解更多信息：
“DB2 最佳實踐 : 物理數據庫設計最佳實踐”和 Balanced Warehouse 文檔
“DB2 最佳實踐 : 性能調優和問題診斷最佳實踐”
調優以產生最佳性能的查詢。
更多信息請參閱“DB2 最佳實踐 : 編寫並調試查詢語句以優化性能最佳實踐”
使用其他可以協助性能的特性，如自調優內存和實用程序節流（throttling ）。
您多年一直在使用的知識和工具並非突然變得無關緊要，它們只是需要與 DB2 工作負載管理中的新功能相協調。通過結合 DB2 工作負載管理和其他特性和功能，您就可以創建出穩定的、可預測的 DB2 數據服務器，這樣的服務器甚至在需求達到峰值時也能保持穩定的性能。
簡單開始並循序漸進
與其他新功能一樣，實現一個復雜的設計或同時進行許多不同的更改通常不是一個好主意。復雜性和劇烈變化通常會隱藏真正的問題，有時甚至還會引入新問題。
對於 DB2 工作負載管理的控制功能，從一個簡單的、直觀的實現開始，然後在此基礎上逐次添加改變。這種方法完全理解每次更改的影響並覺察到任何違背初衷的結果或交互。
而且，最好使任何控制（比如 DB2 阈值提供的控制）的關注范圍盡可能地狹窄，而不是全局應用它們。某些廣泛的數據庫級別阈值也許對於管理系統的全局行為比較理想，但是一般而言，使那些阈值只關注問題區域能夠確保您只看到預期的效果。通常，分配一個 DB2 阈值的最有效的地方是在一個 DB2 服務子類上。
最佳實踐：實現
這個部分提供當前實現 DB2 V9.5 中引入的 DB2 工作負載管理提供的每個功能的最佳實踐。
DB2 工作負載
一個 DB2 工作負載應該針對您感興趣的每個可能的工作源（即一個數據庫連接），無論它是一個應用程序、一個用戶、一個特定部門或其他任何東西。
引入新的工作負載定義不會產生性能影響，每個工作負載定義允許您監控或控制您的系統上傳入工作的一個特定部分。工作負載定義還允許您快速實現未來更改，因為您已經擁有現成的機制來識別您打算通過更改來影響的特定連接組。
中間件應用程序也許會產生一個識別問題，因為許多中間件使用相同的授權 ID 和一致的連接信息與數據庫交互。這時，如果沒有其他信息，數據庫就不能識別這些請求後面的最終用戶。
通過使用可修改的客戶機信息字段（例如 CLIENT USERID 、CLIENT APPLNAME 、CLIENT WRKSTNNAME 和 CLIENT ACCTNG ）使中間件應用程序支持最終用戶應用程序的識別。這些字段可以被連接到 DB2 數據服務器的任何應用程序設置，設置方法是使用各種 DB2 客戶機連接選項或調用 WLM_SET_CLIENT_INFO 存儲過程。
最流行的中間件應用程序要麼提供設置客戶機信息字段的能力，要麼提供在處理期間將用戶提供的 SQL 注入策略位置的方法。這些字段提供一種明確識別將工作提交到 DB2 數據服務器的業務流程和組織的許多外部特征的方法。這些字段還能用於創建獨特的 DB2 工作負載定義。
客戶機信息在許多問題確定和監控場景中都非常有用，因此，重要的是要在您的業務中為這些字段建立一個標准格式和使用預期，以確保這些信息經過良好的重新組織並被目標人群理解。
如果沒有為感興趣的連接創建獨特的工作負載的能力，那麼您必須依賴工作操作集等機制來隔離並處理某個工作，該工作僅僅基於工作的實際特征（如 DML 或 DDL ，READ 或 WRITE 等）或成本估計被提交。這嚴重限制了未來的靈活性以及利用工作負載管理提供的細粒度監控功能的能力。
DB2 服務類
當您安裝 DB2 V9.5 時，一個默認用戶服務類將自動創建，這個默認用戶服務類是提交到數據庫的所有工作運行（通過將連接映射到同樣是在安裝時創建的默認工作負載定義）的地方。這是您的起點，您自動創建的任何其他 DB2 工作負載指向這個默認服務類，除非顯式指定了一個新的服務類。
本小節提供創建新的 DB2 服務類並將工作從默認服務類中拉出以便它能夠根據業務優先權被區別對待的推薦方法。您定義的每個 DB2 服務類為您提供了一個定義用於執行的資源優先權的控制點，以及對正在執行的工作進行輕量級監控的能力。反之，您定義的服務類越多，您的系統作為一個整體進行監控和控制時就更復雜。
在您的實現完成以後，您也許會選擇繼續使用默認服務類，將其作為處理未映射的和不重要的工作的地方。如果這樣，確定這樣的工作應該分配何種業務優先權並適當控制默認用戶服務類的資源以及您可能創建的其他資源。
如 “向數據庫工作分配業務優先權”小節所述，DB2 服務類是反映數據庫中的業務優先權的最好方法。這一過程通常通過實現一個相當直觀的分類系統來簡化，在這個分類系統中，對傳入的工作分配的服務類要麼表示為 HIGH 、MEDIUM 或 LOW 業務優先權，要麼表示為短期、中期或長期預期持續時間。
要實現一個 HIGH 、MEDIUM 或 LOW 業務優先權分類系統，創建一個 DB2 服務超類並在該超類中創建其他兩個服務子類。
每個這些服務類表示一個不同的業務優先權，其中超類的默認子類也是提交到該超類的任何未映射工作的默認位置。根據您想要處理這類工作的方式，您很可能分配這個默認子類以表示工作的 LOW 或 MEDIUM 優先權類別。本文中的示例實現將 LOW 類別分配給為該超類創建的默認子類，將 MEDIUM 和 HIGH 類別分配給兩個顯式創建的子類。參見示例“圖 1. 推薦的服務類實現”。
圖 1. 推薦的服務類實現
圖片說明：
Service Superclass A：服務超類 A
Default subclass: LOW priority：默認子類：LOW 優先權
Subclass A2: MEDIUM priority：子類 A2：MEDIUM 優先權
Subclass A1: HIGH priority：子類 A1：HIGH 優先權
每個這些不同的服務類的資源可以反映出相對優先權，具體方法是將服務類屬性設置為反映對應優先權的值 1，例如，LOW 業務優先權服務子類能夠獲取 LOW 預取優先權和一個較低的相對處理器優先權設置，而 HIGH 業務優先權子類能夠獲取一個 HIGH 預取優先權和一個較高的相對處理器優先權）。一般而言，首先使用 MEDIUM 業務優先權類反映超類的原始默認（即未經修改的）設置，因為這是 DB2 數據庫中常見的執行設置。
不要將任何服務類的服務類處理器優先權設置得比 DB2 默認系統服務類的高，設置方法為要麼直接使用處理器優先權屬性，要麼通過 AIX Workload Manager 集成間接設置。
這種方法中的默認行為如下：由一個 DB2 工作負載映射到服務超類 A 的任何事物在默認子類中執行並采用 LOW 優先權設置。為了獲取不同的優先權設置，傳入的工作要麼使用一個 DB2 工作操作集映射到其他服務子類，要麼直接映射到理想的服務子類。參見 “圖 2. 分配工作到不同的服務子類的示例”。
圖 2. 分配工作到不同的服務子類的示例
圖片說明：
Service Superclass A ：服務超類 A
Priority assigned by work type ：按照工作類型分配的優先權
Priority assigned by workload ：按照工作負載分配的優先權
Work Action Set ：工作操作集
Default subclass: LOW priority ：默認子類：LOW 優先權
Subclass A2: MEDIUM priority ：子類 A2 ：MEDIUM 優先權
Subclass A1: HIGH priority ：子類 A1 ：HIGH 優先權
默認服務子類被賦予最低的或中等的優先權，因為只要 DB2 工作負載被映射到超類，沒有在應用到該超類的一個 DB2 工作操作集中識別的或重新映射的任何工作將自動被賦予最低（或中等）優先權 2 。通常，高優先權為特殊工作預留，而不是用於提交到數據庫的普通日常工作。您還可以將傳入的工作直接映射到一個子類本身，以便向那個工作分配該優先權；通過這樣做，該工作將繞過超類上的任何 DB2 工作操作集。請注意，您不能直接分配一個工作負載到默認子類，這應該在決定哪個子類將表示哪個業務優先權時考慮。
您可以使用這個推薦方法作為模板，將其用於管理您的數據庫上的工作的整體方法（即數據庫上的所有工作都在一個超類中處理），或者用於更多樣化的方法，其中不同的工作組使用不同的方法管理（例如，一個工作組使用業務優先權管理，另一個工作組使用預期持續時間管理）。
一旦您已經設置 DB2 服務類和工作負載來反映您想要的工作處理方式，通過運行已知的工作負載並比較每個工作負載和服務類的不同請求和行為計數來驗證您的實現，確保事情按預期發展。您也可以使用這個時間來測試這個處理模式上的實現的效果。您可以通過兩種方法來驗證這一點：一是使用 WLM 表功能來直接詢問 DB2 ，二是使用 WLM 統計數據事件監控器將不同 WLM 對象的統計數據收集到一個表以備未來分析之用。
圖 3. 一個完整的數據庫實現示例
圖片說明：
User database requests ：用戶數據庫請求
System database requests ：系統數據庫請求
Workload ：工作負載
Default workload ：默認工作負載
Superclass ：超類
Default User Service Class ：默認用戶服務類
Default System Service Class ：默認系統服務類集成 AIX Workload Manager 服務類
集成 AIX Workload Manager 服務類
如果您正在 AIX 操作系統上運行 DB2 V9.5 ，您可以集成 DB2 服務類和補充的 AIX Workload Manager (WLM) 服務類。這樣做允許您利用 AIX WLM 提供的本機控制和監控功能。
AIX WLM 提供許多控制處理器的方法，您必須通過試驗了解哪一種方法（如果有的話）更適合您。需要記住的關鍵點是：AIX WLM 處理器控制機制（例外情況是最大硬性限制）運行的前提是僅當處理器循環處於高峰期時才需要限制低優先權工作。當處理器不受限制時，多數 AIX WLM 控制機制沒有什麼效果。反之，處理器的利用率越高，這些控制機制發揮的作用越大。
在 AIX 系統上控制處理器使用的推薦方法：為實現處理器控制目標而與 AIX Workload Manager 集成時，使用有關處理器使用的最大硬性限制，除非在您想要控制生效的時候您的系統總是受到嚴重的處理器限制。
處理器使用上的最大硬性限制 嚴格控制處理器使用，不管處理器利用程度如何。低優先權工作負載總是受到控制，這樣高優先權工作將受益，即使是在沒有處理器限制的環境中。我們的 AIX WLM 測試和基准測試經驗都證明了這一點。
