2009 年 9 月 24 日

物 理數(shù)據(jù)庫設(shè)計是影響數(shù)據(jù)庫性能的一個最重要的因素。物理數(shù)據(jù)庫設(shè)計涵蓋了所有和數(shù)據(jù)庫物理結(jié)構(gòu)相關(guān)的設(shè)計功能，比如表規(guī)范化和反規(guī)范化、索引、物化視圖、 數(shù)據(jù)集群、多維數(shù)據(jù)集群、表（range）分區(qū)還有數(shù)據(jù)庫（hash）分區(qū)。本文從MDC、數(shù)據(jù)庫分區(qū)、視圖以及后設(shè)計工具方面闡述物理數(shù)據(jù)庫設(shè)計最佳實 踐。

數(shù)據(jù)集群和 MDC 最佳實踐

MDC 是一個同時有不止一個維度數(shù)據(jù)集群的技術(shù)。然而，你也可以對一個維度使用 MDC 集群，就像你可以使用一個集群索引一樣。 MDC 的一個好處是它能保證數(shù)據(jù)一直處于集群狀態(tài)，永遠不需要執(zhí)行一個重組操作來重新建立較高的集群命中率。

而 且，不同于用 CREATE INDEX 語法創(chuàng)建的傳統(tǒng)索引，MDC 是對表中的每一行建立索引，MDC 通過塊把表中的數(shù)據(jù)編入索引。每個塊和表所在的表空間中的擴展數(shù)據(jù)塊有相同的大小。當(dāng) CREATE INDEX 命令創(chuàng)建索引時，每一行數(shù)據(jù)頁會同時被編入索引，每個 MDC 表索引 BLOCKS 可以包含上千條數(shù)據(jù)。 MDC 索引，也叫 BLOCK INDEX，通常只有 1/1000 大小基于索引的行，而且不光為索引提供了大量的保留存儲空間，同時也為所有 BLOCK INDEX 操作（索引掃描、索引 ANDing、索引 ORing，等等）提供了非常好的性能。

要理解 MDC，你必須首先理解一些基礎(chǔ)術(shù)語：單元是表容納數(shù)據(jù)的部分，它有一套唯一的維度值 ，是每個維度切片相交形成的。塊是存儲單元等于一個擴展數(shù)據(jù)塊（一個或多個頁面），塊被用來存儲一個單元。

MDC 表的塊索引

如 上面所述，除了它們指向的是塊而不是記錄，塊索引在結(jié)構(gòu)上和普通索引是一樣的。塊索引比普通索引要更小，因為塊大小是一個頁面中的平均記錄數(shù)的數(shù)倍。如圖 4 中所示，同每一行每一個單獨的輸入相比，在一個塊索引中每塊都有一個單獨的索引。結(jié)果就是，一個塊索引顯著降低了磁盤使用率并明顯加快了數(shù)據(jù)訪問的速度。

圖 5 中顯示的 MDC 表示一個物理組織，比如所有記錄有相同的“ Region ”以及“ Year ”值都同每個塊或擴展數(shù)據(jù)塊中連在一起。

甚至一個只定義一個維度的 MDC 表也可以從這些 MDC 屬性中獲益，而且可以替換一個有集群索引的普通表。這個決定應(yīng)該基于很多因素，包括組成工作負載的查詢以及表中數(shù)據(jù)的性質(zhì)和分布。

在插入操作過程中自動維護集群

在 MDC 表中自動維護數(shù)據(jù)集群確保了使用復(fù)合塊索引。這些索引被用來根據(jù)在 INSERTS 操作過程中的表的維度來動態(tài)管理和維護數(shù)據(jù)庫的物理集群。當(dāng)一個插入發(fā)生了，合成塊索引將會在與被插入記錄的維度值相應(yīng)的邏輯單元中被探測到。

如圖 6 所示，在索引中的邏輯單元的鍵值，它的塊 ID（BIDs）的列表完整的給出了表中有這個本地單元維度值的塊列表。這限制了給插入記錄搜索可用空間的表的擴展數(shù)據(jù)塊的數(shù)目。

因 為集群是自動維護的，所以對 MDC 表來說不需要重組操作來重新集群數(shù)據(jù)。然而，重組仍然被用來釋放空間。例如，如果單元有很多分散的塊，數(shù)據(jù)很少能夠匹配到，或者，如果表有很多指針溢出， 這個表的重組操作將壓縮屬于邏輯單元的記錄到最少的塊中，用時也刪除指針溢出對。

使用 MDC 的益處

MDC 的意義非常深遠。在某些情況下它能將復(fù)雜查詢的性能提高 10 倍以上，同時你還可以用它轉(zhuǎn)入和轉(zhuǎn)出數(shù)據(jù)。還有下面顯示的其他好處：

• MDCs 是多維的。例如，數(shù)據(jù)可以根據(jù) DATE 和 LOCATION 維度完美集群；單元和范圍在新數(shù)據(jù)插入的時候會被自動創(chuàng)建。
• MDCs 能和普通基于 RID 的索引、范圍分區(qū)和 MQTs 聯(lián)合使用。
• MDCs 和內(nèi)部查詢并行性、DPF（不共享）并行性、LOAD、BACKUP 和 REORG 操作同時使用。
• MDC 維度，和范圍分區(qū)表不同，它是動態(tài)的；它會在表中自動創(chuàng)建新的單元，因為新單元是表示通過 SQL 操作（包括 JDBC、CLI，等等）或通過使用工具操作（比如 LOAD 和 IMPORT）插入的新的唯一數(shù)據(jù)。
• MDCs 維護集群，而且正因為這樣就不需要 REORGs 來維護集群命中率了。

下面的例子顯示了如何定義一個 MDC 表：

CREATE TABLE T1 (c1 DATE, c2 INT, c3 INT, c4 DOUBLE,
                    c5 INT generated always as (INT(C1)/100) )
                    ORGANIZE BY DIMENSIONS (c5, c3)
                    

ORGANIZE By 子句定義了集群的維度。這個表同時在 C5 和 C3 上被集群。 C1 是 coarsified C5，它包含很少的不同值（天減少為月）。

注意：由 coarsified 產(chǎn)生的 columns(s) 被使用在 MDC 塊索引中，以提高單元級別的數(shù)據(jù)清除。

MDC 設(shè)計的一個關(guān)鍵是謹(jǐn)慎選擇集群的維度。如果你選擇的集群維度產(chǎn)生太多的單元，存儲的成本會顯著的增加。知道其中的原因非常重要。在一個 MDC 表中，每個單元都會根據(jù)需要的存儲塊來分配。存儲塊是設(shè)計為和表所在表空間的擴展數(shù)據(jù)塊的大小相等。如果一個單元沒有數(shù)據(jù)，那么存儲塊的數(shù)據(jù)是 0 。然而，在一個單元中存儲了若干記錄的典型表中會造成給單元分配一個或多個存儲塊。對每個有數(shù)據(jù)的單元都會有一批通常只包含了被部分填充數(shù)據(jù)塊。因此，在 每個單元（不是數(shù)據(jù)塊）中造成浪費和存儲塊的大小成比例。新數(shù)據(jù)庫只有個在前面的數(shù)據(jù)塊被填滿（或快滿）后被創(chuàng)建。如果行被刪除，數(shù)據(jù)庫管理器會嘗試盡可 能多的重用空間。

存儲塊被設(shè)計為同這個表所在表空間的擴展數(shù)據(jù)塊大小相等。如果這個表的單元數(shù)目非常大，存儲的浪費也會很大。如 果 MDC 很差而且產(chǎn)生了大量的單元，表的存儲需求會非常顯著的增加，而且 MDC 的性能也會受損。然而，設(shè)計的 MDC 表只會比非 MDC 表大一點，而且在集群和數(shù)據(jù)轉(zhuǎn)入轉(zhuǎn)出上提供了較大的好處（將在后面討論）

圖 7 顯示存儲塊和單元分配。如圖所示，每個單元都包含了一批存儲塊。絕大多數(shù)塊被數(shù)據(jù)填充，不過對于每個單元的最后一個塊，卻是或多或少被部分填充的。

如果你有樣本數(shù)據(jù)或具體數(shù)據(jù)，你就可以使用 SQL 來為所有可能的 MDC 設(shè)計度量 MDC 需要的單元數(shù)目，如下所示：

SELECT COUNT(*) FROM (SELECT DISTINCT COL1, COL2, COL3 FROM MY_FAV_TABLE) AS NUM_DISTINCT;

對一個 3 維的 MDC 表來說，COL1、COL2 和 COL3 是 MDC 的維度。結(jié)果數(shù)乘以表的擴展數(shù)據(jù)塊大小將得出一個在表被轉(zhuǎn)換為 MDC 過程中擴展數(shù)據(jù)塊增長（不是大小）的上限。

MDC 的其他核心價值是 DB2 數(shù)據(jù)庫管理器在表的 MDC 維度上自動為 MDC 表創(chuàng)建索引。這些特殊的索引對塊而非行建立索引，這是可行的。因為在 MDC 表中數(shù)據(jù)會一直保持集群，因此在相同塊中的所有的行同樣確保有相同的鍵值。這是由于在 MDC 中數(shù)據(jù)是對塊進行索引而非記錄，所以塊索引通常是傳統(tǒng)基于行的索引的 1/1000 大小。結(jié)果就是在相關(guān)查詢運行時的性能好處，并把 INSERT、UPDATE 和 DELETE 操作的開銷減到了最少。

MDC 提供的功能方便了數(shù)據(jù)的轉(zhuǎn)入和轉(zhuǎn)出。索引條目指向一個塊而不是一行，塊索引又比典型的（rowID）RID 索引要小很多。因此，當(dāng) MDC 在轉(zhuǎn)入處理時只有很少的塊索引 I/O，這是因為塊索引只在塊被寫滿的時候被更新一次（而不是每一行插入）。由于 MDC 重用已經(jīng)存在的空塊不需要分頁，所以插入也很快。插入時加的鎖也少了，因為他們發(fā)生在一個塊級別而不是行級別。表在轉(zhuǎn)入和轉(zhuǎn)出后不需要 REORG 數(shù)據(jù)。

MDC 存儲場景

想要為一個傳統(tǒng)事實表基于 Date、Product Name 和 Region 創(chuàng)建一個 MDC 。這里有一些在創(chuàng)建 MDC 時需要考慮的變量：

• 一年有 365 天。
• XYZ 公司有 100,000 個產(chǎn)品。
• XYZ 公司有 10 個區(qū)域。

開始創(chuàng)建 MDC

如果 MDC 直接創(chuàng)建在 Date， Product 和 Region 列上，每天將會產(chǎn)生 1,000,000 個新的單元（1 x 100,000 x 10），而每年則會產(chǎn)生 365,000,000 個單元。

如果區(qū)域中事務(wù)非常少，這將會有很多分散甚至是空的頁面。這會導(dǎo)致大量沒有必要的空間分配數(shù)量巨大的單元（頁面）用來容納塊數(shù)據(jù)。這非常不好。

開始 MDC 的創(chuàng)建

使用函數(shù)來 coarsify 和限制 MDC 的基數(shù)，例如：

• 如果你在 Date 上使用月份函數(shù)，那么每年你會有 12 條記錄。
• 如果你截取 Production Name 來挑出產(chǎn)品名稱的第一個字母，你就會有 26 條可能的結(jié)果。
• 保留 Region 的 10 個結(jié)果。

使用這個場景中的建議，MDC 將會每年產(chǎn)生 12*26*10 = 3210 個單元或每天 8-9 個單元。這會消除很多頁面沒有數(shù)據(jù)的情況，并對 MDC 提供合理的基數(shù)來獲得性能的好處。

MDC 運行時的開銷 / 收益

MDC 是設(shè)計來為查詢和許多刪除場景提供極大性能好處。雖然如此，在對使用了集群索引的集群表提供顯著的性能好處的同時，MDC 表這么做所帶來的開銷還是超過了非集群表。 MDC 和非集群表相比第一個開銷是：

• 在一個非集群表上的 INSERT 操作，不需要通過索引訪問來判斷記錄被存放在磁盤的什么位置。相比之下在 MDC 表上，在選擇哪個塊中有空間存放插入的記錄之前，需要通過訪問 MDC 復(fù)合塊索引來判斷記錄屬于哪個單元。
• 如果 MDC 表包括一個產(chǎn)生的列來 coarsify 其中的一個維度，每個 INSERT 將引起很少的處理開銷來為這一列計算生成值 , 就像 DB2 中的所有生成列一樣被物化，也就是被計算出來然后填充在記錄中。

然而，當(dāng)和使用集群索引而集群起來的表相比較的話，MDC 有著顯著的性能優(yōu)勢：

• 與 一個集群索引相比，索引維護可以顯著的減少 INSERTs，因為 DB2 數(shù)據(jù)庫管理器僅只有在第一個鍵值添加到塊中時的時候才更新塊索引——不像一個 RID 索引，每一行插入表中都需要對索引進行更新。也就是說，如果每塊有 1000 條記錄，索引更新率就是 RID 索引更新率的 1/1000 。
• 索引更新也非常廉價，因為索引更小而且因此所以在樹中有更少的層。在 B+ 樹中有更少的層次，則意味著需要更少的處理來為索引插入判斷目標(biāo)的葉子節(jié)點。

無 論使用集群索引還是用 MDC 來進行索引，在這兩種情況下 DB2 數(shù)據(jù)庫管理器都將在 INSERT 到目標(biāo)記錄的位置時訪問索引（塊索引的集群索引），并在 INSERT 過程中判斷記錄的目標(biāo)位置。再強調(diào)一下這個索引非常小，而且樹的高度通常很短，因此搜索速度非?？臁?/p>

判斷什么時候使用 MDC，什么時候使用集群索引

MDC 的價值要比集群索引高很多，因為它可以自動保證集群。根據(jù) coarsification 的需求，MDC 的集群率通?？梢赃_到 93%-100% 之間的某個值。相比之下，集群索引雖然可以在一開始就接近 100%，但是隨著時間的推移卻會變得不集群，因而需要花費時間來對數(shù)據(jù)重新集群。一般情況下，使用 MDC 在你的數(shù)據(jù)庫上創(chuàng)建和維護數(shù)據(jù)集群，除非：

• MDC 需要 coarsification，而且你不能將一個生成列添加到你的表中。
• 你不能也不需要在表增長過程中將表的結(jié)果生成 MDC 版本。良好設(shè)計的 MDC 表一般比非 MDC 表大 2-15% 。
• 你會發(fā)現(xiàn)，由于 coarsification 的原因，MDC 集群將提供稍小的集群率（例如，93%）。而使用集群索引的話，為了提高集群率你需要周期性的執(zhí)行 REORG 來達到這個比率。

使用下面的 MDC 設(shè)計的最佳實踐：

• 從找出等于、不等、范圍和排序謂詞使用的列開始，請選擇出你的 MDC 候選列。維度必須匹配你的轉(zhuǎn)入范圍才能提高數(shù)據(jù)轉(zhuǎn)入效率。
• 記住，要爭取密度！為每個已經(jīng)存在的單元分配一個擴展數(shù)據(jù)塊 – ——不管單元中有多少條記錄。這樣可以通過最優(yōu)的空間利用率來增強 MDC，盡量高密度的填充數(shù)據(jù)塊。
• 控制表的膨脹。保持盡可能低的單元數(shù)目并限制存儲擴展。 5% 到 10% 的增長對任何單個表都是合理的范圍（本文在下面章節(jié)討論 MDC 單元），但是也有例外，甚至也有兩倍于平常的增長，不過很少。

注意：BLOCK 索引與相應(yīng)的表相比非常的小，在大多數(shù)情況下，你可以忽略它們的存儲需求。

• Coarsify 一些維度來提高數(shù)據(jù)的密度。使用生成列來 coarsifications 表中基數(shù)非常少的列。例如，基于日期列的一部分 month-of-year 上創(chuàng)建一列，或使用（INT（列名））/100 來把 DATE 列從 Y-M-D 格式轉(zhuǎn)換成 Y-M 。
  

  CREATE TABLE Sales (SALES_DATE DATE, REGION CHAR(12), PRODUCT CHAR(30), … MONTH GENERATED ALWAYS AS ((INTEGER(DATE)/100) … ORGANIZE BY (MONTH, REGION, PRODUCT)

  
  

  查詢：

  select * from sales where sales_date> ” 2006/03/03 ” and date< “ 2007/01/01 ” ..

  
  

  編譯器會生成附加的謂詞：

  month>=200603 and month<=200701

  
  

  為了減少空間浪費，可以指定一個更小的表空間擴展數(shù)據(jù)塊，這會減少你的 MDC 塊大小。

• 不要選擇太多的維度。很少有設(shè)計能在 MDC 有 3 個以上的維度卻不產(chǎn)生過多的存儲需求。
  

  你擁有的維度越多，單元基數(shù)就會以指數(shù)級相應(yīng)的增長。這使得控制表膨脹率 10% 的設(shè)計目標(biāo)變得幾乎不可能實現(xiàn)。如果表過度膨脹（例如超過兩倍大?。┎粌H需要更多的存儲，同時也會因為部分填充塊的 I/O 增加而使集群失去優(yōu)勢。

  一個簡單的例子：考 慮一個有三個維度適合集群的表，每個有 10,000 唯一值。如果這些列彼此之間沒有相互關(guān)聯(lián)，那么對所有三個維度的集群就沒有 coarsification，這會產(chǎn)生 10,000 x 10,000 x 10,000 個單元，每個單元有一個部分填充塊。如果每塊是 1MB，那么這個設(shè)計上的疏忽產(chǎn)生的代價就將是 500,000TB ！

• 考慮只有一個維度的 MDC 。和傳統(tǒng)單維度集群索引相比，單個維度的 MDC 仍然有相當(dāng)多的優(yōu)點。有如下理由：
  • 集群是有保證的。
  • MDC 表中的索引是用block創(chuàng)建的，而非row。這種索引大小只有傳統(tǒng)基于行的索引的 1/1000 。
  • 用 MDC 轉(zhuǎn)出數(shù)據(jù)，提高了 DELETE 性能。 DB2 9.5 中在 MDC 上的 RID 索引更新是異步的。
  • MDC 可以很方便的轉(zhuǎn)入數(shù)據(jù)。
  • 使 用單維 MDC（如果需要可以 coarsification）強制進行集群來替代集群索引。集群索引需要付出很大的努力（不能保證集群質(zhì)量）來集群數(shù)據(jù)，而且隨著時間的推移，數(shù)據(jù)將變 得不再集群。與之相比，MDC 保證了數(shù)據(jù)集群性，避免了重組數(shù)據(jù)的需求（見上面“ MDC Scenario ”章節(jié)中的 coarsification）。
• 準(zhǔn)備修補（在一個測試數(shù)據(jù)庫上）。在尋找一個好的 MDC 設(shè)計過程中，可能需要嘗試也可能會失敗。可以使用帶有– m C 選項（C 是集群搜索）的 DB2 設(shè)計顧問程序。也可以使用 db2mdcsizer 實用工具，這在某個 DB2 產(chǎn)品版本的 AlphaWorks 中提供。 MDC 的修改不會影響你的應(yīng)用程序編程。
• 對一個有代表性的工作負載使用 DB2 設(shè)計顧問程序的 MDC 選擇能力來為現(xiàn)有表找出恰當(dāng)?shù)?MDC 維度。

回頁首

數(shù)據(jù)庫分區(qū)（不共享 hash 分區(qū)）的最佳實踐

數(shù)據(jù)庫分區(qū)是一個在數(shù)據(jù)庫中跨多個彼此合作的實例以建立單個大型數(shù)據(jù)庫服務(wù)器的水平分布記錄的技術(shù)。這些實例可以位于一個服務(wù)器中、跨多個物理機器、或它們的組合。在 DB2 產(chǎn)品中，這個叫數(shù)據(jù)庫分區(qū)功能（DPF）。

數(shù) 據(jù)庫分區(qū)允許 DB2 數(shù)據(jù)庫管理器擴充到上百個實例參與的大型數(shù)據(jù)庫系統(tǒng)。這個設(shè)計的可伸縮性能使很多復(fù)雜查詢的工作負載達到線性增長。這樣，因為數(shù)據(jù)庫分區(qū)接近線性的擴展特 征以及數(shù)據(jù)規(guī)模能達到數(shù)百 T 以及上百個 CPUs，數(shù)據(jù)庫分區(qū)在數(shù)據(jù)倉庫和 BI 工作負載下變得非常流行。由于每個事物都會產(chǎn)生實例內(nèi)部的通訊，而這即使很少卻也能嚴(yán)重影響在 OLTP 工作負載中常見的短期執(zhí)行事務(wù)類型，因此這個架構(gòu)在 OLTP 處理上用的較少。

不共享 hash 分區(qū)是把記錄 hash 分布到邏輯數(shù)據(jù)分區(qū)上。 Hash 分布的主要的設(shè)計目的是確保數(shù)據(jù)均勻分布到所有邏輯節(jié)點（因為范圍分區(qū)容易發(fā)生數(shù)據(jù)傾斜）。這些分區(qū)可能存在于一個服務(wù)器中或者分布到一批物理機器上，如圖 9 所示：

不 共享數(shù)據(jù)庫的擴展性已經(jīng)在大多數(shù)查詢工作負載接近于線性的擴展上得到了證明。同樣，模塊化的設(shè)計讓使它的存儲壓力、工作壓力或它們兩個也都線性增長。結(jié)果 就是在過去十年中不共享結(jié)構(gòu)在數(shù)據(jù)倉上的統(tǒng)治地位。數(shù)據(jù)庫分區(qū)可以在不影響現(xiàn)有應(yīng)用代碼的情況下使用，而且對它們是完全透明的。使用 redistribution 實用工具，可以在線更改分區(qū)策略而應(yīng)用代碼不會受到影響。

最主要的選擇就是決定哪些列用來 hash 分割每個表，并且這些列包含數(shù)據(jù)庫分區(qū)鍵值。這有兩個目標(biāo)：

1. 在各個分區(qū)間均勻的分布數(shù)據(jù)。這要求選擇那些高基數(shù)值的列為分區(qū)鍵，以確保所有行能均勻的分布到各個邏輯分區(qū)上。
2. 把在 join 處理中數(shù)據(jù)庫分區(qū)之間的數(shù)據(jù)傳輸減少到最小。如果在 WHERE 子句中包含分區(qū)鍵，那么將對被連接的行的表并置（避免移動數(shù)據(jù)）。

使用下面的數(shù)據(jù)庫分區(qū)的最佳實踐：

• 選擇用大量值（高基數(shù)）作為分區(qū)鍵，以確保表中的行能均勻的分布到各個分區(qū)。唯一鍵是一個很好的候選。
• 為了提高表并置，可以對一個經(jīng)常進行連接的表使用分區(qū)鍵作為連接列（假如這些列有很高的基數(shù)來滿足均勻分布行的需求）。
• 選擇能獲得高基數(shù)并能在分區(qū)鍵中均勻分布行的最小的列數(shù)。減少分區(qū)鍵中的列數(shù)提高了列出現(xiàn)在連接謂詞中的可能性（提高表并置的幾率）。
• 確保唯一索引是分區(qū)鍵的超集。
• 對小表（表大小只有或不到數(shù)據(jù)庫大小的 3% 或不到最大的表的 5% ，是一個合理的法則）或經(jīng)常被更新的表，使用復(fù)制 MQTs ，目的是：
  • 提高表并置和減少網(wǎng)絡(luò)間的數(shù)據(jù)移動。
  • 有助于在連接中的表并置
• 允許提前計算表中的值，從而提高在一個分區(qū)數(shù)據(jù)庫環(huán)境中經(jīng)常執(zhí)行連接的性能。
  

  例如：

  CREATE TABLE R_EMPLOYEE AS ( SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT FROM EMPLOYEE ) DATA INITIALLY DEFERRED REFRESH IMMEDIATE IN REGIONTABLESPACE REPLICATED;

  
  

  要更新復(fù)制物化查詢表中的內(nèi)容，可以運行下面的語句：

  REFRESH TABLE R_EMPLOYEE;

  
  

  注意：在使用 REFRESH 語句后，你應(yīng)該在復(fù)制表中運行你在其他表中運行的 RUNSTATS 語句。

• 考慮到不同的值和在相應(yīng)實施表的列中的數(shù)據(jù)傾斜，應(yīng)該把最大的維度和事實表進行并置。
• 復(fù)制小的維度，這里“ small ”是相對的，而且是基于安裝的可用存儲。
• 復(fù)制一個水平的或者垂直的維度子集：
  • 將主鍵上剩余的所有維度進行分區(qū)。
  • 在為了提高表并置而創(chuàng)建了一個復(fù)制表后，不要忘了收集表和索引的統(tǒng)計信息（或者使用 DB2 自動收集統(tǒng)計信息功能）。不要忘了在復(fù)制 MQT 表中實現(xiàn)與你在基礎(chǔ)表中定義相同的索引。
  • 如果他們很小而且很少被更新，就定義復(fù)制 MQTs 為 REFRESH IMMEDIATE 。否則就使用一個延遲更新策略。
• 把大型表分布在多個分區(qū)上。如果小表的記錄不到一百萬條，就可以只放在一個數(shù)據(jù)庫分區(qū)中。

在設(shè)計不共享數(shù)據(jù)倉庫分區(qū)時的其他問題是如何判斷最佳的內(nèi)存、CPUs、總線、存儲能力、存儲帶寬的組合，那么，它們分別需要多少呢？

要解決這個問題，IBM 提供了 IBM Balanced Warehouse，它基于不共享架構(gòu)的數(shù)據(jù)庫系統(tǒng)。它是通過成功的客戶運行開發(fā)的 IBM 最佳實踐。

Balanced Warehouse 和 Balanced Configuration Units（BCU）

Balanced Warehouse 又被稱作 Balanced Configuration Units（BCU）的構(gòu)件。這些構(gòu)件是為了性能進行預(yù)配置、預(yù)測試而調(diào)試過的，用以提供一個理想的數(shù)量和比例的資源。 BCU 結(jié)合了數(shù)據(jù)庫配置和硬件組成的最佳實踐，盡可能的簡化數(shù)據(jù)倉庫的安裝和配置。幾十個資源率和數(shù)據(jù)庫配置的最佳實踐都被整合進了 Balanced Warehouse 。

圖 10：顯示了 Balanced Warehouse 在 2007 年和 2008 年提供的多種產(chǎn)品。你可以看到，Balanced Warehouse 現(xiàn)在提供了 3 種產(chǎn)品：C、D 和 E 。這 3 種產(chǎn)品提供了持續(xù)增強能力和可擴展性的解決方案。 C 級別是一個提供給市場的入門級別，或可以集成進一臺服務(wù)器中的系統(tǒng)。 D 和 E 級利用 DB2 數(shù)據(jù)庫分區(qū)能力，提供了可以擴展到相當(dāng)規(guī)模的配置。

回頁首

表（范圍）分區(qū)的最佳實踐

表分區(qū) 應(yīng)該被用來顯著的提高轉(zhuǎn)入和轉(zhuǎn)出數(shù)據(jù)。它允許管理員添加一個大范圍的數(shù)據(jù)（比如某月新的數(shù)據(jù)）到一個表中 en-masse 而且更重要的是管理員幾乎可以同時從表或從數(shù)據(jù)庫 en-masse 中刪除數(shù)據(jù)。

DB2 數(shù)據(jù)庫系統(tǒng)的唯一異步索引清除技術(shù)意味著就算全局索引的數(shù)據(jù)跨多個范圍分區(qū)，也可以從表中分離一個范圍分區(qū)，甚至這個范圍分區(qū)的相關(guān)索引鍵對進來的查詢也 變得立即不可見了。這些鍵值會被后臺進程隨后以對負載幾乎可以忽略不計的影響不動聲色的刪除。數(shù)據(jù)庫分區(qū)也能通過一個叫分區(qū)清除的內(nèi)部進程帶來提高查詢性 能的好處，在很多情況下這個進程允許查詢編譯器選擇改良過的查詢計劃，這是表分區(qū)的第二個好處。

表分區(qū)也允許你把一個表分成多個范圍，存儲在一個數(shù)據(jù)庫分區(qū)里的一個或多個物理對象中。表分區(qū)的目標(biāo)是對數(shù)據(jù)進行邏輯重組，使優(yōu)化數(shù)據(jù)訪問和轉(zhuǎn)出數(shù)據(jù)更容易。這個表的分割引用程序是透明的，而且因此可以在應(yīng)用程序開發(fā)周期的任何時候進行。

更多關(guān)于表分區(qū)的信息見文章“最佳實踐：數(shù)據(jù)生命周期管理”。

表分區(qū)包括下列其他屬性和功能：

• 每個范圍可以在不同的表空間中。
• 范圍可以單獨掃描。
• 某些 BI 風(fēng)格的查詢性能通過表分區(qū)得到了提高。
• 新的 ALTER ATTACH/DETACH 語句方便了轉(zhuǎn)入和轉(zhuǎn)出數(shù)據(jù)。
  • 新的 ATTACH 轉(zhuǎn)入選項
  • 新的 DETACH 轉(zhuǎn)出選項
• SET INTEGRITY 現(xiàn)在可以在線進行了（允許對老數(shù)據(jù)進行讀 / 寫訪問）。
• 在新的范圍中，對在 ATTACH+SET INTEGRITY 操作使用 ADD 加 LOAD 操作。

下面的例子顯示了如何定義一個分區(qū)表：

CREATE TABLE SALES(SALE_DATE DATE, CUSTOMER INT, … )
                    PARTITION BY RANGE(SALE_DATE)
                    (STARTING ‘ 1/1/2006 ’ ENDING ‘ 3/31/2008 ’ ,
                    STARTING ‘ 4/1/2006 ’ ENDING ‘ 6/30/2008,
                    STARTING ‘ 7/1/2006 ’ ENDING ‘ 9/30/2008 ’ ,
                    STARTING ‘ 10/1/2006 ’ ENDING ’ 12/31/2012 ’ );

這個語句結(jié)果會創(chuàng)建 4 個表對象，每個都存儲一個范圍的數(shù)據(jù)，如圖 8 所示：

使用下列表分區(qū)的最佳實踐：

• 使用表（范圍）分區(qū)將范圍數(shù)據(jù)快速刪除（轉(zhuǎn)出）。匹配范圍分區(qū)的周期來轉(zhuǎn)入和轉(zhuǎn)出范圍。例如，如果你需要根據(jù)月份轉(zhuǎn)入和轉(zhuǎn)出數(shù)據(jù)，那么使用月份進行范圍分區(qū)是一個合理的策略。
• 在 DATE 列上的分區(qū)。轉(zhuǎn)入和轉(zhuǎn)出場景幾乎總是基于時間的。改進過的查詢執(zhí)行計劃（QEP）選擇使用分區(qū)清除 以及那些機會的大部分也都基于數(shù)據(jù)謂詞。
• 限制范圍的個數(shù)。不要忘記每個范圍都是至少有兩個擴展數(shù)據(jù)塊的表對象。要避免設(shè)計過多的分區(qū)數(shù)。調(diào)整的規(guī)則是每個范圍有最少 50MB 的數(shù)據(jù)（最好每個范圍有幾 G 數(shù)據(jù)）。確保范圍大小和你通常轉(zhuǎn)出數(shù)據(jù)的大小一致。
• 添加一個新的范圍，可使用 ADD 加 LOAD 操作，這通常比 ATTACH+SET INTEGRITY 操作更好，因為除非范圍很小，否則后者的索引維護日志會非常大。
  
  • LOAD 實用工具增量維護索引，并對一個事件只寫一個日志記錄，而忽略有多少行被插入到表中。
• 考慮把不同的表分區(qū)放到不同的表空間中，可以方便備份和恢復(fù)。表分區(qū)可以通過表空間來備份和恢復(fù)。
• 避免全局索引，因為這可能會很大，它應(yīng)該存放在它們自己單獨的表空間中。
• 通過讓范圍分區(qū)鍵成為集群索引（非 MDC）的引導(dǎo)鍵來確保并保持?jǐn)?shù)據(jù)集群。如果你的集群索引沒有把分區(qū)鍵放在前面，那么數(shù)據(jù)將不會被正確的集群。例如，

  PARTITION BY RANGE (Month, Region) CREATE INDEX … (Month, Region, Department) CLUSTER

  
  
• 使用頁面級別的取樣來減少 RUNSTATS 時間。一個 10-20% 的樣本率，提供了良好質(zhì)量的統(tǒng)計信息以及主要的性能得到了提高。

回頁首

UNION ALL 視圖（UAVs）分區(qū)的最佳實踐

DB2 9 表分區(qū)之前版本的分區(qū)能力，應(yīng)用程序經(jīng)常需要按范圍對數(shù)據(jù)進行分區(qū)。通過對每個范圍創(chuàng)建有相應(yīng)約束的表，DBAs 可以通過對所有這些表創(chuàng)建一個 UNION ALL 視圖提供一個單獨的系統(tǒng)視圖。例如：

Create Table TestQ1 (Col 1 date)
                    Alter Table TestQ1
                    add constraint q1_chk
                    (month(dt) in (1,2,3)

對每個季度重復(fù)表創(chuàng)建 / 約束

Create View Test as
                    Select * from TestQ1
                    Union
                    Select * from TestQ2

然而，表分區(qū)為編譯器和優(yōu)化器提供了一個對表的單獨的視圖。和 UAV 相比，這允對不同的范圍使用許更多的侵略性謂詞，而且分區(qū)數(shù)據(jù)有更多的一致性模型。在大多數(shù)數(shù)據(jù)庫中，表分區(qū)現(xiàn)在是實現(xiàn)基于范圍的分區(qū)的首選方法。下面將討論一些例外。

UNION ALL 設(shè)計方法的優(yōu)勢是：

實用工具能在只包含一個范圍的表中執(zhí)行。最主要的考慮是：

復(fù)制，在某個確定范圍需要復(fù)制而其他范圍不需要復(fù)制時，使用 UNION ALL 視圖可以得到壓縮的好處（在 UAV 中的歷史表可以被壓縮）。

UNION ALL 視圖允許設(shè)計者存儲非壓縮數(shù)據(jù)到需要復(fù)制對象中，同時歷史數(shù)據(jù)可以存儲在其他壓縮對象中。

聯(lián)邦向終端用戶提供了一個聯(lián)邦數(shù)據(jù)（存儲在多個 IBM 或非 IBM 數(shù)據(jù)庫中）視圖。

對于 RORG，如果范圍經(jīng)常發(fā)生改變，就需要對范圍進行重新集群或壓縮。

• 大量使用的范圍，可以分離到有額外索引或 MQTs 單獨的表容器中，以以優(yōu)化數(shù)據(jù)訪問。
• 這被用來減少 REORG 的粒度。

比起 UNION ALL 分區(qū)方法，表分區(qū)具有下列優(yōu)勢：

• 準(zhǔn)備時間更短（一個表，而不是一個視圖中的多個表）。
• 管理更簡單（一個表，而不是多個表）。
• 在轉(zhuǎn)入和轉(zhuǎn)出范圍時，更少編目鎖。
• 支持跨所有范圍的唯一索引。
• 可以更好的處理復(fù)雜查詢。
• 更簡單的 EXPLAINs（使用 explain 工具）。

把 UNION ALL 視圖遷移為表分區(qū)

可以用以下步驟來把 UNION ALL 視圖遷移到表分區(qū)中，而不需要移動數(shù)據(jù)。

1. 創(chuàng)建一個分區(qū)表，它有一個不影響現(xiàn)有數(shù)據(jù)庫分區(qū)的虛擬分區(qū)。這需要相同的頁面大小和擴展數(shù)據(jù)塊大小。
2. ALTER ATTACH 視圖中的所有表。
3. 刪除掉虛擬分區(qū)。
4. 運行完所有 TABLE ATTACH 命令后運行 SET INTEGRITY 。為了加速一致性檢查：
   • 刪除所有索引。
   • 在一致性檢查完成后重建索引。

使用下面 UNION ALL 視圖分區(qū)的最佳實踐：

• 使用數(shù)據(jù)庫分區(qū)來獲得比 UNION ALL 視圖更好的擴展性。
• 遷移 UNION ALL 視圖到表分區(qū)中。新開發(fā)的應(yīng)用程序使用范圍分區(qū)，要求實施表分區(qū)而不是 UNION ALL 視圖，除非你對 UAV 優(yōu)勢列表中的一種或多種情況有很強的需求。
• 實現(xiàn)把 UNION ALL 應(yīng)用程序遷移到表分區(qū)，以獲得 DB2 9.5 自動字典壓縮提供的深度壓縮的好處。

回頁首

數(shù)據(jù)庫分區(qū)、表分區(qū)和 MDC 在同一個數(shù)據(jù)庫中的最佳實踐

數(shù)據(jù)庫分區(qū)、表分區(qū)和 MDC 能同時應(yīng)用在一個設(shè)計中。

• 可以應(yīng)用數(shù)據(jù)庫分區(qū)獲得擴展性，并確保在邏輯分區(qū)之間均勻分布數(shù)據(jù)。
• 表分區(qū)可以方便查詢分區(qū)消除和數(shù)據(jù)轉(zhuǎn)出。
• MDC 可以用來提高查詢性能和方便轉(zhuǎn)入數(shù)據(jù)。

對于部署大型應(yīng)用程序這是一個最佳實踐方法。

例如：

CREATE TABLE TestTable (A INT, B INT, C INT, D INT … )
                    IN Tablespace A, Tablespace B, Tablespace C …
                    INDEX IN Tablespace B DISTRIBUTE BY HASH (A) PARTITION BY RANGE (B)
                    (STARTING FROM (100) ENDING (300) EVERY (100)) ORGANIZE BY DIMENSIONS (C,D)

更多信息請查看文章“最佳實踐：數(shù)據(jù)生命周期管理”。

使用下面的最佳實踐：

• 要部署大型應(yīng)用程序，最好在同一個數(shù)據(jù)庫設(shè)計中實現(xiàn)數(shù)據(jù)庫分區(qū)、表分區(qū)和 MDC 。

回頁首

使用表分區(qū)和 MDC 最佳實踐來轉(zhuǎn)入和轉(zhuǎn)出數(shù)據(jù)

設(shè)計你的分區(qū)策略，以使用表分區(qū)來作為轉(zhuǎn)出策略，并利用在單個維度的 MDC 作為你的轉(zhuǎn)入策略。

例如，如果你按日轉(zhuǎn)入，按月轉(zhuǎn)出，在 day 上指定一個 MDC 并以 month 為表分區(qū)鍵（支持計算值）。

這個方法就減少了分區(qū)數(shù)，并簡化了 DBA 的管理任務(wù)。它利用了 MDC 轉(zhuǎn)入數(shù)據(jù)的優(yōu)勢（用塊索引減少索引 I/O 和日志）。

更多信息見文章“最佳實踐：數(shù)據(jù)生命周期管理”。

對轉(zhuǎn)入和轉(zhuǎn)出數(shù)據(jù)使用下面的最佳實踐：

• 使用表分區(qū)來轉(zhuǎn)出，并用單個維度上的 MDC 來轉(zhuǎn)入。

回頁首

使用表分區(qū)最佳實踐來轉(zhuǎn)入海量數(shù)據(jù)

可以使用表分區(qū)來為需要轉(zhuǎn)入龐大的數(shù)據(jù)量的應(yīng)用程序加速，這避免了執(zhí)行一致性檢查的需求。

還有一種連接分區(qū)的方法：你也可以 ALTER ADD 一個空表到一個表分區(qū)中。在表分區(qū)添加完成后，你可以用 Load 實用工具來填充表（允許對較老數(shù)據(jù)的只讀訪問）或者使用插入（這需要記日志）。

LOAD 可以提供出眾的性能，而且既可以從外部文件裝載，也可以使用 LOAD from cursor 從一個查詢定義裝載。

對應(yīng)用程序使用深度壓縮，DB2 9.5 在轉(zhuǎn)入數(shù)據(jù)時使用這個技術(shù)非常容易，因為它提供了自動字典壓縮，從而避免了用 REORG 來壓縮數(shù)據(jù)的需求。

更多信息見文章“最佳實踐：數(shù)據(jù)生命周期管理”。

使用下面轉(zhuǎn)入和轉(zhuǎn)出的最佳實踐：

• 使用表分區(qū)來轉(zhuǎn)入海量數(shù)據(jù)。
• ALTER ADD 一個空表到一個表分區(qū)，并使用 Load 實用工具來填充它。

回頁首

MQT 最佳實踐

MQT 表是基于一個查詢結(jié)果定義的表。 MQT 包含了預(yù)先計算的結(jié)果。 MQTs 是一個提高復(fù)雜查詢響應(yīng)時間的強大的方式，尤其是有下面幾類數(shù)據(jù)操作需求的查詢：

• 在一個或多個維度上聚合數(shù)據(jù)。
• 在一組表之間連接聚合數(shù)據(jù)。
• 數(shù)據(jù)來自于一個常見的數(shù)據(jù)訪問子集——也就是來自于“熱”水平或垂直數(shù)據(jù)庫分區(qū)。
• 在分區(qū)數(shù)據(jù)庫環(huán)境中，數(shù)據(jù)是對一個表的再分區(qū)，或表的一部分。

為了加速查詢性能，MQTs 可以被用在聯(lián)邦數(shù)據(jù)源的別名上，得以在本地保持頻繁訪問數(shù)據(jù)。他們可以通過復(fù)制來維護（系統(tǒng)維護選項不被支持）。在一個分區(qū)數(shù)據(jù)庫中，復(fù)制 MQTs 可以用來減少網(wǎng)絡(luò)流量。

MQT 對應(yīng)用程序是完全透明的。 MQT 的知識已經(jīng)被整合進 SQL 和 XQuery 編譯器中，它們會判斷是否 MQT 應(yīng)該被用來響應(yīng)一個查詢的所有部分。因此，你可以在不改變應(yīng)用程序代碼的情況下，創(chuàng)建和刪除 MQTs，就和你創(chuàng)建和刪除索引而不需要更改應(yīng)用程序一樣。

圖 11 根據(jù) MQTs 的刷新類型總結(jié)了它的特點。在表中，“ Optimization ”表示 DB2 數(shù)據(jù)庫管理器在運行一個查詢時，會利用延遲刷新的 MQT，。然而“ No optimization ”顯示 MQT 不會被使用，因為他可能已經(jīng)失效；。也就是說，數(shù)據(jù)庫管理器不知道 MQT 什么時候被刷新了。

注意：MQTs 會降低基礎(chǔ)表上的插入性能。

為了幫助問題診斷，DB2 9 解釋工具顯示了為什么一個 MQT 在訪問路徑中不被采用。

使用下列 MQT 設(shè)計的最佳實踐：

• 對你打算用來創(chuàng)建 MQT 的查詢語句，使用相同或更高的隔離級別。為了減少約束，隔離級別是：RR、RS、CS 和 UR 。
• 關(guān)注那些使用大量資源的查詢。這些查詢是利用 MQTs 來提高性能的最好的機會。
• 對 MQTs 數(shù)目，設(shè)置一個你愿意維持的限制。這么做有兩個理由：
  • 每個 MQT 都會使用磁盤存儲空間。
  • 每個 MQT 都會增加查找最優(yōu) QEP 的復(fù)雜度，延長查詢編輯時間。
• 為 MQTs 判斷一個磁盤總量限制。通常，不要分配超過一個數(shù)據(jù)倉庫磁盤總量的 10% - 20% 給 MQT 。
• 考慮在 MQTs 使用索引，并在索引創(chuàng)建后執(zhí)行 runstats 。嘗試創(chuàng)建一個可以用于多個查詢的 MQT 。常常這樣的 MQT 不能完全匹配一個查詢，而且可能需要索引。
• 幫助查詢編譯器找到匹配的 MQTs（MQT 的路由非常復(fù)雜）。利用下面的技術(shù)向編譯器提供盡可能多的信息：
  • 保持 MQTs 的統(tǒng)計信息實時更新。
  • 在 MQT 中的外鍵列上，啟用參考完整性（指定非強制性 RI 以避免系統(tǒng)開銷）。確保 FK 列非空。
  • 避免有問題的 MQT 設(shè)計造成路由困難。盡量避免使用 EXISTS、NOT EXISTS 和 SELECT DISTINCT，除非 MQT 完全匹配一個查詢，這些謂詞會使查詢編譯器很難使用 MQT 。

回頁首

后設(shè)計工具來提高現(xiàn)有數(shù)據(jù)庫設(shè)計

Explain 工具的最佳實踐

Explain 工具可以向你顯示是否使用了設(shè)計功能。例如，它可以向你顯示在 QEP 中是否訪問了索引、是否使用了分區(qū)消除以及是否查詢被路由到了 MQTs 。

考慮圖 12 中 explain 工具顯示的 TPC-H 查詢關(guān)于的 QEP 片段。

QEP 明確的顯示了 PARTSUPP 需要訪問 TPCD.UXPS_PK2KSC 索引和 PARTSUPP 表自己的信息。你如何判斷原因？

查 看 operator(15)，你可以看到 FETCH 聚集需要訪問 PARTSUPP 表，因為索引包含 PS_PARTKEY 和 PS_SUPPKEY 列，卻不包括 PS_AVAILQTY 列。強烈建議把 PS_AVAILQTY 列也加到索引中，這樣你可以避免在輔助方案中訪問 PARTSUPP 表，會因此提高性能。

圖 13 中顯示的 explain 輸出表明了優(yōu)化器在 QEP 中考慮了那些 MQTs 卻沒有選擇，以及沒有選擇的原因。這個原因可能是由于成本或 MQT 匹配度不夠。

使用下列 explain 工具的最佳實踐：

• 利用 explain 工具來幫助理解你的設(shè)計選擇。

DB2 設(shè)計顧問程序的最佳實踐

DB2 設(shè)計顧問程序是 DB2 自主計算的一個關(guān)鍵功能。它是一鍵式解決方案：提供一個工作負載（由用戶提供或系統(tǒng)提供）以及可選擇的磁盤約束，設(shè)計顧問程序建議物理數(shù)據(jù)庫設(shè)計選項，這 些選項設(shè)計可以優(yōu)化工作負載。設(shè)計顧問程序進行廣泛的“假設(shè)”分析、數(shù)據(jù)抽樣和關(guān)聯(lián)模式來探索上千種設(shè)計排列，這些是人工無法做到的。

設(shè)計顧問程序有下列能力：

• 索引選擇
• MQT 選擇
• MDC 選擇
• 分區(qū)選擇（對數(shù)據(jù)庫分區(qū)）
• 業(yè)界領(lǐng)先的工作負載壓縮

很多客戶反映使用設(shè)計顧問程序來動態(tài)提高物理數(shù)據(jù)庫設(shè)計，在整個生命周期內(nèi)引導(dǎo)一個查詢或提升整個工作負載的性能。當(dāng)然，你不要不經(jīng)過考慮就應(yīng)用來自設(shè)計顧問程序的結(jié)果。

圖 14 強調(diào)了設(shè)計顧問程序的好處。在這個例子中，一個決策支持?jǐn)?shù)據(jù)庫運行在 TPC-H 工作負載上而且為數(shù)據(jù)集創(chuàng)建了合理的索引，也就是說，一個優(yōu)秀的數(shù)據(jù)庫設(shè)計人員設(shè)計了這一切，并認為這已經(jīng)足夠了。然后使用設(shè)計顧問程序?qū)?shù)據(jù)庫提出額外 的建議，而應(yīng)用設(shè)計顧問程序的結(jié)果帶來了 6.5 倍的性能提高。

DB2 設(shè)計顧問程序的 MDC 選擇能力

為了提高工作負載性能，可以使用設(shè)計顧問程序 MDC 選擇能力來獲得 MDC 表維度的推薦值，包括基礎(chǔ)表上的 coarsifications 。雖然在一個表上可能會推薦一個或多個維度，但是只對那些只有一列且不是組合列的維度才會被考慮。

MDC 選擇能力是通過db2advis實用工具使用 -m <advise type> 標(biāo)記啟用的。建議類型（ “ C ”對應(yīng) MDC 和集群索引、“ I ”對應(yīng)索引、“ M ”對應(yīng) MQT 以及“ P ” 對應(yīng)數(shù)據(jù)庫分區(qū)）可以互相聯(lián)合。

設(shè)計顧問程序提供的 MDC 建議，總會提供良好的密度和在表被轉(zhuǎn)換成 MDC 時會發(fā)生的表膨脹總量限制。設(shè)計顧問程序中的分析操作不僅包括塊索引的好處，而且也包括了 MDC 對插入的影響，以及刪除表維度操作的影響。

輸出包括出現(xiàn)在 MDC 解決方案中的 coarsified 維度的每個表的生成列描述，以及對每個表的一個 ORGANIZE BY 子句建議。

使用下列設(shè)計顧問程序的最佳實踐：

• 提供能廣泛代表你的工作負載的輸入，不要只為一個查詢運行設(shè)計顧問程序。這使設(shè)計顧問程序生成可以應(yīng)用于整個工作負載的建議，而不是僅僅針對一個查詢。這或許會損害其他部分的工作負載。
• 包括輸入像 INSERT、UPDATE 和 DELETE 這些發(fā)生在你工作負載的操作，這樣設(shè)計顧問程序能對查詢的缺點和優(yōu)勢進行建模（關(guān)于添加新的設(shè)計功能）。例如，新的索引是否在不利于維護之外能提高查詢執(zhí)行時間。
• 使用 DB2 設(shè)計顧問程序的 MDC 選擇能力（在大小超過 12 個擴展數(shù)據(jù)塊大小的表上）來獲得 MDC 的建議維度，以提高工作負載性能。
• 使用 Query Patroller 或 DB2 9.5 負載管理器，來自動以某種格式抓取你的具體工作負載作為設(shè)計顧問程序的輸入。

回頁首

結(jié)論

物理數(shù)據(jù)庫設(shè)計對任何數(shù)據(jù)庫而言都是最重要的品質(zhì)。它影響數(shù)據(jù)庫的靈活性、有效性、可維護性和可擴展性，就像沒有其它方面的數(shù)據(jù)庫管理。雖然數(shù)據(jù)庫設(shè)計很復(fù)雜，但是一個良好的設(shè)計可以提升性能并降低操作風(fēng)險。掌握這些無疑是專業(yè)數(shù)據(jù)庫管理員的基石。

參考資料

• 通過 developerWorks Information Management 專區(qū) 學(xué)習(xí)關(guān)于 Information Management 的更多知識。在這里可以找到技術(shù)文檔、how-to 文章、培訓(xùn)、下載、產(chǎn)品信息等等。
  
  
• 通過 Information Management 專區(qū) DB2 9 技術(shù)資源中心 了解 DB2 產(chǎn)品家族的更多產(chǎn)品信息和相關(guān)技術(shù)。
  
  
• 通過 DB2 V9.7 信息中心，了解 DB2 的詳細產(chǎn)品信息和相關(guān)技術(shù)等全面的內(nèi)容。
  
  
• 通過 DB2 pureXML wiki 查找演示程序、免費下載、技術(shù)文章等的鏈接。
  
  
• 隨時關(guān)注 developerWorks 技術(shù)活動 和 網(wǎng)絡(luò)廣播。
  
  

• 使用可直接從 developerWorks 下載的 IBM 產(chǎn)品評估試用軟件 構(gòu)建您的下一個開發(fā)項目。
  
  
• 現(xiàn)在可以免費使用 DB2。下載 DB2 Express-C，這是為社區(qū)提供的 DB2 Express Edition 的免費版本，它提供了與 DB2 Express Edition 相同的核心數(shù)據(jù)特性，為構(gòu)建和部署應(yīng)用程序奠定了堅實的基礎(chǔ)。