在開發過程的早期作出的很多設計決定對DB2應用程序和數據庫的性能有著巨大的影響。本文為在z/OS環境中取得更好的性能提供了一些一般性的指南和建議。
一、簡介
本文的目的是為IBM業務伙伴提供關於DB2 Universal Database?(UDB)for z/OS(後面將簡稱為 DB2)環境中DB2數據庫性能的重要信息。本文試圖從多處收集材料，並盡可能有效地將它們表述出來。本文無意包含很全面的范圍，也不會包含很深的細節。
我曾打算討論對DB2數據庫的性能影響最大的一些因素。但是，並不是所有可能的情形都可以預測到，也不是所有潛在的考慮都能顧及到，更不用說在期望的范圍內對它們進行描述了。我希望本文可以為不同環境下的DB2用戶提供一個通用的指南，以幫助他們取得最佳的DB2數據庫性能。本文的目的是成為一個良好的起點，用以處理任何給定安裝環境下的數據庫性能問題。
本文的范圍是數據庫設計性能。DB2性能遠不止這一部分，它肯定要受到數據庫設計以外的很多因素的影響。例如，程序的編碼邏輯和其中使用的實際的SQL語句，可以列為應用程序設計一類。DB2系統性能可以包括諸如安裝選項、緩沖池大小設置、DB2相關地址空間的調度優先級等等之類的因素。
本文的焦點是DB2數據庫的設計。不過，有時候這些性能因素類別之間的界線可能會有些模糊。例如，在某種安裝環境下進行配置時，緩沖池大小的設置和數量的選擇通常被認為是一項系統性能因素。但是，倘若是將特定的表空間和索引指派給那些緩沖池，那麼這些因素又可以看作是數據庫設計一類的因素了。
在這裡，我假設讀者對z/OS環境中的DB2有一個基本的理解。本文的頭幾頁將討論性能管理的一些基本概念和准則，以便進行“級別設置” 。我的建議有點綜合的性質，因而不會總是詳細地給出技術性的描述和語法。讀者如果想了解關於這些內容的更詳細的信息，那麼應該去閱讀關於用戶本地所安裝的DB2版本的最近的IBM文檔。
本文的通用設計點是DB2 for z/OS V7。雖然DB2 for z/OS V8已經被宣布，並且也普遍可用（generally available ，GA），但是大部分IBM客戶極有可能需要幾個月的時間才能實現用於他們的生產系統的DB2 V8 NFM（New Function Mode）。而且，這裡還要考慮另外一個因素。雖然DB2的每個新版本在變得普遍可用之前，都已經在IBM及其客戶環境下經過了廣泛的測試，但是相對於一個還沒有推廣的、沒有普遍使用的版本而言，客戶們往往對於基於早先版本的DB2的一般建議和竅門更有信心（長時間積累的經驗驗證了這一結論）。我將提到DB2 V8的一些新特性，從性能的角度來看，這些新性能可能會影響數據庫設計。 免責聲明：本文中所包含的信息未經任何正式的IBM測試，而是以AS IS的形式發布的。對這些信息的使用和其中任何技術的實現，都由用戶承擔責任，並取決於用戶的能力去評價它們和將它們整合到客戶特有的操作環境。雖然IBM對於每一項都進行了審查，以求特定情況下的正確性，但不能保證在其他情況下也能得到相同的或類似的結果。試圖將這些技術應用於他們自身環境的用戶須自己承擔風險。 二、性能准則和方法學
1. 何時考慮性能
考慮應用程序和數據庫的性能特性的時機是在那些應用程序和數據庫的初期設計階段，也就是開發過程的開始階段。對DB2應用程序和數據庫所需的資源進行合理的估計，這有助於用戶在開發過程的早期便對設計和實現作出恰當的決定。如果等到後期才來考慮訪問數據庫的應用程序的性能，那麼為了取得適當的響應時間和生成批處理窗口而進行一些必需的修改時，就會更加困難，而且更加消耗時間。
2. 應該關注些什麼
當從性能的角度進行設計時，將大部分的精力集中在重要DB2數據和程序上，這種做法比較明智。在確定是什麼應用程序或事務構成這一重要的工作負載時，以下特征中的一條或幾條將會適用：
1) 它們代表了總體業務工作負載的很大的百分比。
2) 它們有著關鍵響應時間需求。
3) 它們包括復雜的邏輯和/或數據訪問需求。
4) 它們訪問大量的數據。
5) 它們消耗大量的資源。
6) 與那些屬於公司內部的應用程序相比，它們是直接與客戶打交道的（通過 Web、ATM 等）。
3. 數據庫設計
數據庫的設計有兩個階段：
1) 邏輯數據庫設計
2) 物理數據庫設計
數據庫的邏輯模型僅僅是對用戶的所有數據需求的一種表示，它將這些需求變成一種范式。這種模型通常就是數據建模會議的輸出或最終結果。該模型實際上很少被原原本本地實現。其實，該模型只是在考慮如何實際地構造數據和將數據存儲在DBMS之前，對數據的一種理想化的看法。
在對數據庫對象的架構進行了考慮之後，邏輯模型就被轉化為物理模型。在設計的這個階段，就需要較為詳細地考慮數據訪問需求和性能因素。在產生物理設計的這個過程當中，有兩大要素，即表設計和索引設計。下面將較為詳細地討論這兩個話題。
4. DB2性能管理的方法
為了確保DB2應用程序具備合格的性能，未雨綢缪勝於亡羊補牢。在設計DB2數據庫的早期階段就將性能因素考慮進來，這一點很重要。然後，在項目盡可能早的時候，建立一套符合Service Level Agreement(SLA) 的性能“基准線”測量方法，這樣，便可以在展示的時候和應用程序被修改的時候，跟蹤性能特性和趨勢。同時還應該持續地監控DB2系統和應用程序，從而在大的問題完全發作之前進行預測。
通常，很多客戶只有到了應用程序開發項目的最後階段才開始擔心性能。但是通常沒有什麼好的理由需要等到那時才去考慮性能。更好的做法是，在指定了用戶界面和處理邏輯之後，立即考慮數據庫設計的性能特性。例如，在創建最佳索引時，應該將重要DB2工作（請參閱前面的討論）中SQL語句的謂詞作為主要指南。
即使您可以開發一個有效的初期設計，隨著數據量的增加，或者在系統資源緊缺的時候，也仍有必要對應用程序和/或數據庫作出修改。如果一個應用程序執行時的性能不合格，較為可取的做法通常是添加更多的列到現有的索引中，或者為一個表添加新的索引，這種做法是首選。而更改表的設計，或修改用戶需求，抑或修改反規范化（de-normalizing）表，都不是很有吸引力的選擇。 三、理解DB2性能
1. Rules-of-thumb
Rules of thumb（經驗法則，也稱ROT）在規劃、監控和優化DB2性能的時候很有用。ROT通常是基於以前的經驗（比如在一段時間內觀察到的平均值）或者更復雜公式的簡化。
記住這樣一個事實很重要，即ROT只對於粗略的估計有用，而對於詳細的分析用處不大。如果只是在某一類的文檔中看到了一些ROT，便欣然接受並作為精確的事實來引用，那麼就會有危險。在最好的情況下，這些ROT是一種估計，而在最壞的情況下，這些ROT對於特定的DB2環境可能不成立。
您應該為自己的環境特別開發這些ROT（或者對它們進行調節，以適應自己的環境的特性）。應確保ROT與實際經驗相關，而不是盲目地接受，這樣才能對它們更有信心。一開始的時候，使用那些在您特定環境以外被使用過或者被開發出來的ROT，這種做法可能有用。但是，當對您自己DB2系統中的適當數據進行收集、分析和編制文檔之後，應該對這些ROT加以驗證和修改。IBM Redbooks是關於ROT的一種很好的參考資料，這些ROT常常作為建議被包括在性能監控工具中。
另一方面的考慮是，ROT可能隨著時間的推移而演變。硬件技術的發展，軟件編程技術的提高，系統架構的變化，諸如此類的變化都可能使得ROT的可靠性降低，甚至變得無效。而使ROT隨著時間變化的最大因素也許正是DB2本身新版本的發行。
2. DB2工作負載
磁盤I/O常常是影響響應時間的最大因素，但是通過查看GETPAGE(GP)請求，更容易理解底層的性能問題。當監控DB2活動和分析報告時，GETPAGE的數量也許是DB2總體工作負載的最好的指示器。
某個安裝環境下的很多DB2工作都可以無異議地歸為以下幾類：
1) 事務：事務是在事務管理器（例如CICS和IMS/TM）控制下運行的程序。其中的SQL通常比較簡單，但是事務量比較重。事務必須為用戶提供極好的響應時間，這樣應用程序才不致於要長時間地等待它們所需的資源。通常，第一個調用事務的用戶將承受讀取索引和數據頁的成本。隨後的用戶則常常可以發現有些資源已經在緩沖池中。
2) 查詢：查詢也是程序，常常在需要決策支持時執行它。其中的SQL可能非常復雜，但是工作量常常遠不及事務。查詢的用戶常常要等上數分鐘甚至數小時，這取決於為了產生用戶所請求的結果集，需要對多少數據進行搜索。查詢常常要引起對整個表的掃描，而對結果排序是這種類型的工作負載的另一種常見特征。
3) 批處理和實用程序： 批處理和實用程序通常處理大量的數據，並且常常以一種連續的方式處理數據。這些程序在給定的窗口中完成它們的處理，這一點很重要。批處理和實用程序往往是各種系統資源的消費大戶，一旦它們擠在一起，常常會使工作負載逐步上升。
3. 規范化
規范化是分析應用程序所需的數據實體，然後將這些數據實體轉化成一組設計良好的結構的一個格式化的過程。邏輯數據模型的一般設計目標是正確性、一致性、非冗余和簡單性。而且，關系理論的信條也要求數據庫要經過規范化。
有一些按照連續編號排列的規則（也叫 范式（form））可以用來很詳細地定義規范化數據。大多數專家都會建議設計者盡量遵從前三條規則，由此得到的數據就可以說是符合第三范式。
而將一個表反規范化（de-normalize）的意思是，違反該表之前遵從的一種或多種范式，從而修改規范化的設計。這種反標准化的過程常常是由於性能的原因而進行的。在大多數以關系數據庫為主題的書籍當中，都可以找到關於規范化的更詳細的信息。
4. DB2表空間類型
在一個定義好的DB2數據庫中，實際的表必須在稱作表空間（table space）的DB2對象中創建。用戶可以在DB2中定義4種不同的表空間：
1) 簡單表空間：簡單表空間可以包含一個以上的DB2表。這種表空間由頁構成，每個頁可以包含該表空間中定義的任何表中的行。
2) 分段表空間：分段表空間可以包含一個以上的DB2表。這種表空間由頁組構成，頁組被稱作段（segment）。每個段只能包含該表空間中定義的一個表中的行。
3) 分區表空間：分區表空間只能包含一個表。根據分區（partitioning）索引的鍵范圍，這種表空間被分成數個分區。每個分區都被看作一個獨立的實體，允許SQL和DB2實用程序對其進行並發處理。
4) LOB表空間：LOB 表空間只用於LOB（大型對象）數據。LOB包括三種數據類型：BLOB（二進制大型對象）、CLOB（字符大型對象）和DBCLOB（雙字節字符大型對象）。 四、表空間與表設計方面的考慮
1. 記錄大小和頁寬
固定長度的記錄要優於可變長度的記錄，因為DB2代碼專門為處理固定長度的記錄進行優化。如果記錄是固定長度的，那麼就無需將其從存儲它的初始頁面轉移到其他地方。而對於可變長度的記錄，其長度可能會變得不再適合初始頁，因此必須將其轉移到其他頁。之後，每當需要訪問該記錄時，就必須發生額外的頁引用。DB2 UDB V8中的一種新特性允許在需要的時候修改（ALTER）某一列的寬度，這樣一來，即使您不能確定將來數據長度的增長情況，也不再需要創建可變長度的記錄。
一個頁中所能存放的記錄的數目也是值得考慮的一個方面。DB2為頁寬提供了很多選項（4KB、8KB、16KB和32KB）。一開始的時候，可以選擇默認選項（4KB），如果行的長度很小，或者對數據的訪問基本上是隨機的，則更應該選擇這一選項。不過，在有些情況下，則需要考慮使用更大的頁寬。如果一個表中各行的長度要大於4KB，那麼就需要使用更大的頁寬，因為DB2不支持跨頁（spanned）記錄。
還有一些情況下，對於一條固定長度的記錄，其總長度可能剛好比4KB的一半大一點點，這時一個頁只能容納一條記錄。對於剛好比頁寬的 1/3、1/4 大一點點的記錄，情形也是類似的。這種設計不僅浪費DASD空間，而且，對於很多DB2操作，還需要消耗更多的資源。因此，對於這一類的記錄，應該考慮使用更大的頁寬，這樣浪費的空間相對要少一些。
其他可能的頁寬是8KB、16KB和32KB。頁寬不是在CREATE TABLE語句中直接指定的。相反，表的頁寬是由相應的緩沖池的頁寬來確定的，這個緩沖池也就是為包含該表的表空間所指定的緩沖池。要了解更多細節，請參考DB2 SQL Reference手冊中的CREATE TABLESPACE語句。
2. 反規范化方面的考慮
邏輯數據模型是數據的理想藍圖。物理數據模型才是對數據的現實的實現。規范化只關注數據的意義，而沒有考慮對於訪問數據的應用程序的性能需求。完全規范化的數據庫設計在性能方面要受到質疑。
這種性能問題的最常見的例子是連接（join）操作。通常，規范化過程最終將相關的信息放入不同的表中。於是應用程序需要從多個這樣的表中訪問數據。關系數據庫為SQL語句提供了從一個以上的表中訪問信息的能力，這是通過 連接多個表來完成的。連接操作可能要消耗大量的資源和時間，這取決於表的數量以及這些表各自的長度。
像I/T中的很多事情一樣， 這裡也可以考慮一種權衡的方法。對於具有經常被請求的列的多個表，一種是復制其中的數據，一種是執行表連接，兩者誰的成本更高呢？在邏輯數據庫設計過程中，您可以毫無保留地規范化數據模型，然後再加入一定程度的反規范化，作為潛在的性能調優的一種選擇。如果您確實打算反規范化，那麼一定要為此制作完整文檔：較詳細地描述您所采取的反規范化步驟背後的原因。
3. 設計大型的表
訪問非常大的DB2表時，相應地要消耗很多的資源：CPU、內存和I/O。在設計大型表的時候，為了提高性能，用戶可以做的最重要的兩件事是：
1) 實現分區。
2) 創建有用的索引。
下面將更詳細地討論這兩個話題。 4. 使用分段的或分區的表空間
如果數據包括LOB，那麼用戶就必須創建LOB表空間。對於非LOB數據，一般需要在分區表空間和分段表空間之間進行選擇，這很大程度上取決於要存儲的數據量，在一定長度上也取決於相關應用程序所需的數據訪問類型。簡單表空間已經很少被推薦了。
下面列出了分段表空間相對於簡單表空間的一些性能優勢：
1) 對於包含多個表的表空間，當DB2取得用於某一個表的鎖時，這個鎖不會影響對其他表的段的訪問。
2) 當DB2掃描一個表時，只是訪問與那個表相關的段。而且，空段中的頁不會被提取。
3) 如果一個表被刪除，在執行COMMIT之際，它的段就立即可以為其他表所用，而不需要執行REORG實用程序。
4) 如果一個表中的所有行都被刪除（即 mass delete），則在執行COMMIT之際，該表所有的段就立即可以為其他表所用，而不需要執行REORG實用程序。
5) mass delete執行起來要高效得多，並且要寫的日志信息也更少一些。
6) COPY實用程序不會復制那些由mass delete操作或刪除（DROP）一個表所造成的空頁。
當表達到一定大小時，通過實現分區表空間可以提高易管理性和性能。如果預見到這樣的增長，那麼明智的做法是，在設計和創建表空間時將其定義為分區的。下面列出了分區表空間可以提供的一些潛在的優勢：
1) 並行性：您可以使用DB2 UDB目前所使用的三種並行方式。查詢並行（多條I/O路徑）是在DB2 V3中引入的。Sysplex查詢並行（一個DB2數據共享組中的多用戶和多任務）是在DB2 UDB V5中引入的。到現在，DB2已得到極大的發展，並大大地增強了那些處理分區表空間的DB2應用程序的並行處理能力。通過增加一定的CPU時間，可以大大減少這些查詢所需的時間。
2) 對部分數據進行操作：分區表空間允許DB2實用程序一次處理一個分區的數據，這樣其他任務或應用程序就可以並發地對其他分區進行訪問。按照類似的方式，您可以將mass UPDATE、DELETE或INSERT操作拆成多個不同的任務。
除了增加可用性以外，這種技術還可以為減少完成這種DB2工作所需的時間提供潛力。
3) 對頻繁訪問的數據有更快的訪問速度：如果分區索引可以將訪問更頻繁的行與表中其他的行分開來，那麼就可以將這些數據放入到它們專用的分區中，並使用更高速的DASD設備。
通常，表越大，就越有理由將其創建為分區的表。但有時候為較小的表創建分區表空間也很有利。當將 查找（lookup）表與其他較大的分區的表相連接時，通過將查找表也進行分區，可以最大化並行度。
如果在連接謂詞中使用分區鍵（partitioning key），最後還有一點考慮需要顧及。需要按分區鍵進行連接的表應該有相同數量的分區，並且應該在相同的值上斷開。 5. 數據壓縮
DB2提供了壓縮一個表空間或分區中的數據的能力。這是通過在CREATE TABLESPACE語句中指定COMPRESS YES選項，然後對表空間執行LOAD或REORG實用程序來實現的。通過用較短的字符串替換經常出現的長字符串，可以壓縮數據。這時會建立一個字典，其中包含了映射原始的長字符串與它們的替換值的信息。
在數據被存儲之前壓縮數據，以及在從外部存儲設備讀出數據時將數據解壓，這都需要使用一定的CPU資源。但是，數據壓縮也可以為性能帶來好處，因為可以在更少的空間（包括DASD和緩沖池中的空間）中存儲更多的數據，與未壓縮的數據相比，這樣可以減少同步讀，減少I/O等。
在決定是否壓縮一個表空間或分區時，要考慮下面一些事情：
1) 行的長度：行的長度越大（尤其是它接近頁寬時），壓縮的效率就越低。在DB2中，行不能跨頁，您可能無法實現足夠的壓縮來使一頁可以容納多行。
2) 表的長度：對於更大的表空間，壓縮更為有效。對於非常小的表，壓縮字典的大小（8KB到64KB）有可能會抵消掉通過壓縮所節省出來的空間。
3) 數據中的模式：對於特定的表空間或分區，數據中重復出現的模式的出現頻率將決定壓縮的效果。有大量重復字符串的數據有巨大的壓縮潛力。
4) 對壓縮的估計：DB2提供了一個獨立的實用程序DSN1COMP，通過執行該實用程序可以判斷壓縮數據的效果。要了解關於運行該實用程序的更多信息，請參考DB2 UtilitIEs Guide and Reference手冊。
5) 處理成本： 壓縮和解壓數據時，要消耗一定的CPU資源。與使用DB2軟件模擬程序相比，使用IBM的同步數據壓縮硬件可以大大減少所消耗的CPU資源（當DB2啟動時，它將判斷硬件壓縮特性是否可用）。
6) 更好的字典：當使用LOAD實用程序來建立壓縮字典時，DB2使用所裝載的前n行（其中n取決於數據的壓縮程度）來決定字典的內容。REORG使用一種抽樣技術來建立字典。它不僅使用所裝載的前n行，而且還會對該實用程序執行期間剩下的UNLOAD階段中的行進行抽樣。因此，REORG常常可以產生更能代表整個表空間或分區中的數據的字典。
如果您的環境可以從壓縮中得到好處，通常我們建議壓縮那些DB2表空間和分區，因為由於更少空間容納更多數據所帶來的性能優勢幾乎總是大於壓縮和解壓數據時所需的CPU資源消耗。
6. 裝載大型的表
當處理大量的數據時，一開始將數據裝載到表中時可能會遇到性能問題。為了在裝載過程中實現並行性，可以手動地創建多個LOAD任務，每個分區對應一個任務，或者，也可以在單個LOAD實用程序中裝載多個分區。每個分區都展開在I/O子系統上，從而更易於達到最佳的並行度。
為了獲得最佳性能，在LOAD語句中指定SORTKEYS參數也很重要。這將指示DB2將索引鍵傳遞給內存中的排序程序，而不是再次將這些鍵寫到DASD上的排序工作文件中，然後從中讀取這些鍵。SORTKEYS還允許裝載和排序之間的重疊，因為排序是作為一個單獨的任務運行的。
下面給出了關於裝載大型表的其他建議：
1) 一次只LOAD一個表。
2) 如果可能，為那些預計將歷時最長的任務提供較高的優先級。
3) 將工作分布在sysplex上。
4) 將輔助索引拆分成數塊，以實現並行性（請參閱下面題為PIECESIZE的討論）。
5) 在開始裝載數據時，指定LOG NO（用以防止日志記錄，以及節省日志記錄所消耗的大量資源），然後在成功裝載數據之後運行一個映像拷貝。 7. 空余空間方面的考慮
分配空余空間的主要目的是使數據行的物理順序與群集索引一致，以減少頻繁重組數據的需要。此外，對行的更好的群集會使讀訪問的速度更快，行插入的速度也更快。然而，過多地分配空余空間可能會產生浪費的DASD空間，導致每次I/O只能傳輸更少的數據，緩沖池的利用效率更低，並且要掃描更多的頁。
表空間和索引中空余空間的分配是由CREATE或ALTER TABLESPACE以及CREATE或ALTER INDEX語句的PCTFREE和FREEPAGE選項確定的。
PCTFREE告訴DB2在裝載或重組數據時，表空間或索引中的每個頁要留出多少百分比的空余空間。如果沒有足夠的空余空間來按照恰當的順序（也就是按群集順序）編寫行或索引，那麼DB2就必須將多出的數據放到另一個頁上。當越來越多的記錄被亂序存放時，性能就會出現問題。
FREEPAGE告訴DB2在裝載或重組數據時，應該過多久就分配一整頁的空余空間。例如，如果指定了FREEPAGE 5，那麼DB2將在用數據填充了5個頁之後分配一頁的空余空間。如果表行大於頁寬的一半，則應該使用FREEPAGE，因為在那樣的環境下不能在一頁上再INSERT一行。
是否定義帶空余空間的表空間，以及分配多少的空余空間，這很大程度上取決於表空間中表的INSERT特征（其次是DELETE活動）。換句話說，這取決於將行添加到表中的頻率，以及將行添加到表的什麼地方。下面有4種類別：
1) 只讀表：如果對於一個表沒有任務更新活動，那麼可以將其定義為沒有空余空間。而且，也沒有任何必要去運行REORG實用程序。
2) 隨機插入：對於已經有很多行、並且INSERT活動的級別很低，那麼一開始可以使用默認的PCTFREE（對於表空間，該值是5，對於索引，該值是10）。然後使用RUNSTATS監控數據失序的程度，再考慮您期望運行REORG的頻率，對PCTFREE進行必要的上下調整。對於INSERT活動級別很高的表，可能需要使用大於默認值的PCTFREE。對於開始為空或者只包含很少行的表（例如在新數據庫的部署期間），可能需要指定一個較高的PCTFREE，並不時地運行一下REORG，直到這個表被填充好為止。
3) 在表的末尾插入：如果一個表中的行的長度不會增長，那麼就無需分配空余空間，因為這些行是在表的末尾插入的。由於這些行是按照物理的群集順序來寫的，因此不需要運行REORG。但是，如果一個表包含可更新的VARCHAR列，或者該表被壓縮，那麼有可能行的長度會增長，從而導致某一行被轉移到其他頁上。您可以通過對表空間執行RUNSTATS，然後檢查DB2編目表SYSIBM.SYSTABLEPART的NEARINDREF和FARINDREF這兩列來判斷上述情況。如果表變得缺乏組織，那麼為表空間指定一個PCTFREE，並繼續用RUNSTATS監控位置不當（mislocated）的行。根據當前的數據以及您所觀察到的趨勢，對REORG的頻率和PCTFREE的數字進行相應的調整。通過在REORG TABLESPACE中指定INDREFLIMIT和REPORTONLY選項，可以監控被更新的DB2表中位置不當的行的數目，以及隔多遠會出現這樣的行。
4) 在熱點（hot spot）中插入：在這種情況下，表上的插入活動很頻繁，而且集中在某一個位置（或幾個位置），而不是在表的末尾進行插入。這一類情況可能是最難於處理的。可以嘗試增加PCTFREE的值。如果插入活動停留在主段（home segment）中，並且插入的行不是很長，那麼可以將數行存儲在相同的頁中。在此情況下，另一種可以考慮的方案是使用FREEPAGE。這時有必要嚴密監控表變得無組織的速度，這樣就可以在性能急劇下。 五、索引設計方面的考慮
索引也是一種DB2對象（一個單獨的VSAM數據集），它由一組排好序的鍵組成，這些鍵是從相應表中的一個列或多個列抽取出來的。很多DB2專家聲稱，只有為表空間建立恰當的索引，才是使得訪問該表空間中DB2數據的應用程序的性能達到最佳、最有效的效果。數年前，在I/T中DASD的成本和空間是更重要的考慮因素。
隨著技術的發展，通過增加更多的索引（或添加列到已有的索引中）來減少I/O，以及由此消耗的額外磁盤空間，這幾年兩者之間的權衡已經變得越來越有吸引力。索引所帶來的主要性能好處是：
1) 提供指向表中被請求的數據行的直接指針。
2) 如果結果集要求的順序與索引一致，則可以消除排序。
3) 如果被請求的列都包含在索引項中，則可以避免不得不讀數據行的情況。
1. 分區索引
在DB2 UDB V7中創建分區的表空間時，DB2根據CREATE INDEX語句的PART子句將數據劃分到幾個分區上。那樣的索引就成為所謂的分區索引，而這種分區的方法就被稱為 索引控制的分區（index-controlled partitioning）。對於分區索引，建議選擇不大可能改變的鍵列。如果對那些列進行更新，則可能導致一行從一個分區轉移到另一個分區，從而降低了性能。
DB2 V8一個重要的特性是表控制的分區（table-controlled partitioning）。這時，當創建分區的表時，分區的邊界由CREATE TABLE語句決定，而不是由CREATE INDEX語句決定。對於索引控制的分區方法，分區的表、分區索引和群集這幾個概念之間有點糾纏不清。而在表控制的分區方法中，這三個概念是各自獨立的。這種增加的靈活性使您可以考慮更多潛在的設計方案，因而也增加了提高DB2數據庫及其應用程序性能的機會。
2. 何時建立索引
CREATE INDEX語句使用戶可以立即建立索引，或者將索引的建立推遲到方便的時候。如果立即建立索引，則需要掃描表空間，這樣要花費比較多的時間。通過指定DEFER，則可以推遲索引的創建。
只要有可能，應該在初次裝載一個表之前創建其所有索引，因為LOAD實用程序建立索引的效率比CREATE INDEX過程要高。如果需要在一個已有的（並且被填充的）表上創建一個索引，那麼可以使用DEFER子句。然後可以在晚些時候使用REBUILD INDEX實用程序，這個實用程序與LOAD實用程序一樣，是更為有效的填充索引的方式。
3. PIECESIZE
DB2 UDB V5中引入了一個新特性，這種特性使您可以將一個非分區索引（non-partitioning index，NPI）拆成數塊，然後控制將組成索引空間的多個數據集的大小。通過使用這些小塊，可以使NPI的索引頁散步到多個數據集中。
通過在CREATE或ALTER INDEX語句中指定關鍵字PIECESIZE，可以確定各塊的大小。PIECESIZE的值必須是2的冪，其大小可以介於256KB到64GB之間。對於常規表空間，PIECESIZE的默認值是2GB，對於LARGE表空間，默認值是4GB。如果NPI極有可能顯著增長，那麼應選擇一個更大的值。在為主空間和輔助空間（CREATE INDEX語句的PRIQTY和SECQTY選項）的分配確定值時，也應該留意PIECESIZE的值。
通過使用這個選項，可以促進並行性，從而提高NPI的掃描性能。另一個好處是可以減少在讀或更新的處理過程中對I/O的爭用。通過指定一個較小的PIECESIZE，可以創建更多的塊，從而對塊的放置有更多的控制。將這些塊放在不同的I/O路徑中，可以減少訪問NPI所需的SQL操作的爭用。
4. 理想的索引
通過檢查應用程序中的SQL語句，可以建立一種想象起來很好的索引。
1) 首先，在索引中包括WHERE子句中的所有列，這樣，就可以使用索引形成的屏蔽來拒絕結果集中不合格的行。將這些列放在索引的開始部分。這樣一來，當對SQL語句進行EXPLAIN時，就可以產生最大的MATCHCOLS值。
2) 接下來，確保索引中這些列有適當的順序（按照ORDER BY子句），這樣可以避免排序。在進行EXPLAIN時，通過檢查PLAN_TABLE中所有不同的SORT*列，便可以確認這一點。
3) 最後，如果可能的話，將SELECT中所有的列包括到索引當中，這樣就不需要訪問表中的行。這樣的索引項可以提供所有被請求的數據。這在EXPLAIN中就表現為INDEXONLY = Y。
在很多情況下，實現這一理想的代價太高，也不切實際，甚至是不可能的。對於一個索引中可以包括的列數，以及整個索引項的長度，都有架構上的限制（雖然這些限制已考慮到相當大的索引項長度和靈活性）。而且，也要考慮索引維護的成本。雖然建立理想化的索引可以顯著提高查詢性能，但是每當對DB2數據庫執行SQL寫操作（INSERT、UPDATE 或 DELETE）時，上述理想化的索引都會有負面的影響。因此，您常常可以選擇實現只包括在WHERE和ORDER BY子句中引用到的列的索引。 六、並行處理方面的考慮
這些年，DB2通過實現各種並行處理的方法，已經大大提高了訪問數據的性能。為了提高數據密集型只讀查詢的性能，DB2 V3引入了查詢I/O並行。在這種並行中，DB2充分利用分區表空間促成的可用I/O帶寬。通過這種方法，DB2可以為單個I/O請求啟動多個並發的I/O請求，並在多個數據分區上執行並行I/O處理。這通常可以顯著減少I/O bound查詢所需的時間，而代價只是稍微增加的CPU時間。
DB2 V4引入了另一種並行技術，這種技術稱作查詢CP並行。這種方法將並行處理擴展到過程密集型（process-intensive）查詢中來。通過這種方法，一條查詢可以使DB2生成多個任務，這些任務被並行地執行，以訪問數據。分區表空間最能體現這種並行所帶來的性能提高。
DB2 UDB V5引入了sysplex查詢並行，進一步擴展了並行處理。CP並行可以在DB2子系統中為一條查詢使用多個任務，而sysplex查詢並行這種方法使一個DB2數據共享組中的所有成員可以一起處理一個查詢。對於那些主要是只讀形式的I/O密集型和處理器密集型查詢，都可以從這種並行中得到好處。
1. 支持並行訪問
DB2環境中對並行的支持有一個度的問題。首先，在DB2子系統級，並行訪問是在安裝面板DSNTIP4上控制的。DSNTIP4上的MAX DEGREE選項決定了最大並行度（並行任務的最大數量）。默認值是0，這意味著對於DB2可能調用的並行度沒有上限。我建議您先估計z/OS環境中的虛擬存儲能力和局限性，這樣DB2就不至於創建多於虛擬存儲所能處理的並行任務。
您可以通過BIND PLAN和BIND PACKAGE命令的DEGREE選項來控制DB2是否利用並行處理。若指定DEGREE(1)，表示禁止並行處理，若指定DEGREE(ANY)，則表示支持並行處理。為獲得更大的靈活性，動態SQL允許通過SET CURRENT DEGREE語句在一個計劃或包中更改這個選項，該語句可以控制專用寄存器中的值。
當一個計劃或包與DEGREE(ANY)捆綁在一起，或者CURRENT DEGREE寄存器被設為ANY時，DB2優化器將考慮對於最有效的順序計劃，並行是否可行。如果並行不可行，那麼就選擇次好的順序計劃。
2. 限定分區掃描
限定分區掃描允許DB2將數據掃描限制在一個分區表空間中。根據SQL謂詞中的值，DB2可以判斷可能包含SQL語句所請求的表行的最低分區和最高分區，然後將數據掃描限制在這一范圍內的分區中。為了使用這種技術，SQL必須提供分區索引的第一個鍵列上的一個謂詞。
3. 並行方面的建議
為了進一步促進並行處理所能帶來的性能提高，下面列出了一些需要考慮的事情：
1)盡可能均勻地對表空間分區，因為數據不整齊會對並行度產生影響。一般來說，DB2根據最大物理分區的大小將表空間分成邏輯上的幾塊。
2) 為DB2應用程序的處理分配盡可能多的中央處理器（central processor，CP），以及盡可能多的 I/O 設備和路徑。
3) 對於I/O密集型查詢，應確保分區的數量與可以訪問該表空間的I/O路徑的數量一致。
4) 對於處理器密集型查詢，應確保分區的數量等於將被分配用來在數據共享組上處理查詢的CP的數量。
5) 將用於表空間和索引的分區放在單獨的DASD卷中，並且，如果可能的話，要隔開控制單元，以減少I/O爭用。
6) 按時執行RUNSTATS實用程序，以獲得分區級的統計信息。
7) 監控虛擬緩沖池的阈值和使用情況，確保提供了足夠的緩沖池空間來最大化並行度。 七、緩沖池方面的考慮
1. 緩沖池的重要性
很多專家將數據庫緩沖池看作DB2環境中影響性能的最關鍵的資源。很多DB2的架構和設計，其基本思想都是盡可能地避免物理I/O。
DB2緩沖池由數個插槽（slot）的連續的內存組成。數據和索引頁被從DASD中讀出之後，便進入這些插槽，並留在其中，直到DB2緩沖區管理器確定那些插槽要用於其他數據。應用程序所請求的數據出現在內存中（而不是外面的DASD上）的概率越大，總體性能就越好。實際上，這裡的數據被重復使用，因而減少了應用程序對I/O的需要。
是否釋放一個緩沖池槽，這是根據最近被使用（LRU）原則來決定的。DB2維護兩個LRU列表，一個用於被隨機訪問的頁，另一個用於被順序訪問的頁。這樣可以防止大規模的表掃描完全支配緩沖池，並惡劣地影響隨機操作。通過使用不同的阈值，DB2 提供了改善緩沖池性能的靈活性。在DB2 SQL Reference手冊的第2.7.4節中對這些阈值進行了較為詳細的討論。
2. 為緩沖池設置適當的大小
緩沖池大小的指定要取決於可用存儲（包括中央存儲和擴展存儲）的容量。我建議首先分析緩沖池的分配，然後逐漸增加緩沖池的大小，直到通過增加分配的空間已無法增加更多的吞吐量，或者直到MVS換頁率已難於接受為止。為實現這一點，要使DASD I/O的數量持續下降，並不斷增加VPSIZE，直到換頁的成本超出了通過減少I/O所帶來的好處為止。
早些時候，GETPAGES的數量被認為可能是對DB2正在運行的工作量的最好度量。緩沖池的目的是減少I/O（異步讀通常表明需要進行預取，從性能角度來看，這樣做通常是值得的。另一方面，同步讀常常需要對DASD進行隨機I/O，因為被請求的頁不在緩沖池中）。會計報表顯示對應於每個緩沖池的GETPAGES和同步讀的數量。一個被普遍接受的ROT聲稱，如果GETPAGES對同步讀的比率小於10:1，那麼應該估計對更大緩沖池的需要。
3. 多緩沖池配置
如果操作系統允許為DB2緩沖池分配相當大的內存，那麼使用多緩沖池的配置很可能可以提高特定應用程序或數據庫的性能。然而，需要清楚的是，若有了多個緩沖池，那麼對這些緩沖池使用效率的監控就變得更加重要。
下面給出了關於分配多個緩沖池的一般建議：
1) 將表空間與和它們相關的索引分放到不同的緩沖池中，以減少索引I/O。
2) 將有不同數據訪問模式的數據統一放到不同的緩沖池中。批處理和查詢應用程序通常要進行大量的順序處理，而用於OLTP的數據訪問往往更具有隨機性。這為利用各種阈值處理緩沖池中某些類型的數據訪問提供了一種方法。
3) 為獨立的應用程序提供一個單獨的緩沖池。這就為緊密監控應用程序的性能問題或測試新的應用程序提供了一種方法。
4) 如果排序的性能在您的環境中很重要，那麼需要為工作文件創建一個單獨的緩沖池。
5) 對於相對較小但更新頻繁的表，通過一個足夠大的單獨的緩沖池，也許可以同時減少讀和寫的I/O。
6) 為只讀表（小的引用表）提供單獨的緩沖池可以提高性能。
八、結束語
考慮周詳的數據庫設計可以提供巨大的性能收益，但是這必須在應用程序開發過程的早期便開始著手。從早期的DB2開始，明智的開發人員就已經使用了前面提到的很多准則，這些准則直到現在也仍然成立。但是，DB2功能的增強、其他領域中硬件和軟件技術的變化將影響當前和將來的應用程序，知道這一點至關重要。當數據庫性能成為開發過程中的焦點時，您的數據庫設計使得為DB2應用程序提供最佳性能有了更大的可能性。
