DB2資料庫設計和最高效能原則

這篇文章的目的是為了給IBM(r)商業夥伴提供一些重要的資訊，這些資訊是關於DB2通用資料庫（UDB）在z/OS(r) 環境下（以下簡稱DB2）DB2(r)資料庫效能方面的。本文試圖將來自多方資源的材料進行整合，然後盡量有效地將資訊展示出來。本文盡量避免在範圍上過於寬泛，以及過於深入細節。下面，我將要討論那些最頻繁影響DB2資料庫效能的因素。我在這裡並不涉及所有可能的條件和所有潛在的考慮，而是只局限於預期的範圍之內。我希望這篇文章能夠對DB2客戶有一個總體的指導，從而使它們自己的環境中去獲得DB2資料庫的最適宜的效能。這篇文章將從如何在一個特定的安裝中定製資料庫的效能開始談起。

這篇文章所涉及的範圍是資料庫設計效能。而DB2的效能包括的內容比這要多得多，除了資料庫的設計之外，實際上還有很多其他的影響因素。例如，程式的編碼邏輯，實際使用的SQL語句，都被劃分在應用程式設計範圍內了。影響DB2系統效能的因素包括了例如安裝選項、緩衝池規模、DB2相關的地址空間的分配優先順序等。本文的重點在於DB2資料庫的設計。但是有些時候，這些影響效能的因素分類之間的界限有些模糊。例如，安裝過程中對緩衝池的規模，選用緩衝池的數量進行的配置一般都被認為是系統效能因素。但是，當分配特定的資料表空間和那些緩衝池的索引的時候，就被認為是資料庫設計所要考慮的了。

假設讀者已經對z/OS環境下的DB2有了一些基本的瞭解。本文的前幾頁討論了一些關於效能管理的基本概念和原則，以便於後面的理解。我的建議在本質上有些籠統，我總是避免過於糾纏技術細節或者文法等方面的問題。想要獲得關於這些問題的詳細資料，你可以查看IBM最近發布的有關安裝在用戶端的DB2的文檔。

這篇文檔主要著眼於z/OS V7環境下的DB2。雖然在z/OS V8下的DB2已經發布了，並且具有通用性，但是很可能還需要幾個月的時間，IBM 的大多數客戶才能夠讓他們的產品系統實現DB2 V8 NFM（新功能模式）。這裡還有另一個需要考慮的問題：雖然每個新發布的DB2在正式通用之前，都會在IBM和客戶環境中進行相當充分的測試，但是客戶仍然很可能對基於前一版本的有關DB2的常見推薦和單憑經驗的方法懷有更多的信心，而不是非常認同還沒有發布，或者是沒有獲得普遍使用的新版本（由於驗證結論的實際過程的時間長度和深度）。我會在文中提到一些可能會影響資料庫設計效能的DB2 V8的新特性。

免責聲明：本文包含的資訊並沒有提交給任何正式的IBM測試，並按"AS IS"原則提供。本資訊的使用，或者是以上提到的任何技術的實現均由使用者負責，且依靠使用者的個人能力對其進行評估，並將其整合進入客戶特定的作業環境中。其中的每一項都將在IBM特定的條件下獲得精確的數值，這裡不保證在其他地方會出現同樣或者相似的結果。當使用者嘗試在各自的環境下採用上述技術時，需要自己承擔風險。

效能原則和方法學

考慮效能的時機

考慮應用程式和資料庫各自不同的效能特徵的時間，是在對這些應用程式和資料庫進行設計的初始階段，即開發過程的一開始。對你的DB2應用程式和資料庫所需要的資源進行合理評估，將會協助使用者在開發過程的早期對設計和實現做出適當的決定。如果你的應用程式訪問資料庫的效能直到後來才被說明，那麼就要做必需的修改以獲得足夠的回應時間，並處理你的批處理視窗；這將會變得更加困難，並且消耗時間。

關注焦點

當設計效能的時候，將大部分的精力集中在重要的DB2資料和程式上是很明智的做法。對應用程式或者事務進行定義是這部分工作中的重點，以下一個或者多個特點是適用的：

它們表現了所有業務工作量中的大部分

它們有一個很關鍵的回應時間需求

它們包括了複雜的邏輯和/或資料訪問需求

它們訪問大量的資料

它們消耗大量的資源

它們直接與客戶進行互動（通過網路、ATM等），與此相反，應用程式大多面向公司內部

資料庫設計

資料庫設計發生在以下兩個階段：

資料庫邏輯設計

資料庫實體設計

資料庫的邏輯模型只是所有使用者資料需求規格化的形式表現。這個模型通常是資料建模階段的輸出或者是最終結果。它很少在實際意義上被實現。更何況，在考慮如何在資料庫管理系統中實際地組織和儲存資料之前，它只是資料的一個理想化的視圖。

當考慮到特定資料庫物件的體繫結構的時候，邏輯模型才會轉化為物理模型。在這一設計階段，才需要考慮到資料訪問需求和效能因素的一些細節。在進行實體設計的過程中，兩個關鍵的因素是表設計和索引設計。這兩個問題將會在下面進行詳細討論。

DB2效能管理的方式

為了確保你的DB2應用程式有足夠的效能，採取積極的態度總比消極應對有意義得多。在DB2資料庫設計的早期階段總結出效能因素是至關重要的。然後在項目中，努力儘早地確定滿足你的服務等級協定（SLA）的效能“基準”的測量標準，這樣你就可以在首次示範和應用程式變更的時候追蹤效能特點及其發展趨勢。不斷地監測你的DB2系統和應用程式，以便在大多數的問題成形之前預見到它們。

傳統意義上，許多客戶都是直到應用程式開發項目的最後階段才開始關心效能問題。但是這樣的等待是毫無益處的。早在描述使用者介面和處理邏輯的階段就去思考資料庫設計的效能特點，是比較有好處的。例如，在你的重要的DB2工作（見前面所述）中，建立最好的索引的一個基本的指導就是對SQL語句中的謂詞的考慮。

即使是你開發出的最初設計是一個有效設計，但是以下的若干修改仍然是必要的，例如對你的應用程式進行修改，或者資料庫以卷的形式增長，或者是限制系統資源。如果現有的應用程式沒有充分的運行，那麼通常情況下你都會希望最好能夠在現有的索引上面添加更多的列，或者在表上添加新的索引。不論改變表的設計，或者修改客戶的需求，還是使表非標準化，通常情況下都不是好的選擇。