在開發過程的早期作出的很多設計決定對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啟動時，它將判斷硬件壓縮特性是否可用）。
