簡(jiǎn)介： 在開(kāi)發(fā)過(guò)程的早期作出的很多設(shè)計(jì)決定對(duì) DB2? 應(yīng)用程序和數(shù)據(jù)庫(kù)的性能有著巨大的影響。本文為在 z/OS? 環(huán)境中取得更好的性能提供了一些一般性的指南和建議。
發(fā)布日期： 2004 年 10 月 01 日
級(jí)別： 初級(jí)
訪問(wèn)情況 27 次瀏覽
建議: 0 (添加評(píng)論)
本文的目的是為 IBM? 業(yè)務(wù)伙伴提供關(guān)于 DB2 Universal Database? (UDB) for z/OS?（后面將簡(jiǎn)稱為 DB2）環(huán)境中 DB2? 數(shù)據(jù)庫(kù)性能的重要信息。本文試圖從多處收集材料，并盡可能有效地將它們表述出來(lái)。本文無(wú)意包含很全面的范圍，也不會(huì)包含很深的細(xì)節(jié)。
我曾打算討論對(duì) DB2 數(shù)據(jù)庫(kù)的性能影響最大的一些因素。但是，并不是所有可能的情形都可以預(yù)測(cè)到，也不是所有潛在的考慮都能顧及到，更不用說(shuō)在期望的范圍內(nèi)對(duì)它們進(jìn)行描述了。我希望本文可以為不同環(huán)境下的 DB2 用戶提供一個(gè)通用的指南，以幫助他們?nèi)〉米罴训?DB2 數(shù)據(jù)庫(kù)性能。本文的目的是成為一個(gè)良好的起點(diǎn)，用以處理任何給定安裝環(huán)境下的數(shù)據(jù)庫(kù)性能問(wèn)題。
本文的范圍是數(shù)據(jù)庫(kù)設(shè)計(jì)性能。DB2 性能遠(yuǎn)不止這一部分，它肯定要受到數(shù)據(jù)庫(kù)設(shè)計(jì)以外的很多因素的影響。例如，程序的編碼邏輯和其中使用的實(shí)際的 SQL 語(yǔ)句，可以列為應(yīng)用程序設(shè)計(jì)一類。DB2 系統(tǒng)性能可以包括諸如安裝選項(xiàng)、緩沖池大小設(shè)置、DB2 相關(guān)地址空間的調(diào)度優(yōu)先級(jí)等等之類的因素。
本文的焦點(diǎn)是 DB2 數(shù)據(jù)庫(kù)的設(shè)計(jì)。不過(guò)，有時(shí)候這些性能因素類別之間的界線可能會(huì)有些模糊。例如，在某種安裝環(huán)境下進(jìn)行配置時(shí)，緩沖池大小的設(shè)置和數(shù)量的選擇通常被認(rèn)為是一項(xiàng)系統(tǒng)性能因素。但是，倘若是將特定的表空間和索引指派給那些緩沖池，那么這些因素又可以看作是數(shù)據(jù)庫(kù)設(shè)計(jì)一類的因素了。
在這里，我假設(shè)讀者對(duì) z/OS 環(huán)境中的 DB2 有一個(gè)基本的理解。本文的頭幾頁(yè)將討論性能管理的一些基本概念和準(zhǔn)則，以便進(jìn)行"級(jí)別設(shè)置" 。我的建議有點(diǎn)綜合的性質(zhì)，因而不會(huì)總是詳細(xì)地給出技術(shù)性的描述和語(yǔ)法。讀者如果想了解關(guān)于這些內(nèi)容的更詳細(xì)的信息，那么應(yīng)該去閱讀關(guān)于用戶本地所安裝的 DB2 版本的最近的 IBM 文檔。
本文的通用設(shè)計(jì)點(diǎn)是 DB2 for z/OS V7。雖然 DB2 for z/OS V8 已經(jīng)被宣布，并且也普遍可用（generally available ，GA），但是大部分 IBM 客戶極有可能需要幾個(gè)月的時(shí)間才能實(shí)現(xiàn)用于他們的生產(chǎn)系統(tǒng)的 DB2 V8 NFM （New Function Mode）。而且，這里還要考慮另外一個(gè)因素。雖然 DB2 的每個(gè)新版本在變得普遍可用之前，都已經(jīng)在 IBM 及其客戶環(huán)境下經(jīng)過(guò)了廣泛的測(cè)試，但是相對(duì)于一個(gè)還沒(méi)有推廣的、沒(méi)有普遍使用的版本而言，客戶們往往對(duì)于基于早先版本的 DB2 的一般建議和竅門更有信心（長(zhǎng)時(shí)間積累的經(jīng)驗(yàn)驗(yàn)證了這一結(jié)論）。我將提到 DB2 V8 的一些新特性，從性能的角度來(lái)看，這些新性能可能會(huì)影響數(shù)據(jù)庫(kù)設(shè)計(jì)。
免責(zé)聲明：本文中所包含的信息未經(jīng)任何正式的 IBM 測(cè)試，而是以 AS IS 的形式發(fā)布的。對(duì)這些信息的使用和其中任何技術(shù)的實(shí)現(xiàn)，都由用戶承擔(dān)責(zé)任，并取決于用戶的能力去評(píng)價(jià)它們和將它們整合到客戶特有的操作環(huán)境。雖然 IBM 對(duì)于每一項(xiàng)都進(jìn)行了審查，以求特定情況下的正確性，但不能保證在其他情況下也能得到相同的或類似的結(jié)果。試圖將這些技術(shù)應(yīng)用于他們自身環(huán)境的用戶須自己承擔(dān)風(fēng)險(xiǎn)。
考慮應(yīng)用程序和數(shù)據(jù)庫(kù)的性能特性的時(shí)機(jī)是在那些應(yīng)用程序和數(shù)據(jù)庫(kù)的初期設(shè)計(jì)階段，也就是開(kāi)發(fā)過(guò)程的開(kāi)始階段。對(duì) DB2 應(yīng)用程序和數(shù)據(jù)庫(kù)所需的資源進(jìn)行合理的估計(jì)，這有助于用戶在開(kāi)發(fā)過(guò)程的早期便對(duì)設(shè)計(jì)和實(shí)現(xiàn)作出恰當(dāng)?shù)臎Q定。如果等到后期才來(lái)考慮訪問(wèn)數(shù)據(jù)庫(kù)的應(yīng)用程序的性能，那么為了取得適當(dāng)?shù)捻憫?yīng)時(shí)間和生成批處理窗口而進(jìn)行一些必需的修改時(shí)，就會(huì)更加困難，而且更加消耗時(shí)間。
當(dāng)從性能的角度進(jìn)行設(shè)計(jì)時(shí)，將大部分的精力集中在 重要DB2 數(shù)據(jù)和程序上，這種做法比較明智。在確定是什么應(yīng)用程序或事務(wù)構(gòu)成這一重要的工作負(fù)載時(shí)，以下特征中的一條或幾條將會(huì)適用：
數(shù)據(jù)庫(kù)的設(shè)計(jì)有兩個(gè)階段：
數(shù)據(jù)庫(kù)的邏輯模型僅僅是對(duì)用戶的所有數(shù)據(jù)需求的一種表示，它將這些需求變成一種范式。這種模型通常就是數(shù)據(jù)建模會(huì)議的輸出或最終結(jié)果。該模型實(shí)際上很少被原原本本地實(shí)現(xiàn)。其實(shí)，該模型只是在考慮如何實(shí)際地構(gòu)造數(shù)據(jù)和將數(shù)據(jù)存儲(chǔ)在 DBMS 之前，對(duì)數(shù)據(jù)的一種理想化的看法。
在對(duì)數(shù)據(jù)庫(kù)對(duì)象的架構(gòu)進(jìn)行了考慮之后，邏輯模型就被轉(zhuǎn)化為物理模型。在設(shè)計(jì)的這個(gè)階段，就需要較為詳細(xì)地考慮數(shù)據(jù)訪問(wèn)需求和性能因素。在產(chǎn)生物理設(shè)計(jì)的這個(gè)過(guò)程當(dāng)中，有兩大要素，即表設(shè)計(jì)和索引設(shè)計(jì)。下面將較為詳細(xì)地討論這兩個(gè)話題。
為了確保 DB2 應(yīng)用程序具備合格的性能，未雨綢繆勝于亡羊補(bǔ)牢。在設(shè)計(jì) DB2 數(shù)據(jù)庫(kù)的早期階段就將性能因素考慮進(jìn)來(lái)，這一點(diǎn)很重要。然后，在項(xiàng)目盡可能早的時(shí)候，建立一套符合 service level agreement (SLA) 的性能"基準(zhǔn)線"測(cè)量方法，這樣，便可以在展示的時(shí)候和應(yīng)用程序被修改的時(shí)候，跟蹤性能特性和趨勢(shì)。同時(shí)還應(yīng)該持續(xù)地監(jiān)控 DB2 系統(tǒng)和應(yīng)用程序，從而在大的問(wèn)題完全發(fā)作之前進(jìn)行預(yù)測(cè)。
通常，很多客戶只有到了應(yīng)用程序開(kāi)發(fā)項(xiàng)目的最后階段才開(kāi)始擔(dān)心性能。但是通常沒(méi)有什么好的理由需要等到那時(shí)才去考慮性能。更好的做法是，在指定了用戶界面和處理邏輯之后，立即考慮數(shù)據(jù)庫(kù)設(shè)計(jì)的性能特性。例如，在創(chuàng)建最佳索引時(shí)，應(yīng)該將 重要DB2 工作（請(qǐng)參閱前面的討論）中 SQL 語(yǔ)句的謂詞作為主要指南。
即使您可以開(kāi)發(fā)一個(gè)有效的初期設(shè)計(jì)，隨著數(shù)據(jù)量的增加，或者在系統(tǒng)資源緊缺的時(shí)候，也仍有必要對(duì)應(yīng)用程序和/或數(shù)據(jù)庫(kù)作出修改。如果一個(gè)應(yīng)用程序執(zhí)行時(shí)的性能不合格，較為可取的做法通常是添加更多的列到現(xiàn)有的索引中，或者為一個(gè)表添加新的索引，這種做法是首選。而更改表的設(shè)計(jì)，或修改用戶需求，抑或修改反規(guī)范化（de-normalizing）表，都不是很有吸引力的選擇。
Rules of thumb （經(jīng)驗(yàn)法則，也稱 ROT）在規(guī)劃、監(jiān)控和優(yōu)化 DB2 性能的時(shí)候很有用。ROT 通常是基于以前的經(jīng)驗(yàn)（比如在一段時(shí)間內(nèi)觀察到的平均值）或者更復(fù)雜公式的簡(jiǎn)化。
記住這樣一個(gè)事實(shí)很重要，即 ROT 只對(duì)于粗略的估計(jì)有用，而對(duì)于詳細(xì)的分析用處不大。如果只是在某一類的文檔中看到了一些 ROT，便欣然接受并作為精確的事實(shí)來(lái)引用，那么就會(huì)有危險(xiǎn)。在最好的情況下，這些 ROT 是一種估計(jì)，而在最壞的情況下，這些 ROT 對(duì)于特定的 DB2 環(huán)境可能不成立。
您應(yīng)該為自己的環(huán)境特別開(kāi)發(fā)這些 ROT（或者對(duì)它們進(jìn)行調(diào)節(jié)，以適應(yīng)自己的環(huán)境的特性）。應(yīng)確保 ROT 與實(shí)際經(jīng)驗(yàn)相關(guān)，而不是盲目地接受，這樣才能對(duì)它們更有信心。一開(kāi)始的時(shí)候，使用那些在您特定環(huán)境以外被使用過(guò)或者被開(kāi)發(fā)出來(lái)的 ROT，這種做法可能有用。但是，當(dāng)對(duì)您自己 DB2 系統(tǒng)中的適當(dāng)數(shù)據(jù)進(jìn)行收集、分析和編制文檔之后，應(yīng)該對(duì)這些 ROT 加以驗(yàn)證和修改。IBM Redbooks 是關(guān)于 ROT 的一種很好的參考資料，這些 ROT 常常作為建議被包括在性能監(jiān)控工具中。
另一方面的考慮是，ROT 可能隨著時(shí)間的推移而 演變。硬件技術(shù)的發(fā)展，軟件編程技術(shù)的提高，系統(tǒng)架構(gòu)的變化，諸如此類的變化都可能使得 ROT 的可靠性降低，甚至變得無(wú)效。而使 ROT 隨著時(shí)間變化的最大因素也許正是 DB2 本身新版本的發(fā)行。
磁盤 I/O 常常是影響響應(yīng)時(shí)間的最大因素，但是通過(guò)查看 GETPAGE (GP) 請(qǐng)求，更容易理解底層的性能問(wèn)題。當(dāng)監(jiān)控 DB2 活動(dòng)和分析報(bào)告時(shí)，GETPAGE 的數(shù)量也許是 DB2 總體工作負(fù)載的最好的指示器。
某個(gè)安裝環(huán)境下的很多 DB2 工作都可以無(wú)異議地歸為以下幾類：
規(guī)范化是分析應(yīng)用程序所需的數(shù)據(jù)實(shí)體，然后將這些數(shù)據(jù)實(shí)體轉(zhuǎn)化成一組設(shè)計(jì)良好的結(jié)構(gòu)的一個(gè)格式化的過(guò)程。邏輯數(shù)據(jù)模型的一般設(shè)計(jì)目標(biāo)是正確性、一致性、非冗余和簡(jiǎn)單性。而且，關(guān)系理論的信條也要求數(shù)據(jù)庫(kù)要經(jīng)過(guò) 規(guī)范化。
有一些按照連續(xù)編號(hào)排列的規(guī)則（也叫 范式（form））可以用來(lái)很詳細(xì)地定義規(guī)范化數(shù)據(jù)。大多數(shù)專家都會(huì)建議設(shè)計(jì)者盡量遵從前三條規(guī)則，由此得到的數(shù)據(jù)就可以說(shuō)是符合 第三范式。
而將一個(gè)表 反規(guī)范化（de-normalize）的意思是，違反該表之前遵從的一種或多種范式，從而修改規(guī)范化的設(shè)計(jì)。這種反標(biāo)準(zhǔn)化的過(guò)程常常是由于性能的原因而進(jìn)行的。在大多數(shù)以關(guān)系數(shù)據(jù)庫(kù)為主題的書籍當(dāng)中，都可以找到關(guān)于規(guī)范化的更詳細(xì)的信息。
在一個(gè)定義好的 DB2 數(shù)據(jù)庫(kù)中，實(shí)際的表必須在稱作 表空間（table space）的 DB2 對(duì)象中創(chuàng)建。用戶可以在 DB2 中定義 4 種不同的表空間：
固定長(zhǎng)度的記錄要優(yōu)于可變長(zhǎng)度的記錄，因?yàn)?DB2 代碼專門為處理固定長(zhǎng)度的記錄進(jìn)行優(yōu)化。如果記錄是固定長(zhǎng)度的，那么就無(wú)需將其從存儲(chǔ)它的初始頁(yè)面轉(zhuǎn)移到其他地方。而對(duì)于可變長(zhǎng)度的記錄，其長(zhǎng)度可能會(huì)變得不再適合初始頁(yè)，因此必須將其轉(zhuǎn)移到其他頁(yè)。之后，每當(dāng)需要訪問(wèn)該記錄時(shí)，就必須發(fā)生額外的頁(yè)引用。DB2 UDB V8 中的一種新特性允許在需要的時(shí)候修改（ALTER）某一列的寬度，這樣一來(lái)，即使您不能確定將來(lái)數(shù)據(jù)長(zhǎng)度的增長(zhǎng)情況，也不再需要?jiǎng)?chuàng)建可變長(zhǎng)度的記錄。
一個(gè)頁(yè)中所能存放的記錄的數(shù)目也是值得考慮的一個(gè)方面。DB2 為頁(yè)寬提供了很多選項(xiàng)（4 KB、8 KB、16 KB 和 32 KB）。一開(kāi)始的時(shí)候，可以選擇默認(rèn)選項(xiàng)（4 KB），如果行的長(zhǎng)度很小，或者對(duì)數(shù)據(jù)的訪問(wèn)基本上是隨機(jī)的，則更應(yīng)該選擇這一選項(xiàng)。不過(guò)，在有些情況下，則需要考慮使用更大的頁(yè)寬。如果一個(gè)表中各行的長(zhǎng)度要大于 4 KB，那么就需要使用更大的頁(yè)寬，因?yàn)?DB2 不支持 跨頁(yè)（spanned）記錄。
還有一些情況下，對(duì)于一條固定長(zhǎng)度的記錄，其總長(zhǎng)度可能剛好比 4 KB 的一半大一點(diǎn)點(diǎn)，這時(shí)一個(gè)頁(yè)只能容納一條記錄。對(duì)于剛好比頁(yè)寬的 1/3、1/4 大一點(diǎn)點(diǎn)的記錄，情形也是類似的。這種設(shè)計(jì)不僅浪費(fèi) DASD 空間，而且，對(duì)于很多 DB2 操作，還需要消耗更多的資源。因此，對(duì)于這一類的記錄，應(yīng)該考慮使用更大的頁(yè)寬，這樣浪費(fèi)的空間相對(duì)要少一些。
其他可能的頁(yè)寬是 8 KB、16 KB 和 32 KB。頁(yè)寬不是在 CREATE TABLE 語(yǔ)句中直接指定的。相反，表的頁(yè)寬是由相應(yīng)的緩沖池的頁(yè)寬來(lái)確定的，這個(gè)緩沖池也就是為包含該表的表空間所指定的緩沖池。要了解更多細(xì)節(jié)，請(qǐng)參考 DB2 SQL Reference手冊(cè)中的 CREATE TABLESPACE 語(yǔ)句。
邏輯數(shù)據(jù)模型是數(shù)據(jù)的 理想藍(lán)圖。物理數(shù)據(jù)模型才是對(duì)數(shù)據(jù)的 現(xiàn)實(shí)的實(shí)現(xiàn)。規(guī)范化只關(guān)注數(shù)據(jù)的意義，而沒(méi)有考慮對(duì)于訪問(wèn)數(shù)據(jù)的應(yīng)用程序的性能需求。完全規(guī)范化的數(shù)據(jù)庫(kù)設(shè)計(jì)在性能方面要受到質(zhì)疑。
這種性能問(wèn)題的最常見(jiàn)的例子是 連接（join）操作。通常，規(guī)范化過(guò)程最終將相關(guān)的信息放入不同的表中。于是應(yīng)用程序需要從多個(gè)這樣的表中訪問(wèn)數(shù)據(jù)。關(guān)系數(shù)據(jù)庫(kù)為 SQL 語(yǔ)句提供了從一個(gè)以上的表中訪問(wèn)信息的能力，這是通過(guò) 連接多個(gè)表來(lái)完成的。連接操作可能要消耗大量的資源和時(shí)間，這取決于表的數(shù)量以及這些表各自的長(zhǎng)度。
像 I/T 中的很多事情一樣， 這里也可以考慮一種權(quán)衡的方法。對(duì)于具有經(jīng)常被請(qǐng)求的列的多個(gè)表，一種是復(fù)制其中的數(shù)據(jù)，一種是執(zhí)行表連接，兩者誰(shuí)的成本更高呢？在邏輯數(shù)據(jù)庫(kù)設(shè)計(jì)過(guò)程中，您可以毫無(wú)保留地規(guī)范化數(shù)據(jù)模型，然后再加入一定程度的反規(guī)范化，作為潛在的性能調(diào)優(yōu)的一種選擇。如果您確實(shí)打算反規(guī)范化，那么一定要為此制作完整文檔：較詳細(xì)地描述您所采取的反規(guī)范化步驟背后的原因。
訪問(wèn)非常大的 DB2 表時(shí)，相應(yīng)地要消耗很多的資源：CPU、內(nèi)存 和 I/O。在設(shè)計(jì)大型表的時(shí)候，為了提高性能，用戶可以做的最重要的兩件事是：
下面將更詳細(xì)地討論這兩個(gè)話題。
如果數(shù)據(jù)包括 LOB，那么用戶就必須創(chuàng)建 LOB 表空間。對(duì)于非 LOB 數(shù)據(jù)，一般需要在分區(qū)表空間和分段表空間之間進(jìn)行選擇，這很大程度上取決于要存儲(chǔ)的數(shù)據(jù)量，在一定長(zhǎng)度上也取決于相關(guān)應(yīng)用程序所需的數(shù)據(jù)訪問(wèn)類型。簡(jiǎn)單表空間已經(jīng)很少被推薦了。
下面列出了分段表空間相對(duì)于簡(jiǎn)單表空間的一些性能優(yōu)勢(shì)：
當(dāng)表達(dá)到一定大小時(shí)，通過(guò)實(shí)現(xiàn)分區(qū)表空間可以提高易管理性和性能。如果預(yù)見(jiàn)到這樣的增長(zhǎng)，那么明智的做法是，在設(shè)計(jì)和創(chuàng)建表空間時(shí)將其定義為分區(qū)的。下面列出了分區(qū)表空間可以提供的一些潛在的優(yōu)勢(shì)：
通常，表越大，就越有理由將其創(chuàng)建為分區(qū)的表。但有時(shí)候?yàn)檩^小的表創(chuàng)建分區(qū)表空間也很有利。當(dāng)將 查找（lookup）表與其他較大的分區(qū)的表相連接時(shí)，通過(guò)將查找表也進(jìn)行分區(qū)，可以最大化并行度。
如果在連接謂詞中使用分區(qū)鍵（partitioning key），最后還有一點(diǎn)考慮需要顧及。需要按分區(qū)鍵進(jìn)行連接的表應(yīng)該有相同數(shù)量的分區(qū)，并且應(yīng)該在相同的值上 斷開(kāi)。
DB2 提供了壓縮一個(gè)表空間或分區(qū)中的數(shù)據(jù)的能力。這是通過(guò)在 CREATE TABLESPACE 語(yǔ)句中指定 COMPRESS YES 選項(xiàng)，然后對(duì)表空間執(zhí)行 LOAD 或 REORG 實(shí)用程序來(lái)實(shí)現(xiàn)的。通過(guò)用較短的字符串替換經(jīng)常出現(xiàn)的長(zhǎng)字符串，可以壓縮數(shù)據(jù)。這時(shí)會(huì)建立一個(gè)字典，其中包含了映射原始的長(zhǎng)字符串與它們的替換值的信息。
在數(shù)據(jù)被存儲(chǔ)之前壓縮數(shù)據(jù)，以及在從外部存儲(chǔ)設(shè)備讀出數(shù)據(jù)時(shí)將數(shù)據(jù)解壓，這都需要使用一定的 CPU 資源。但是，數(shù)據(jù)壓縮也可以為性能帶來(lái)好處，因?yàn)榭梢栽诟俚目臻g（包括 DASD 和緩沖池中的空間）中存儲(chǔ)更多的數(shù)據(jù)，與未壓縮的數(shù)據(jù)相比，這樣可以減少同步讀，減少 I/O 等。
在決定是否壓縮一個(gè)表空間或分區(qū)時(shí)，要考慮下面一些事情：
如果您的環(huán)境可以從壓縮中得到好處，通常我們建議壓縮那些 DB2 表空間和分區(qū)，因?yàn)橛捎诟倏臻g容納更多數(shù)據(jù)所帶來(lái)的性能優(yōu)勢(shì)幾乎總是大于壓縮和解壓數(shù)據(jù)時(shí)所需的 CPU 資源消耗。
當(dāng)處理大量的數(shù)據(jù)時(shí)，一開(kāi)始將數(shù)據(jù)裝載到表中時(shí)可能會(huì)遇到性能問(wèn)題。為了在裝載過(guò)程中實(shí)現(xiàn)并行性，可以手動(dòng)地創(chuàng)建多個(gè) LOAD 任務(wù)，每個(gè)分區(qū)對(duì)應(yīng)一個(gè)任務(wù)，或者，也可以在單個(gè) LOAD 實(shí)用程序中裝載多個(gè)分區(qū)。每個(gè)分區(qū)都展開(kāi)在 I/O 子系統(tǒng)上，從而更易于達(dá)到最佳的并行度。
為了獲得最佳性能，在 LOAD 語(yǔ)句中指定 SORTKEYS 參數(shù)也很重要。這將指示 DB2 將索引鍵傳遞給內(nèi)存中的排序程序，而不是再次將這些鍵寫到 DASD 上的排序工作文件中，然后從中讀取這些鍵。SORTKEYS 還允許裝載和排序之間的重疊，因?yàn)榕判蚴亲鳛橐粋€(gè)單獨(dú)的任務(wù)運(yùn)行的。
下面給出了關(guān)于裝載大型表的其他建議：
分配空余空間的主要目的是使數(shù)據(jù)行的物理順序與群集索引一致，以減少頻繁重組數(shù)據(jù)的需要。此外，對(duì)行的更好的群集會(huì)使讀訪問(wèn)的速度更快，行插入的速度也更快。然而，過(guò)多地分配空余空間可能會(huì)產(chǎn)生浪費(fèi)的 DASD 空間，導(dǎo)致每次 I/O 只能傳輸更少的數(shù)據(jù)，緩沖池的利用效率更低，并且要掃描更多的頁(yè)。
表空間和索引中空余空間的分配是由 CREATE 或 ALTER TABLESPACE 以及 CREATE 或 ALTER INDEX 語(yǔ)句的 PCTFREE 和 FREEPAGE 選項(xiàng)確定的。
PCTFREE 告訴 DB2 在裝載或重組數(shù)據(jù)時(shí)，表空間或索引中的每個(gè)頁(yè)要留出多少百分比的空余空間。如果沒(méi)有足夠的空余空間來(lái)按照 恰當(dāng)的順序（也就是按群集順序）編寫行或索引，那么 DB2 就必須將多出的數(shù)據(jù)放到另一個(gè)頁(yè)上。當(dāng)越來(lái)越多的記錄被亂序存放時(shí)，性能就會(huì)出現(xiàn)問(wèn)題。
FREEPAGE 告訴 DB2 在裝載或重組數(shù)據(jù)時(shí)，應(yīng)該過(guò)多久就分配一整頁(yè)的空余空間。例如，如果指定了 FREEPAGE 5，那么 DB2 將在用數(shù)據(jù)填充了 5 個(gè)頁(yè)之后分配一頁(yè)的空余空間。如果表行大于頁(yè)寬的一半，則應(yīng)該使用 FREEPAGE，因?yàn)樵谀菢拥沫h(huán)境下不能在一頁(yè)上再 INSERT 一行。
是否定義帶空余空間的表空間，以及分配多少的空余空間，這很大程度上取決于表空間中表的 INSERT 特征（其次是 DELETE 活動(dòng)）。換句話說(shuō)，這取決于將行添加到表中的頻率，以及將行添加到表的什么地方。下面有 4 種類別：
索引也是一種 DB2 對(duì)象（一個(gè)單獨(dú)的 VSAM 數(shù)據(jù)集），它由一組排好序的鍵組成，這些鍵是從相應(yīng)表中的一個(gè)列或多個(gè)列抽取出來(lái)的。很多 DB2 專家聲稱，只有為表空間建立恰當(dāng)?shù)乃饕?，才是使得訪問(wèn)該表空間中 DB2 數(shù)據(jù)的應(yīng)用程序的性能達(dá)到最佳、最有效的效果。數(shù)年前，在 I/T 中 DASD 的成本和空間是更重要的考慮因素。隨著技術(shù)的發(fā)展，通過(guò)增加更多的索引（或添加列到已有的索引中）來(lái)減少 I/O，以及由此消耗的額外磁盤空間，這幾年兩者之間的權(quán)衡已經(jīng)變得越來(lái)越有吸引力。索引所帶來(lái)的主要性能好處是：
在 DB2 UDB V7 中創(chuàng)建分區(qū)的表空間時(shí)，DB2 根據(jù) CREATE INDEX 語(yǔ)句的 PART 子句將數(shù)據(jù)劃分到幾個(gè)分區(qū)上。那樣的索引就成為所謂的分區(qū)索引，而這種分區(qū)的方法就被稱為 索引控制的分區(qū)（index-controlled partitioning）。對(duì)于分區(qū)索引，建議選擇不大可能改變的鍵列。如果對(duì)那些列進(jìn)行更新，則可能導(dǎo)致一行從一個(gè)分區(qū)轉(zhuǎn)移到另一個(gè)分區(qū)，從而降低了性能。
DB2 V8 一個(gè)重要的特性是 表控制的分區(qū)（table-controlled partitioning）。這時(shí)，當(dāng)創(chuàng)建分區(qū)的表時(shí)，分區(qū)的邊界由 CREATE TABLE 語(yǔ)句決定，而不是由 CREATE INDEX 語(yǔ)句決定。對(duì)于索引控制的分區(qū)方法，分區(qū)的表、分區(qū)索引和群集這幾個(gè)概念之間有點(diǎn)糾纏不清。而在表控制的分區(qū)方法中，這三個(gè)概念是各自獨(dú)立的。這種增加的靈活性使您可以考慮更多潛在的設(shè)計(jì)方案，因而也增加了提高 DB2 數(shù)據(jù)庫(kù)及其應(yīng)用程序性能的機(jī)會(huì)。
CREATE INDEX 語(yǔ)句使用戶可以立即建立索引，或者將索引的建立推遲到方便的時(shí)候。如果立即建立索引，則需要掃描表空間，這樣要花費(fèi)比較多的時(shí)間。通過(guò)指定 DEFER，則可以推遲索引的創(chuàng)建。
只要有可能，應(yīng)該在初次裝載一個(gè)表之前創(chuàng)建其所有索引，因?yàn)?LOAD 實(shí)用程序建立索引的效率比 CREATE INDEX 過(guò)程要高。如果需要在一個(gè)已有的（并且被填充的）表上創(chuàng)建一個(gè)索引，那么可以使用 DEFER 子句。然后可以在晚些時(shí)候使用 REBUILD INDEX 實(shí)用程序，這個(gè)實(shí)用程序與 LOAD 實(shí)用程序一樣，是更為有效的填充索引的方式。
DB2 UDB V5 中引入了一個(gè)新特性，這種特性使您可以將一個(gè)非分區(qū)索引（non-partitioning index，NPI）拆成 數(shù)塊，然后控制將組成索引空間的多個(gè)數(shù)據(jù)集的大小。通過(guò)使用這些小塊，可以使 NPI 的索引頁(yè)散步到多個(gè)數(shù)據(jù)集中。
通過(guò)在 CREATE 或 ALTER INDEX 語(yǔ)句中指定關(guān)鍵字 PIECESIZE，可以確定各塊的大小。PIECESIZE 的值必須是 2 的冪，其大小可以介于 256 KB 到 64 GB 之間。對(duì)于常規(guī)表空間，PIECESIZE 的默認(rèn)值是 2 GB，對(duì)于 LARGE 表空間，默認(rèn)值是 4 GB。如果 NPI 極有可能顯著增長(zhǎng)，那么應(yīng)選擇一個(gè)更大的值。在為主空間和輔助空間（CREATE INDEX 語(yǔ)句的 PRIQTY 和 SECQTY 選項(xiàng)）的分配確定值時(shí)，也應(yīng)該留意 PIECESIZE 的值。
通過(guò)使用這個(gè)選項(xiàng)，可以促進(jìn)并行性，從而提高 NPI 的掃描性能。另一個(gè)好處是可以減少在讀或更新的處理過(guò)程中對(duì) I/O 的爭(zhēng)用。通過(guò)指定一個(gè)較小的 PIECESIZE，可以創(chuàng)建更多的塊，從而對(duì)塊的放置有更多的控制。將這些塊放在不同的 I/O 路徑中，可以減少訪問(wèn) NPI 所需的 SQL 操作的爭(zhēng)用。
通過(guò)檢查應(yīng)用程序中的 SQL 語(yǔ)句，可以建立一種想象起來(lái)很好的索引。
在很多情況下，實(shí)現(xiàn)這一理想的代價(jià)太高，也不切實(shí)際，甚至是不可能的。對(duì)于一個(gè)索引中可以包括的列數(shù)，以及整個(gè)索引項(xiàng)的長(zhǎng)度，都有架構(gòu)上的限制（雖然這些限制已考慮到相當(dāng)大的索引項(xiàng)長(zhǎng)度和靈活性）。而且，也要考慮索引維護(hù)的成本。雖然建立理想化的索引可以顯著提高查詢性能，但是每當(dāng)對(duì) DB2 數(shù)據(jù)庫(kù)執(zhí)行 SQL 寫操作（INSERT、UPDATE 或 DELETE）時(shí)，上述理想化的索引都會(huì)有負(fù)面的影響。因此，您常?？梢赃x擇實(shí)現(xiàn)只包括在 WHERE 和 ORDER BY 子句中引用到的列的索引。
這些年，DB2 通過(guò)實(shí)現(xiàn)各種并行處理的方法，已經(jīng)大大提高了訪問(wèn)數(shù)據(jù)的性能。為了提高數(shù)據(jù)密集型只讀查詢的性能，DB2 V3 引入了查詢 I/O 并行。在這種并行中，DB2 充分利用分區(qū)表空間促成的可用 I/O 帶寬。通過(guò)這種方法，DB2 可以為單個(gè) I/O 請(qǐng)求啟動(dòng)多個(gè)并發(fā)的 I/O 請(qǐng)求，并在多個(gè)數(shù)據(jù)分區(qū)上執(zhí)行并行 I/O 處理。這通?？梢燥@著減少 I/O bound 查詢所需的時(shí)間，而代價(jià)只是稍微增加的 CPU 時(shí)間。
DB2 V4 引入了另一種并行技術(shù)，這種技術(shù)稱作查詢 CP 并行。這種方法將并行處理擴(kuò)展到過(guò)程密集型（process-intensive）查詢中來(lái)。通過(guò)這種方法，一條查詢可以使 DB2 生成多個(gè)任務(wù)，這些任務(wù)被并行地執(zhí)行，以訪問(wèn)數(shù)據(jù)。分區(qū)表空間最能體現(xiàn)這種并行所帶來(lái)的性能提高。
DB2 UDB V5 引入了 sysplex 查詢并行，進(jìn)一步擴(kuò)展了并行處理。CP 并行可以在 DB2 子系統(tǒng)中為一條查詢使用多個(gè)任務(wù)，而 sysplex 查詢并行這種方法使一個(gè) DB2 數(shù)據(jù)共享組中的所有成員可以一起處理一個(gè)查詢。對(duì)于那些主要是只讀形式的 I/O 密集型和處理器密集型查詢，都可以從這種并行中得到好處。
DB2 環(huán)境中對(duì)并行的支持有一個(gè)度的問(wèn)題。首先，在 DB2 子系統(tǒng)級(jí)，并行訪問(wèn)是在安裝面板 DSNTIP4 上控制的。DSNTIP4 上的 MAX DEGREE 選項(xiàng)決定了最大并行度（并行任務(wù)的最大數(shù)量）。默認(rèn)值是 0，這意味著對(duì)于 DB2 可能調(diào)用的并行度沒(méi)有上限。我建議您先估計(jì) z/OS 環(huán)境中的虛擬存儲(chǔ)能力和局限性，這樣 DB2 就不至于創(chuàng)建多于虛擬存儲(chǔ)所能處理的并行任務(wù)。
您可以通過(guò) BIND PLAN 和 BIND PACKAGE 命令的 DEGREE 選項(xiàng)來(lái)控制 DB2 是否利用并行處理。若指定 DEGREE(1)，表示禁止并行處理，若指定 DEGREE(ANY)，則表示支持并行處理。為獲得更大的靈活性，動(dòng)態(tài) SQL 允許通過(guò) SET CURRENT DEGREE 語(yǔ)句在一個(gè)計(jì)劃或包中更改這個(gè)選項(xiàng)，該語(yǔ)句可以控制專用寄存器中的值。
當(dāng)一個(gè)計(jì)劃或包與 DEGREE(ANY) 捆綁在一起，或者 CURRENT DEGREE 寄存器被設(shè)為 ANY 時(shí)，DB2 優(yōu)化器將考慮對(duì)于最有效的順序計(jì)劃，并行是否可行。如果并行不可行，那么就選擇次好的順序計(jì)劃。
限定分區(qū)掃描允許 DB2 將數(shù)據(jù)掃描限制在一個(gè)分區(qū)表空間中。根據(jù) SQL 謂詞中的值，DB2 可以判斷可能包含 SQL 語(yǔ)句所請(qǐng)求的表行的最低分區(qū)和最高分區(qū)，然后將數(shù)據(jù)掃描限制在這一范圍內(nèi)的分區(qū)中。為了使用這種技術(shù)，SQL 必須提供分區(qū)索引的第一個(gè)鍵列上的一個(gè)謂詞。
為了進(jìn)一步促進(jìn)并行處理所能帶來(lái)的性能提高，下面列出了一些需要考慮的事情：
很多專家將數(shù)據(jù)庫(kù)緩沖池看作 DB2 環(huán)境中影響性能的最關(guān)鍵的資源。很多 DB2 的架構(gòu)和設(shè)計(jì)，其基本思想都是盡可能地避免物理 I/O。
DB2 緩沖池由數(shù)個(gè) 插槽（slot）的連續(xù)的內(nèi)存組成。數(shù)據(jù)和索引頁(yè)被從 DASD 中讀出之后，便進(jìn)入這些插槽，并留在其中，直到 DB2 緩沖區(qū)管理器確定那些插槽要用于其他數(shù)據(jù)。應(yīng)用程序所請(qǐng)求的數(shù)據(jù)出現(xiàn)在內(nèi)存中（而不是外面的 DASD 上）的概率越大，總體性能就越好。實(shí)際上，這里的數(shù)據(jù)被重復(fù)使用，因而減少了應(yīng)用程序?qū)?I/O 的需要。
是否釋放一個(gè)緩沖池槽，這是根據(jù)最近被使用（LRU）原則來(lái)決定的。DB2 維護(hù)兩個(gè) LRU 列表，一個(gè)用于被隨機(jī)訪問(wèn)的頁(yè)，另一個(gè)用于被順序訪問(wèn)的頁(yè)。這樣可以防止大規(guī)模的表掃描完全支配緩沖池，并惡劣地影響隨機(jī)操作。通過(guò)使用不同的閾值，DB2 提供了改善緩沖池性能的靈活性。在 DB2 SQL Reference 手冊(cè)的第 2.7.4 節(jié)中對(duì)這些閾值進(jìn)行了較為詳細(xì)的討論。
為緩沖池設(shè)置適當(dāng)?shù)拇笮?/span>
緩沖池大小的指定要取決于可用存儲(chǔ)（包括中央存儲(chǔ)和擴(kuò)展存儲(chǔ)）的容量。我建議首先分析緩沖池的分配，然后逐漸增加緩沖池的大小，直到通過(guò)增加分配的空間已無(wú)法增加更多的吞吐量，或者直到 MVS 換頁(yè)率已難于接受為止。為實(shí)現(xiàn)這一點(diǎn)，要使 DASD I/O 的數(shù)量持續(xù)下降，并不斷增加 VPSIZE，直到換頁(yè)的成本超出了通過(guò)減少 I/O 所帶來(lái)的好處為止。
早些時(shí)候，GETPAGES 的數(shù)量被認(rèn)為可能是對(duì) DB2 正在運(yùn)行的工作量的最好度量。緩沖池的目的是減少 I/O（異步讀通常表明需要進(jìn)行預(yù)取，從性能角度來(lái)看，這樣做通常是值得的。另一方面，同步讀常常需要對(duì) DASD 進(jìn)行隨機(jī) I/O，因?yàn)楸徽?qǐng)求的頁(yè)不在緩沖池中）。會(huì)計(jì)報(bào)表顯示對(duì)應(yīng)于每個(gè)緩沖池的 GETPAGES 和同步讀的數(shù)量。一個(gè)被普遍接受的 ROT 聲稱，如果 GETPAGES 對(duì)同步讀的比率小于 10:1，那么應(yīng)該估計(jì)對(duì)更大緩沖池的需要。
如果操作系統(tǒng)允許為 DB2 緩沖池分配相當(dāng)大的內(nèi)存，那么使用多緩沖池的配置很可能可以提高特定應(yīng)用程序或數(shù)據(jù)庫(kù)的性能。然而，需要清楚的是，若有了多個(gè)緩沖池，那么對(duì)這些緩沖池使用效率的監(jiān)控就變得更加重要。
下面給出了關(guān)于分配多個(gè)緩沖池的一般建議：
考慮周詳?shù)臄?shù)據(jù)庫(kù)設(shè)計(jì)可以提供巨大的性能收益，但是這必須在應(yīng)用程序開(kāi)發(fā)過(guò)程的早期便開(kāi)始著手。從早期的 DB2 開(kāi)始，明智的開(kāi)發(fā)人員就已經(jīng)使用了前面提到的很多準(zhǔn)則，這些準(zhǔn)則直到現(xiàn)在也仍然成立。但是，DB2 功能的增強(qiáng)、其他領(lǐng)域中硬件和軟件技術(shù)的變化將影響當(dāng)前和將來(lái)的應(yīng)用程序，知道這一點(diǎn)至關(guān)重要。當(dāng)數(shù)據(jù)庫(kù)性能成為開(kāi)發(fā)過(guò)程中的焦點(diǎn)時(shí)，您的數(shù)據(jù)庫(kù)設(shè)計(jì)使得為 DB2 應(yīng)用程序提供最佳性能有了更大的可能性。
聯(lián)系客服
