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