這篇文章的目的是為了給IBM(r)商業伙伴提供一些重要的信息，這些信息是關于DB2通用數據庫（UDB）在z/OS(r) 環境下（以下簡稱DB2）DB2(r)數據庫性能方面的。本文試圖將來自多方資源的材料進行整合，然后盡量有效地將信息展示出來。本文盡量避免在范圍上過于寬泛，以及過于深入細節。下面，我將要討論那些最頻繁影響DB2數據庫性能的因素。我在這里并不涉及所有可能的條件和所有潛在的考慮，而是只局限于預期的范圍之內。我希望這篇文章能夠對DB2客戶有一個總體的指導，從而使它們自己的環境中去獲得DB2數據庫的最適宜的性能。這篇文章將從如何在一個特定的安裝中定制數據庫的性能開始談起。 這篇文章所涉及的范圍是數據庫設計性能。而DB2的性能包括的內容比這要多得多，除了數據庫的設計之外，實際上還有很多其他的影響因素。例如，程序的編碼邏輯，實際使用的SQL語句，都被劃分在應用程序設計范圍內了。影響DB2系統性能的因素包括了例如安裝選項、緩沖池規模、DB2相關的地址空間的分配優先級等。本文的重點在于DB2數據庫的設計。但是有些時候，這些影響性能的因素分類之間的界限有些模糊。例如，安裝過程中對緩沖池的規模，選用緩沖池的數量進行的配置一般都被認為是系統性能因素。但是，當分配特定的表空間和那些緩沖池的索引的時候，就被認為是數據庫設計所要考慮的了。 假設讀者已經對z/OS環境下的DB2有了一些基本的了解。本文的前幾頁討論了一些關于性能治理的基本概念和原則，以便于后面的理解。我的建議在本質上有些籠統，我總是避免過于糾纏技術細節或者語法等方面的問題。想要獲得關于這些問題的具體信息，你可以查看IBM最近發布的有關安裝在客戶端的DB2的文檔。 這篇文檔主要著眼于z/OS V7環境下的DB2。雖然在z/OS V8下的DB2已經發布了，并且具有通用性，但是很可能還需要幾個月的時間，IBM 的大多數客戶才能夠讓他們的產品系統實現DB2 V8 NFM（新功能模式）。這里還有另一個需要考慮的問題：雖然每個新發布的DB2在正式通用之前，都會在IBM和客戶環境中進行相當充分的測試，但是客戶仍然很可能對基于前一版本的有關DB2的常見推薦和單憑經驗的方法懷有更多的信心，而不是非常認同還沒有發布，或者是沒有獲得普遍使用的新版本（由于驗證結論的實際過程的時間長度和深度）。我會在文中提到一些可能會影響數據庫設計性能的DB2 V8的新特性。 12345678910下一頁 免責聲明：本文包含的信息并沒有提交給任何正式的IBM測試，并按"AS IS"原則提供。本信息的使用，或者是以上提到的任何技術的實現均由用戶負責，且依靠用戶的個人能力對其進行評估，并將其整合進入客戶特定的操作環境中。其中的每一項都將在IBM特定的條件下獲得精確的數值，這里不保證在其他地方會出現同樣或者相似的結果。當用戶嘗試在各自的環境下采用上述技術時，需要自己承擔風險。 性能原則和方法學 考慮性能的時機 考慮應用程序和數據庫各自不同的性能特征的時間，是在對這些應用程序和數據庫進行設計的初始階段，即開發過程的一開始。對你的DB2應用程序和數據庫所需要的資源進行合理評估，將會幫助用戶在開發過程的早期對設計和實現做出適當的決定。假如你的應用程序訪問數據庫的性能直到后來才被說明，那么就要做必需的修改以獲得足夠的響應時間，并處理你的批處理窗口；這將會變得更加困難，并且消耗時間。 關注焦點 當設計性能的時候，將大部分的精力集中在重要的DB2數據和程序上是很明智的做法。對應用程序或者事務進行定義是這部分工作中的重點，以下一個或者多個特點是適用的： 它們表現了所有業務工作量中的大部分 它們有一個很要害的響應時間需求 它們包括了復雜的邏輯和/或數據訪問需求 它們訪問大量的數據 它們消耗大量的資源 它們直接與客戶進行交互（通過網絡、ATM等），與此相反，應用程序大多面向公司內部 數據庫設計 數據庫設計發生在以下兩個階段： 數據庫邏輯設計 數據庫物理設計 數據庫的邏輯模型只是所有用戶數據需求規格化的形式表現。這個模型通常是數據建模階段的輸出或者是最終結果。它很少在實際意義上被實現。更何況，在考慮如何在數據庫治理系統中實際地組織和存儲數據之前，它只是數據的一個理想化的視圖。 上一頁1234567下一頁 當考慮到特定數據庫對象的體系結構的時候，邏輯模型才會轉化為物理模型。在這一設計階段，才需要考慮到數據訪問需求和性能因素的一些細節。在進行物理設計的過程中，兩個要害的因素是表設計和索引設計。這兩個問題將會在下面進行具體討論。 DB2性能治理的方式 為了確保你的DB2應用程序有足夠的性能，采取積極的態度總比消極應對有意義得多。在DB2數據庫設計的早期階段總結出性能因素是至關重要的。然后在項目中，努力盡早地確定滿足你的服務級別協議（SLA）的性能“基線的測量標準，這樣你就可以在首次演示和應用程序變更的時候追蹤性能特點及其發展趨勢。不斷地監測你的DB2系統和應用程序，以便在大多數的問題成形之前預見到它們。 傳統意義上，許多客戶都是直到應用程序開發項目的最后階段才開始關心性能問題。但是這樣的等待是毫無益處的。早在描述用戶界面和處理邏輯的階段就去思考數據庫設計的性能特點，是比較有好處的。例如，在你的重要的DB2工作（見前面所述）中，創建最好的索引的一個基本的指導就是對SQL語句中的謂詞的考慮。 即使是你開發出的最初設計是一個有效的設計，但是以下的若干修改仍然是必要的，例如對你的應用程序進行修改，或者數據庫以卷的形式增長，或者是限制系統資源。假如現有的應用程序沒有充分的運行，那么通常情況下你都會希望最好能夠在現有的索引上面添加更多的列，或者在表上添加新的索引。不論改變表的設計，或者修改客戶的需求，還是使表非標準化，通常情況下都不是好的選擇。理解DB2性能 單憑經驗的方法 單憑經驗的方法（又叫做ROT）在進行計劃、監測，以及對DB2的性能進行優化時是很有用處的。ROT典型地基于以前的經驗（例如，長時間的觀測平均水平），或者是基于對比較復雜的公式進行簡化。 上一頁12345678下一頁 記住下面這一點是很重要的，ROT對于粗略的估計有用，但是進行具體分析的時候就不行了。只是因為這些經驗出現在某些文章中，就把它們作為性能的精確引證是很危險的。最好的情況下，它們是估計值；在最壞的情況下，它們對于你特定的DB2環境來說就是無效的。 ROT應該在你的環境中得到（或者是對其進行調整，使其適應你的環境）。它們應該與你的實際經驗相聯系，而不是被盲目接受，這樣你才會對它們的值有信心。從那些在你的非凡環境之外得到的ROT開始也許會有些幫助。但是當你從你的DB2系統中收集、分析、記錄了合適的數據之后，就需要對這些經驗值進行校正或者修改。IBM的紅皮書是一本有關ROT的值得閱讀的資源，里面含有許多關于性能監測工具的推薦經驗。 另一個要考慮的事項就是ROT需要持續一段時間。隨著硬件技術的發展，軟件編碼的改進，系統的體系結構發生了變化，這使得ROT更加不可靠，甚至是完全錯誤的。隨著時間的發展，使ROT發生改變的最大因素恐怕就是最新發布的DB2自身了。 DB2工作量 磁盤I/O通常是影響響應時間的最大因素，但是，通過查看GETPAGE (GP)需求可以更輕易地看到潛在的性能問題。當監測DB2的活動并進行報告分析的時候，GETPAGE的數量很可能就是顯示DB2整體工作情況的最好的指示器。 大部分的DB2安裝工作可以分為以下幾個較清楚的類別： 事務：這是運行在事務治理器控制之下的程序，例如CICS 和 IMS/TM。SQL通常比較簡單，但是事務卷是很繁重的。事務必須為用戶提供非常及時的響應時間，這樣應用程序才不會被迫等待很長的時間以獲得所需的資源。通常是第一個用戶調用事務時才會產生讀取索引和數據頁的I/O開銷。隨后的用戶可以在緩沖池中訪問部分資源。 上一頁123456789下一頁 查詢：這是通常情況下為決策支持運行的程序。其中的SQL也許十分復雜，但是卷通常要比事務的卷輕松許多。查詢用戶通常需要等待幾分鐘，甚至是幾個小時，具體時間依靠于產生用戶需要的結果集所查詢的數據量。查詢通常會調用針對整個表的掃描，并且對結果排序也是此類工作量的另一個常見特點。 批處理和實用工具集：批處理和實用工具集程序需要處理大量的數據，并且通常是以順序的方式處理數據。在特定的窗口中結束處理對于這些程序來說是很重要的。多次使用位置正確的COMMIT（提交）語句是這些應用程序具有的一個很重要的特點。批處理和實用工具集通常需要消耗大量的各類資源，進行壓縮的時候，通常可以逐步提高工作量。 標準化 標準化是應用程序進行數據實體分析的標準化過程，最終將把數據實體轉換為一系列經過良好設計的結構體。通常，邏輯數據模型的設計目標是正確性、一致性、沒有冗余和簡單化。而且，關系理論原則也需要數據庫進行標準化。 還有幾條連續編號的規則，被稱為范式，它可以相當具體地定義標準化數據。我在這里并不具體討論這些規則。大多數的專家都會建議設計者們盡力遵循前三條的規則，因此這樣的數據可被稱為遵循第三范式。 對表進行非標準化的意思是，對一個先前遵守范式的表進行修改，使其違反一條或者多條范式規則。有時候，由于性能的原因，確實需要進行這個非標準化的過程。有關標準化的更進一步的具體信息，你可以在大多數的講述關系數據庫的書籍中找到。 DB2表空間的類型 在定義DB2數據庫的時候，實際的表必須在被成為表空間的DB2對象中進行創建。用戶可以在DB2中定義四種不同類型的表空間，如下所示： 單一：一個單一的表空間可以包含多于一個的DB2表。這個空間由多個頁組成，每個頁都可以包含若干行，它們可能是來自表空間中定義的任何表的數據行。 上一頁12345678910下一頁 分段：分段表空間可以包含多于一個的DB2表。這個表空間由多組頁組成，每組頁被稱為一個段。每個段包含來自表空間中定義的某一個表的若干行。 分區：分區表空間只可以包含一個表。這個空間根據分區索引的要害值范圍被劃分成多個區。每個分區都作為一個獨立的實體對待，答應SQL和DB2實用工具集的并發處理。 LOB：LOB表空間只存儲LOB（大對象）數據。LOB包括了3個數據類型：BLOB（二進制大對象）、CLOB（字符型大對象），以及DBCLOB（雙字節字符型大對象）。表空間和表設計考慮事項 記錄尺寸和頁尺寸 固定長度的記錄比可變長度的記錄要好，因為處理固定長度記錄的DB2的代碼經過了優化。假如記錄是固定長度的，那么它就永遠不需要從原來存儲的頁中被移動出來。然而，可變長度的記錄可能增長到不再適合原來頁的長度，因此它也就必須被移動到另一頁。無論何時記錄被順序訪問，都一定會出現一個額外的參考頁。DB2 UDB V8中的一個新特性就是當你不確定未來的數據長度增長情況時，答應你根據需要改變列的尺寸，這樣你就可以不再需要創建可變長度的記錄。 每頁中記錄的數量也是需要考慮的內容。DB2提供了一些有關頁尺寸的選項，例如4 KB, 8 KB, 16 KB和32 KB 。比較好的起點是選擇默認的4KB，非凡是當行的尺寸相對較小，或者是對數據的訪問比較隨機的情況下。然而，在一些情況下，也需要考慮較大的頁尺寸。假如表中單個行的長度超過4KB，那么你就需要使用大一些的頁尺寸，因為DB2不支持跨行的記錄。 還有另一種情況是，當固定記錄的總長度比二分之一的頁（4KB）稍大一些的時候，一頁中就只能放置一個記錄。另外一種類似的情況是，固定記錄的總長度略長于三分之一頁、四分之一頁，等。這樣的設計不僅會浪費DASD空間，還會導致很多的DB2操作消耗更多的資源。因此，對于上面描述的記錄而言，你需要考慮使用較大的頁尺寸，這樣就會相對地少浪費一些空間。 上一頁234567891011下一頁 另外一些可能的頁尺寸為8 KB, 16 KB和 32 KB。頁的尺寸并不在創建表（CREATE TABLE）的語句中直接寫明。相反，表中頁的尺寸是由分配給包含這個表的表空間的緩沖池中的頁尺寸決定的。要獲得更具體的信息，你可以參考DB2 SQL 手冊中有關創建表空間（CREATE TABLESPACE）語句的內容。 非標準化考慮事項 邏輯數據模型是數據的一個理想描述。物理數據模型則是數據在現實世界的實現。標準化只集中在數據的內涵上面，而不考慮可能訪問數據的應用程序的性能需求。數據庫設計的充分標準化會帶來性能的挑戰。 有關此類性能問題的一個非經常見的例子就是連接操作。通常情況下，標準化過程的結果是給各個獨立的表賦予相互關聯的信息。應用程序需要從這些表中訪問數據。關系數據庫提供了使用SQL語句來從多于一個的表中通過連接多個表去訪問信息的能力。取決于表的數目和它們各自的尺寸，連接操作可能會消耗非常多的資源和時間。 因為在I/T中有如此多的事情需要考慮，于是出現了一個折中的想法。對那些包含被頻繁訪問列的多個表中的數據保存副本，與連接表的性能相比，成本高還是低呢？在邏輯數據庫設計過程中，對你的數據模型盡量的執行標準化，之后再對其進行一定程度的非標準化，也許是進行潛在性能優化的一個選項。假如你決定進行非標準化了，要確保從頭到尾地記錄了文檔：對某些細節的描述、執行非標準化步驟之后的推理，等。 設計較大的表 訪問很大的DB2表需要消耗相當多的資源：CPU，內存，I/O。當設計大表的時候，用戶需要做的兩件最重要的事情就是： 實現分區 創建有用的索引 以上兩個問題將在下面進行具體討論。 使用分段或者分區表空間 上一頁3456789101112下一頁 假如數據中包含了LOB，那么用戶就必須創建LOB表空間。對于非LOB的數據，通常的選擇是分段或者分區表空間，具體選擇哪一個在很大程序上取決于你要存儲的數據量，同時還需要考慮相關應用程序需求的數據訪問類型。不太推薦使用單一的表空間。 分段表空間比單一的表空間具有更多的性能優勢，如下所示： 對于包含多于一個表的表空間，當DB2在一個表上獲得鎖定時，那個鎖定不影響其他表分段的訪問。 當DB2掃描一個表時，只訪問與那個表相聯系的分段。此外，空分段的頁不會被取出。 假如一個表被清除了，不需要執行REORG實用工具集，它的分段就立即在COMMIT點上變成可再次使用的狀態。 假如一個表中的所有行被刪除了（被稱為塊刪除），不需要執行REORG實用工具集，所有的分段都立即在COMMIT點上變成可再次使用的狀態。 塊刪除操作起來更加有效，并且書寫相當少的記錄信息。 COPY（復制）實用工具集不復制由于塊刪除或者表清除所造成的空頁。 當表達到一個特定的尺寸，它們的可治理性和性能都可以通過分區表空間獲得改善。假如你想獲得這方面的進展，在設計和創建時，以分區的形式定義表空間是一個明智的做法。分區表空間的一些潛在優勢列舉如下： 并行性：你可以利用三種類型的并行性，它們目前正應用于DB2 UDB。DB2 V3引入了查詢并行性（多個I/O路徑）。DB2 V4則實現了CP并行性（多CP之上的多任務）。DB2 UDB V5更是引入了系統查詢并行機制（多個DB2數據共享群之上的多任務）。DB2的發展進化，顯著提高了DB2應用程序處理分區表空間的并行處理能力。由于CPU時間的增加，這些查詢所消耗的時間也顯著的減少了。 在數據的一部分上工作：分區表空間答應DB2應用程序一次運行數據的一個分區，因而使其能夠同時運行另外分區上的另外的工作或者應用程序。以同樣的方式，你可以將塊UPDATE（更新）、DELETE（刪除）或INSERT（插入）操作分解為獨立的工作。除增加了可用性之外，這一技術也為完成這類DB2工作減少消耗的時間提供了可能。 上一頁45678910111213下一頁 更快的訪問被頻繁訪問的數據：假如分區索引能夠將更多的頻繁訪問的行從剩余的表中分離出來，然后將那些數據置于一個它自己的，并且應用更高速DASD設備的分區之內。 一般而言，表越大，就越應該將其創建為一個分區的表。但是也有一些實際例子表明為小表創建分區表空間是有利的。當查找表用于連接其他大分區表空間時，通過將查找表分區，你能夠使并行性在連接中最大化。 當你在連接謂詞中利用分區方法時，需要考慮一個決定性的因素。被連接在分區方法上的表應該具有相同的分區數，并且應該設定為相同的值。 數據壓縮 DB2提供了壓縮表空間或分區內數據的功能。通過指定CREATE TABLESPACE（創建表空間）語句中的 COMPRESS YES（壓縮許可）選項，之后在表空間上同時執行LOAD或REORG實用工具集，即可完成該功能。數據的壓縮是通過用更短的串來替換頻繁出現的字符串實現的。系統還創建了一個字典，包含了原始字節串和它們的替代串之間的映射信息。 一定數量的CPU資源被用于在執行數據存儲對其進行壓縮，之后，當外部存儲設備讀取時，數據又被解壓縮。然而，數據壓縮也能夠提供性能方面的好處，因為更多的數據存儲在更小的空間內（在DASD上和緩沖池中）；同未經壓縮的數據相比，這樣可以產生更少的同時讀取、更小的I/O等。 接下來是當試圖決定是否壓縮一個表空間或分區時，需要考慮的一些事情： 行的長度：行越長（尤其是在接近頁的尺寸時），壓縮的有效性就越低。DB2的行不能夠跨頁，當一頁上有多于一行的情況時，你也許不能獲得足夠的壓縮。 表的尺寸：對于較大的表，壓縮具有較好的效果。對于很小的表，壓縮字典的大小（8KB到64KB）可能會抵消壓縮節省下的所有空間。 上一頁567891011121314下一頁 數據中的模式：對于一個特定的表空間或分區，數據中重復出現的模式的頻率，決定了壓縮的效果。含有大量重復字符串的數據能夠獲得顯著的壓縮效果。 壓縮估計：DB2提供了一個單獨的實用工具集，DSN1COMP，它可以用來測定數據壓縮將有怎樣的效果。想獲得有關運行該使用工具的額外信息，請參考DB2實用工具集指南和參考手冊。 處理成本：在壓縮和解壓縮DB2數據時，會消耗一些CPU資源。假如你用IBM的同步數據壓縮硬件特征，所消耗的CPU資源將比利用DB2軟件仿真程序低得多（當DB2啟動時，這決定了硬件壓縮特征是否可用）。 更好的字典：當用LOAD使用工具集來建立壓縮字典時，DB2用戶用最初載入的n行（n取決于你能夠壓縮的數據量）來決定字典的內容。REORG采用取樣技術來建立字典。它不僅使用最初載入的n行，還在實用工具執行UNLOAD（未載入）階段的剩余時間里繼續對數據行采樣。 通常情況下，我們推薦你在自己的特定環境下，壓縮那些DB2表空間和分區，這將會使你的環境受益；因為在更小的空間內存儲更多的數據的性能優勢，幾乎總是在價值上超過壓縮和解壓縮數據所消耗的CPU資源。 載入大表 在處理大批量數據時，將數據初始載入表中可能會對系統性能產生挑戰。為了在載入過程中實現并行性，你可以手動創建多個LOAD作業，每個分區建一個；或者作為另一個選擇，你可以在一個LOAD程序中載入多個分區。每個分區都延伸至I/O子系統，這種方式可以更輕易地實現最理想的并行性。 為了使性能最優化，在LOAD語句中指定SORTKEYS參數也很重要。這個參數指示DB2將索引方法傳遞給內存中的分類程序，而不是將要害字寫入或者再次讀取DASD上的排序任務文件。SORTKEYS也能夠實現載入和分類之間的交迭，因為分類是作為一個獨立的任務運行的。 上一頁6789101112131415下一頁