在開發過程的早期作出的很多設計決定對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文檔。 12345678910下一頁 本文的通用設計點是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數據和程序上，這種做法比較明智。在確定是什么應用程序或事務構成這一重要的工作負載時，以下特征中的一條或幾條將會適用： 上一頁1234567下一頁 1) 它們代表了總體業務工作負載的很大的百分比。 2) 它們有著要害響應時間需求。 3) 它們包括復雜的邏輯和/或數據訪問需求。 4) 它們訪問大量的數據。 5) 它們消耗大量的資源。 6) 與那些屬于公司內部的應用程序相比，它們是直接與客戶打交道的（通過 Web、ATM 等）。 3. 數據庫設計 數據庫的設計有兩個階段： 1) 邏輯數據庫設計 2) 物理數據庫設計 數據庫的邏輯模型僅僅是對用戶的所有數據需求的一種表示，它將這些需求變成一種范式。這種模型通常就是數據建模會議的輸出或最終結果。該模型實際上很少被原原本本地實現。其實，該模型只是在考慮如何實際地構造數據和將數據存儲在DBMS之前，對數據的一種理想化的看法。 在對數據庫對象的架構進行了考慮之后，邏輯模型就被轉化為物理模型。在設計的這個階段，就需要較為具體地考慮數據訪問需求和性能因素。在產生物理設計的這個過程當中，有兩大要素，即表設計和索引設計。下面將較為具體地討論這兩個話題。 4. DB2性能治理的方法 為了確保DB2應用程序具備合格的性能，未雨綢繆勝于亡羊補牢。在設計DB2數據庫的早期階段就將性能因素考慮進來，這一點很重要。然后，在項目盡可能早的時候，建立一套符合Service Level Agreement(SLA) 的性能“基準線測量方法，這樣，便可以在展示的時候和應用程序被修改的時候，跟蹤性能特性和趨勢。同時還應該持續地監控DB2系統和應用程序，從而在大的問題完全發作之前進行猜測。 通常，很多客戶只有到了應用程序開發項目的最后階段才開始擔心性能。但是通常沒有什么好的理由需要等到那時才去考慮性能。更好的做法是，在指定了用戶界面和處理邏輯之后，立即考慮數據庫設計的性能特性。例如，在創建最佳索引時，應該將重要DB2工作（請參閱前面的討論）中SQL語句的謂詞作為主要指南。 上一頁12345678下一頁 即使您可以開發一個有效的初期設計，隨著數據量的增加，或者在系統資源緊缺的時候，也仍有必要對應用程序和/或數據庫作出修改。假如一個應用程序執行時的性能不合格，較為可取的做法通常是添加更多的列到現有的索引中，或者為一個表添加新的索引，這種做法是首選。而更改表的設計，或修改用戶需求，抑或修改反規范化（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本身新版本的發行。 上一頁123456789下一頁 2. DB2工作負載 磁盤I/O經常是影響響應時間的最大因素，但是通過查看GETPAGE(GP)請求，更輕易理解底層的性能問題。當監控DB2活動和分析報告時，GETPAGE的數量也許是DB2總體工作負載的最好的指示器。 某個安裝環境下的很多DB2工作都可以無異議地歸為以下幾類： 1) 事務：事務是在事務治理器（例如CICS和IMS/TM）控制下運行的程序。其中的SQL通常比較簡單，但是事務量比較重。事務必須為用戶提供極好的響應時間，這樣應用程序才不致于要長時間地等待它們所需的資源。通常，第一個調用事務的用戶將承受讀取索引和數據頁的成本。隨后的用戶則經常可以發現有些資源已經在緩沖池中。 2) 查詢：查詢也是程序，經常在需要決策支持時執行它。其中的SQL可能非常復雜，但是工作量經常遠不及事務。查詢的用戶經常要等上數分鐘甚至數小時，這取決于為了產生用戶所請求的結果集，需要對多少數據進行搜索。查詢經常要引起對整個表的掃描，而對結果排序是這種類型的工作負載的另一種常見特征。 3) 批處理和實用程序： 批處理和實用程序通常處理大量的數據，并且經常以一種連續的方式處理數據。這些程序在給定的窗口中完成它們的處理，這一點很重要。批處理和實用程序往往是各種系統資源的消費大戶，一旦它們擠在一起，經常會使工作負載逐步上升。 3. 規范化 規范化是分析應用程序所需的數據實體，然后將這些數據實體轉化成一組設計良好的結構的一個格式化的過程。邏輯數據模型的一般設計目標是正確性、一致性、非冗余和簡單性。而且，關系理論的信條也要求數據庫要經過規范化。 有一些按照連續編號排列的規則（也叫 范式（form））可以用來很具體地定義規范化數據。大多數專家都會建議設計者盡量遵從前三條規則，由此得到的數據就可以說是符合第三范式。 上一頁12345678910下一頁 而將一個表反規范化（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）某一列的寬度，這樣一來，即使您不能確定將來數據長度的增長情況，也不再需要創建可變長度的記錄。 上一頁234567891011下一頁 一個頁中所能存放的記錄的數目也是值得考慮的一個方面。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語句提供了從一個以上的表中訪問信息的能力，這是通過 連接多個表來完成的。連接操作可能要消耗大量的資源和時間，這取決于表的數量以及這些表各自的長度。 上一頁3456789101112下一頁 像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執行起來要高效得多，并且要寫的日志信息也更少一些。 上一頁45678910111213下一頁 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），最后還有一點考慮需要顧及。需要按分區鍵進行連接的表應該有相同數量的分區，并且應該在相同的值上斷開。 上一頁567891011121314下一頁 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啟動時，它將判定硬件壓縮特性是否可用）。 上一頁6789101112131415下一頁