在開發(fā)過程的早期作出的很多設計決定對DB2應用程序和數(shù)據(jù)庫的性能有著巨大的影響。本文為在z/OS環(huán)境中取得更好的性能提供了一些一般性的指南和建議。 一、簡介 本文的目的是為IBM業(yè)務伙伴提供關于DB2 Universal Database?(UDB)for z/OS(后面將簡稱為 DB2)環(huán)境中DB2數(shù)據(jù)庫性能的重要信息。本文試圖從多處收集材料，并盡可能有效地將它們表述出來。本文無意包含很全面的范圍，也不會包含很深的細節(jié)。 我曾打算討論對DB2數(shù)據(jù)庫的性能影響最大的一些因素。但是，并不是所有可能的情形都可以猜測到，也不是所有潛在的考慮都能顧及到，更不用說在期望的范圍內(nèi)對它們進行描述了。我希望本文可以為不同環(huán)境下的DB2用戶提供一個通用的指南，以幫助他們?nèi)〉米罴训腄B2數(shù)據(jù)庫性能。本文的目的是成為一個良好的起點，用以處理任何給定安裝環(huán)境下的數(shù)據(jù)庫性能問題。 本文的范圍是數(shù)據(jù)庫設計性能。DB2性能遠不止這一部分，它肯定要受到數(shù)據(jù)庫設計以外的很多因素的影響。例如，程序的編碼邏輯和其中使用的實際的SQL語句，可以列為應用程序設計一類。DB2系統(tǒng)性能可以包括諸如安裝選項、緩沖池大小設置、DB2相關地址空間的調(diào)度優(yōu)先級等等之類的因素。 本文的焦點是DB2數(shù)據(jù)庫的設計。不過，有時候這些性能因素類別之間的界線可能會有些模糊。例如，在某種安裝環(huán)境下進行配置時，緩沖池大小的設置和數(shù)量的選擇通常被認為是一項系統(tǒng)性能因素。但是，倘若是將特定的表空間和索引指派給那些緩沖池，那么這些因素又可以看作是數(shù)據(jù)庫設計一類的因素了。 在這里，我假設讀者對z/OS環(huán)境中的DB2有一個基本的理解。本文的頭幾頁將討論性能治理的一些基本概念和準則，以便進行“級別設置 。我的建議有點綜合的性質(zhì)，因而不會總是具體地給出技術性的描述和語法。讀者假如想了解關于這些內(nèi)容的更具體的信息，那么應該去閱讀關于用戶本地所安裝的DB2版本的最近的IBM文檔。 12345678910下一頁 本文的通用設計點是DB2 for z/OS V7。雖然DB2 for z/OS V8已經(jīng)被公布，并且也普遍可用（generally available ，GA），但是大部分IBM客戶極有可能需要幾個月的時間才能實現(xiàn)用于他們的生產(chǎn)系統(tǒng)的DB2 V8 NFM（New Function Mode）。而且，這里還要考慮另外一個因素。雖然DB2的每個新版本在變得普遍可用之前，都已經(jīng)在IBM及其客戶環(huán)境下經(jīng)過了廣泛的測試，但是相對于一個還沒有推廣的、沒有普遍使用的版本而言，客戶們往往對于基于早先版本的DB2的一般建議和竅門更有信心（長時間積累的經(jīng)驗驗證了這一結(jié)論）。我將提到DB2 V8的一些新特性，從性能的角度來看，這些新性能可能會影響數(shù)據(jù)庫設計。 免責聲明：本文中所包含的信息未經(jīng)任何正式的IBM測試，而是以AS IS的形式發(fā)布的。對這些信息的使用和其中任何技術的實現(xiàn)，都由用戶承擔責任，并取決于用戶的能力去評價它們和將它們整合到客戶特有的操作環(huán)境。雖然IBM對于每一項都進行了審查，以求特定情況下的正確性，但不能保證在其他情況下也能得到相同的或類似的結(jié)果。試圖將這些技術應用于他們自身環(huán)境的用戶須自己承擔風險。 二、性能準則和方法學 1. 何時考慮性能 考慮應用程序和數(shù)據(jù)庫的性能特性的時機是在那些應用程序和數(shù)據(jù)庫的初期設計階段，也就是開發(fā)過程的開始階段。對DB2應用程序和數(shù)據(jù)庫所需的資源進行合理的估計，這有助于用戶在開發(fā)過程的早期便對設計和實現(xiàn)作出恰當?shù)臎Q定。假如等到后期才來考慮訪問數(shù)據(jù)庫的應用程序的性能，那么為了取得適當?shù)捻憫獣r間和生成批處理窗口而進行一些必需的修改時，就會更加困難，而且更加消耗時間。 2. 應該關注些什么 當從性能的角度進行設計時，將大部分的精力集中在重要DB2數(shù)據(jù)和程序上，這種做法比較明智。在確定是什么應用程序或事務構成這一重要的工作負載時，以下特征中的一條或幾條將會適用： 上一頁1234567下一頁 1) 它們代表了總體業(yè)務工作負載的很大的百分比。 2) 它們有著要害響應時間需求。 3) 它們包括復雜的邏輯和/或數(shù)據(jù)訪問需求。 4) 它們訪問大量的數(shù)據(jù)。 5) 它們消耗大量的資源。 6) 與那些屬于公司內(nèi)部的應用程序相比，它們是直接與客戶打交道的（通過 Web、ATM 等）。 3. 數(shù)據(jù)庫設計 數(shù)據(jù)庫的設計有兩個階段： 1) 邏輯數(shù)據(jù)庫設計 2) 物理數(shù)據(jù)庫設計 數(shù)據(jù)庫的邏輯模型僅僅是對用戶的所有數(shù)據(jù)需求的一種表示，它將這些需求變成一種范式。這種模型通常就是數(shù)據(jù)建模會議的輸出或最終結(jié)果。該模型實際上很少被原原本本地實現(xiàn)。其實，該模型只是在考慮如何實際地構造數(shù)據(jù)和將數(shù)據(jù)存儲在DBMS之前，對數(shù)據(jù)的一種理想化的看法。 在對數(shù)據(jù)庫對象的架構進行了考慮之后，邏輯模型就被轉(zhuǎn)化為物理模型。在設計的這個階段，就需要較為具體地考慮數(shù)據(jù)訪問需求和性能因素。在產(chǎn)生物理設計的這個過程當中，有兩大要素，即表設計和索引設計。下面將較為具體地討論這兩個話題。 4. DB2性能治理的方法 為了確保DB2應用程序具備合格的性能，未雨綢繆勝于亡羊補牢。在設計DB2數(shù)據(jù)庫的早期階段就將性能因素考慮進來，這一點很重要。然后，在項目盡可能早的時候，建立一套符合Service Level Agreement(SLA) 的性能“基準線測量方法，這樣，便可以在展示的時候和應用程序被修改的時候，跟蹤性能特性和趨勢。同時還應該持續(xù)地監(jiān)控DB2系統(tǒng)和應用程序，從而在大的問題完全發(fā)作之前進行猜測。 通常，很多客戶只有到了應用程序開發(fā)項目的最后階段才開始擔心性能。但是通常沒有什么好的理由需要等到那時才去考慮性能。更好的做法是，在指定了用戶界面和處理邏輯之后，立即考慮數(shù)據(jù)庫設計的性能特性。例如，在創(chuàng)建最佳索引時，應該將重要DB2工作（請參閱前面的討論）中SQL語句的謂詞作為主要指南。 上一頁12345678下一頁 即使您可以開發(fā)一個有效的初期設計，隨著數(shù)據(jù)量的增加，或者在系統(tǒng)資源緊缺的時候，也仍有必要對應用程序和/或數(shù)據(jù)庫作出修改。假如一個應用程序執(zhí)行時的性能不合格，較為可取的做法通常是添加更多的列到現(xiàn)有的索引中，或者為一個表添加新的索引，這種做法是首選。而更改表的設計，或修改用戶需求，抑或修改反規(guī)范化（de-normalizing）表，都不是很有吸引力的選擇。 三、理解DB2性能 1. Rules-of-thumb Rules of thumb（經(jīng)驗法則，也稱ROT）在規(guī)劃、監(jiān)控和優(yōu)化DB2性能的時候很有用。ROT通常是基于以前的經(jīng)驗（比如在一段時間內(nèi)觀察到的平均值）或者更復雜公式的簡化。 記住這樣一個事實很重要，即ROT只對于粗略的估計有用，而對于具體的分析用處不大。假如只是在某一類的文檔中看到了一些ROT，便欣然接受并作為精確的事實來引用，那么就會有危險。在最好的情況下，這些ROT是一種估計，而在最壞的情況下，這些ROT對于特定的DB2環(huán)境可能不成立。 您應該為自己的環(huán)境非凡開發(fā)這些ROT（或者對它們進行調(diào)節(jié)，以適應自己的環(huán)境的特性）。應確保ROT與實際經(jīng)驗相關，而不是盲目地接受，這樣才能對它們更有信心。一開始的時候，使用那些在您特定環(huán)境以外被使用過或者被開發(fā)出來的ROT，這種做法可能有用。但是，當對您自己DB2系統(tǒng)中的適當數(shù)據(jù)進行收集、分析和編制文檔之后，應該對這些ROT加以驗證和修改。IBM Redbooks是關于ROT的一種很好的參考資料，這些ROT經(jīng)常作為建議被包括在性能監(jiān)控工具中。 另一方面的考慮是，ROT可能隨著時間的推移而演變。硬件技術的發(fā)展，軟件編程技術的提高，系統(tǒng)架構的變化，諸如此類的變化都可能使得ROT的可靠性降低，甚至變得無效。而使ROT隨著時間變化的最大因素也許正是DB2本身新版本的發(fā)行。 上一頁123456789下一頁 2. DB2工作負載 磁盤I/O經(jīng)常是影響響應時間的最大因素，但是通過查看GETPAGE(GP)請求，更輕易理解底層的性能問題。當監(jiān)控DB2活動和分析報告時，GETPAGE的數(shù)量也許是DB2總體工作負載的最好的指示器。 某個安裝環(huán)境下的很多DB2工作都可以無異議地歸為以下幾類： 1) 事務：事務是在事務治理器（例如CICS和IMS/TM）控制下運行的程序。其中的SQL通常比較簡單，但是事務量比較重。事務必須為用戶提供極好的響應時間，這樣應用程序才不致于要長時間地等待它們所需的資源。通常，第一個調(diào)用事務的用戶將承受讀取索引和數(shù)據(jù)頁的成本。隨后的用戶則經(jīng)常可以發(fā)現(xiàn)有些資源已經(jīng)在緩沖池中。 2) 查詢：查詢也是程序，經(jīng)常在需要決策支持時執(zhí)行它。其中的SQL可能非常復雜，但是工作量經(jīng)常遠不及事務。查詢的用戶經(jīng)常要等上數(shù)分鐘甚至數(shù)小時，這取決于為了產(chǎn)生用戶所請求的結(jié)果集，需要對多少數(shù)據(jù)進行搜索。查詢經(jīng)常要引起對整個表的掃描，而對結(jié)果排序是這種類型的工作負載的另一種常見特征。 3) 批處理和實用程序： 批處理和實用程序通常處理大量的數(shù)據(jù)，并且經(jīng)常以一種連續(xù)的方式處理數(shù)據(jù)。這些程序在給定的窗口中完成它們的處理，這一點很重要。批處理和實用程序往往是各種系統(tǒng)資源的消費大戶，一旦它們擠在一起，經(jīng)常會使工作負載逐步上升。 3. 規(guī)范化 規(guī)范化是分析應用程序所需的數(shù)據(jù)實體，然后將這些數(shù)據(jù)實體轉(zhuǎn)化成一組設計良好的結(jié)構的一個格式化的過程。邏輯數(shù)據(jù)模型的一般設計目標是正確性、一致性、非冗余和簡單性。而且，關系理論的信條也要求數(shù)據(jù)庫要經(jīng)過規(guī)范化。 有一些按照連續(xù)編號排列的規(guī)則（也叫 范式（form））可以用來很具體地定義規(guī)范化數(shù)據(jù)。大多數(shù)專家都會建議設計者盡量遵從前三條規(guī)則，由此得到的數(shù)據(jù)就可以說是符合第三范式。 上一頁12345678910下一頁 而將一個表反規(guī)范化（de-normalize）的意思是，違反該表之前遵從的一種或多種范式，從而修改規(guī)范化的設計。這種反標準化的過程經(jīng)常是由于性能的原因而進行的。在大多數(shù)以關系數(shù)據(jù)庫為主題的書籍當中，都可以找到關于規(guī)范化的更具體的信息。 4. DB2表空間類型 在一個定義好的DB2數(shù)據(jù)庫中，實際的表必須在稱作表空間（table space）的DB2對象中創(chuàng)建。用戶可以在DB2中定義4種不同的表空間： 1) 簡單表空間：簡單表空間可以包含一個以上的DB2表。這種表空間由頁構成，每個頁可以包含該表空間中定義的任何表中的行。 2) 分段表空間：分段表空間可以包含一個以上的DB2表。這種表空間由頁組構成，頁組被稱作段（segment）。每個段只能包含該表空間中定義的一個表中的行。 3) 分區(qū)表空間：分區(qū)表空間只能包含一個表。根據(jù)分區(qū)（partitioning）索引的鍵范圍，這種表空間被分成數(shù)個分區(qū)。每個分區(qū)都被看作一個獨立的實體，答應SQL和DB2實用程序?qū)ζ溥M行并發(fā)處理。 4) LOB表空間：LOB 表空間只用于LOB（大型對象）數(shù)據(jù)。LOB包括三種數(shù)據(jù)類型：BLOB（二進制大型對象）、CLOB（字符大型對象）和DBCLOB（雙字節(jié)字符大型對象）。 四、表空間與表設計方面的考慮 1. 記錄大小和頁寬 固定長度的記錄要優(yōu)于可變長度的記錄，因為DB2代碼專門為處理固定長度的記錄進行優(yōu)化。假如記錄是固定長度的，那么就無需將其從存儲它的初始頁面轉(zhuǎn)移到其他地方。而對于可變長度的記錄，其長度可能會變得不再適合初始頁，因此必須將其轉(zhuǎn)移到其他頁。之后，每當需要訪問該記錄時，就必須發(fā)生額外的頁引用。DB2 UDB V8中的一種新特性答應在需要的時候修改（ALTER）某一列的寬度，這樣一來，即使您不能確定將來數(shù)據(jù)長度的增長情況，也不再需要創(chuàng)建可變長度的記錄。 上一頁234567891011下一頁 一個頁中所能存放的記錄的數(shù)目也是值得考慮的一個方面。DB2為頁寬提供了很多選項（4KB、8KB、16KB和32KB）。一開始的時候，可以選擇默認選項（4KB），假如行的長度很小，或者對數(shù)據(jù)的訪問基本上是隨機的，則更應該選擇這一選項。不過，在有些情況下，則需要考慮使用更大的頁寬。假如一個表中各行的長度要大于4KB，那么就需要使用更大的頁寬，因為DB2不支持跨頁（spanned）記錄。 還有一些情況下，對于一條固定長度的記錄，其總長度可能剛好比4KB的一半大一點點，這時一個頁只能容納一條記錄。對于剛好比頁寬的 1/3、1/4 大一點點的記錄，情形也是類似的。這種設計不僅浪費DASD空間，而且，對于很多DB2操作，還需要消耗更多的資源。因此，對于這一類的記錄，應該考慮使用更大的頁寬，這樣浪費的空間相對要少一些。 其他可能的頁寬是8KB、16KB和32KB。頁寬不是在CREATE TABLE語句中直接指定的。相反，表的頁寬是由相應的緩沖池的頁寬來確定的，這個緩沖池也就是為包含該表的表空間所指定的緩沖池。要了解更多細節(jié)，請參考DB2 SQL Reference手冊中的CREATE TABLESPACE語句。 2. 反規(guī)范化方面的考慮 邏輯數(shù)據(jù)模型是數(shù)據(jù)的理想藍圖。物理數(shù)據(jù)模型才是對數(shù)據(jù)的現(xiàn)實的實現(xiàn)。規(guī)范化只關注數(shù)據(jù)的意義，而沒有考慮對于訪問數(shù)據(jù)的應用程序的性能需求。完全規(guī)范化的數(shù)據(jù)庫設計在性能方面要受到質(zhì)疑。 這種性能問題的最常見的例子是連接（join）操作。通常，規(guī)范化過程最終將相關的信息放入不同的表中。于是應用程序需要從多個這樣的表中訪問數(shù)據(jù)。關系數(shù)據(jù)庫為SQL語句提供了從一個以上的表中訪問信息的能力，這是通過 連接多個表來完成的。連接操作可能要消耗大量的資源和時間，這取決于表的數(shù)量以及這些表各自的長度。 上一頁3456789101112下一頁 像I/T中的很多事情一樣， 這里也可以考慮一種權衡的方法。對于具有經(jīng)常被請求的列的多個表，一種是復制其中的數(shù)據(jù)，一種是執(zhí)行表連接，兩者誰的成本更高呢？在邏輯數(shù)據(jù)庫設計過程中，您可以毫無保留地規(guī)范化數(shù)據(jù)模型，然后再加入一定程度的反規(guī)范化，作為潛在的性能調(diào)優(yōu)的一種選擇。假如您確實打算反規(guī)范化，那么一定要為此制作完整文檔：較具體地描述您所采取的反規(guī)范化步驟背后的原因。 3. 設計大型的表 訪問非常大的DB2表時，相應地要消耗很多的資源：CPU、內(nèi)存和I/O。在設計大型表的時候，為了提高性能，用戶可以做的最重要的兩件事是： 1) 實現(xiàn)分區(qū)。 2) 創(chuàng)建有用的索引。 下面將更具體地討論這兩個話題。 4. 使用分段的或分區(qū)的表空間 假如數(shù)據(jù)包括LOB，那么用戶就必須創(chuàng)建LOB表空間。對于非LOB數(shù)據(jù)，一般需要在分區(qū)表空間和分段表空間之間進行選擇，這很大程度上取決于要存儲的數(shù)據(jù)量，在一定長度上也取決于相關應用程序所需的數(shù)據(jù)訪問類型。簡單表空間已經(jīng)很少被推薦了。 下面列出了分段表空間相對于簡單表空間的一些性能優(yōu)勢： 1) 對于包含多個表的表空間，當DB2取得用于某一個表的鎖時，這個鎖不會影響對其他表的段的訪問。 2) 當DB2掃描一個表時，只是訪問與那個表相關的段。而且，空段中的頁不會被提取。 3) 假如一個表被刪除，在執(zhí)行COMMIT之際，它的段就立即可以為其他表所用，而不需要執(zhí)行REORG實用程序。 4) 假如一個表中的所有行都被刪除（即 mass delete），則在執(zhí)行COMMIT之際，該表所有的段就立即可以為其他表所用，而不需要執(zhí)行REORG實用程序。 5) mass delete執(zhí)行起來要高效得多，并且要寫的日志信息也更少一些。 上一頁45678910111213下一頁 6) COPY實用程序不會復制那些由mass delete操作或刪除（DROP）一個表所造成的空頁。 當表達到一定大小時，通過實現(xiàn)分區(qū)表空間可以提高易治理性和性能。假如預見到這樣的增長，那么明智的做法是，在設計和創(chuàng)建表空間時將其定義為分區(qū)的。下面列出了分區(qū)表空間可以提供的一些潛在的優(yōu)勢： 1) 并行性：您可以使用DB2 UDB目前所使用的三種并行方式。查詢并行（多條I/O路徑）是在DB2 V3中引入的。Sysplex查詢并行（一個DB2數(shù)據(jù)共享組中的多用戶和多任務）是在DB2 UDB V5中引入的。到現(xiàn)在，DB2已得到極大的發(fā)展，并大大地增強了那些處理分區(qū)表空間的DB2應用程序的并行處理能力。通過增加一定的CPU時間，可以大大減少這些查詢所需的時間。 2) 對部分數(shù)據(jù)進行操作：分區(qū)表空間答應DB2實用程序一次處理一個分區(qū)的數(shù)據(jù)，這樣其他任務或應用程序就可以并發(fā)地對其他分區(qū)進行訪問。按照類似的方式，您可以將mass UPDATE、DELETE或INSERT操作拆成多個不同的任務。除了增加可用性以外，這種技術還可以為減少完成這種DB2工作所需的時間提供潛力。 3) 對頻繁訪問的數(shù)據(jù)有更快的訪問速度：假如分區(qū)索引可以將訪問更頻繁的行與表中其他的行分開來，那么就可以將這些數(shù)據(jù)放入到它們專用的分區(qū)中，并使用更高速的DASD設備。 通常，表越大，就越有理由將其創(chuàng)建為分區(qū)的表。但有時候為較小的表創(chuàng)建分區(qū)表空間也很有利。當將 查找（lookup）表與其他較大的分區(qū)的表相連接時，通過將查找表也進行分區(qū)，可以最大化并行度。 假如在連接謂詞中使用分區(qū)鍵（partitioning key），最后還有一點考慮需要顧及。需要按分區(qū)鍵進行連接的表應該有相同數(shù)量的分區(qū)，并且應該在相同的值上斷開。 上一頁567891011121314下一頁 5. 數(shù)據(jù)壓縮 DB2提供了壓縮一個表空間或分區(qū)中的數(shù)據(jù)的能力。這是通過在CREATE TABLESPACE語句中指定COMPRESS YES選項，然后對表空間執(zhí)行LOAD或REORG實用程序來實現(xiàn)的。通過用較短的字符串替換經(jīng)常出現(xiàn)的長字符串，可以壓縮數(shù)據(jù)。這時會建立一個字典，其中包含了映射原始的長字符串與它們的替換值的信息。 在數(shù)據(jù)被存儲之前壓縮數(shù)據(jù)，以及在從外部存儲設備讀出數(shù)據(jù)時將數(shù)據(jù)解壓，這都需要使用一定的CPU資源。但是，數(shù)據(jù)壓縮也可以為性能帶來好處，因為可以在更少的空間（包括DASD和緩沖池中的空間）中存儲更多的數(shù)據(jù)，與未壓縮的數(shù)據(jù)相比，這樣可以減少同步讀，減少I/O等。 在決定是否壓縮一個表空間或分區(qū)時，要考慮下面一些事情： 1) 行的長度：行的長度越大（尤其是它接近頁寬時），壓縮的效率就越低。在DB2中，行不能跨頁，您可能無法實現(xiàn)足夠的壓縮來使一頁可以容納多行。 2) 表的長度：對于更大的表空間，壓縮更為有效。對于非常小的表，壓縮字典的大小（8KB到64KB）有可能會抵消掉通過壓縮所節(jié)省出來的空間。 3) 數(shù)據(jù)中的模式：對于特定的表空間或分區(qū)，數(shù)據(jù)中重復出現(xiàn)的模式的出現(xiàn)頻率將決定壓縮的效果。有大量重復字符串的數(shù)據(jù)有巨大的壓縮潛力。 4) 對壓縮的估計：DB2提供了一個獨立的實用程序DSN1COMP，通過執(zhí)行該實用程序可以判定壓縮數(shù)據(jù)的效果。要了解關于運行該實用程序的更多信息，請參考DB2 Utilities Guide and Reference手冊。 5) 處理成本： 壓縮和解壓數(shù)據(jù)時，要消耗一定的CPU資源。與使用DB2軟件模擬程序相比，使用IBM的同步數(shù)據(jù)壓縮硬件可以大大減少所消耗的CPU資源（當DB2啟動時，它將判定硬件壓縮特性是否可用）。 上一頁6789101112131415下一頁