簡介曾聽說過創造性壓力嗎？它屬于那些偽精神哲學之一，它宣稱互相作用的力會創造出作為斗爭副產品的事物。這有點象小人書里面善與惡之間的斗爭。現在，我不想說所有軟件工程師都是好人，或者所有硬件工程師都是壞人，但是在他們之間存在著創造性壓力。正如 Joseph Campbell 所說的，“不要讓您對科學不切實際的憎惡迷惑了您的雙眼，以至看不到計算機芯片中的光輝境界。假如整個表象浪潮一樣涌出磁盤并沖入內存，那還能有什么比這更浪漫呢？有時侯，軟件工程師會哀嘆硬件發展的步伐太緩慢了：機器磁盤速度太慢、內存組太小并且時鐘速度象蝸牛爬行。（當硬件發展趕上的時候，可能我們會忘記 Java™ 應用程序曾經是那么慢。）當新一代硬件出現時，操作系統首先適應，但留給用戶的卻是，它們只能用 32 位體系架構運行 16 位或（氣喘吁吁的）8 位 DOS 應用程序的痛苦。現在壓力轉到了軟件工程師頭上：他們什么時候才會重新編譯應用程序并利用新硬件所提供的新數據類型和內存可尋址能力呢？在最終的分析中，您將在 8086 上運行的 BASIC 與在 24 路 SMP 上運行的 C++ 進行比較時，運行“Hello World程序所花費的時間大約與編寫該程序所花費的時間一樣長。但是，數據庫所要做的遠不止是要向顯示器輸出“Hello World。與 Web服務器軟件期望更高速線路一樣，數據庫軟件期望從磁盤速度、容量、可尋址內存的每次升級中盡可能獲得好處。盡管應用程序程序員可能會抱怨必須為 32 位機器重新編譯 16 位程序（它已經運行良好了），但是數據庫工程師喜歡這樣的想法：在將數據排序、聚集或發送給用戶之前把它保存在內存中而不是磁盤上。I/O 是如此眾多要求過高工作負載的殺手 — 這正是您將 1 TB 的數據分散到 5 TB 的磁盤上的原因（更多的磁盤 = 更多的軸，這意味著更多并行的 I/O，至少在基準測試世界中是這樣）。 123456下一頁 現在，在 RISC 和 Sparc 世界中，64 位體系架構正逐步成為標準，它答應商業性 UNIX®（如 AIX®、HP-UX 和 Solaris 等）為您喜愛的關系數據庫提供大量內存。32 位內存的可尋址能力大約等于 4 GB，而許多 UNIX 機器裝有 20 到 100 GB 內存，您肯定希望使用這樣大的內存。Intel 世界也不落后多少：現在，操作系統、編譯器和數據庫軟件實驗室里，正在 64 位 Intel 芯片上運行的 Linux 和 Windows 2000 是一個現實，而且不久會在您四周的網站上銷售。那么，假如硬件和操作系統都已經為使用巨大的內存做好了預備，并且數據庫也能夠利用大內存，那么您如何將它們結合起來并使之工作呢？使用 DB2® 版本 7，首先要弄清楚的是，在內部，DB2 假設使用 32 位內存和硬件。要利用更大的內存，必須告訴 DB2 可以使用它以及如何使用它。請勿責備 DB2 — 大多數 DB2 客戶機和許多 DB2服務器在未來數年中將運行在 32 位 Intel 機器上。并且即使 DB2 在您機器上檢測到有 96 GB 內存，誰又能肯定您希望 DB2 使用所有內存，而不是與其它應用程序共享這個內存呢？當使用這種大內存時，您有幾種選擇。最顯而易見的選擇是創建 64 位 DB2 實例。現在，AIX、Solaris 和 HP-UX 上的 DB2 版本 7 都支持這種操作。假如您擁有版本 7.1，則必須下載修訂包 1 以安裝 64 位 DB2 庫。假如您擁有版本 7.2 或更新版本，則不必為了創建 64 位 DB2 實例而安裝修訂包。要創建 64 位 DB2 實例，可以使用 db2icrt 命令，并指定參數 -w 的值為 64。例如：db2icrt -w 64 -u db2fenc1 db2inst1描述 64 位環境中 DB2 使用的手冊位于：http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?fn=db2q9e71frm3toc.htm 上一頁123456下一頁 1 + 1 = 2。2 的 32 次方 = 極大的數。每個 32 位 DB2 實例能夠對 4 GB 內存尋址。通常，您希望將大部分內存給緩沖池專用。但是，AIX、HP-UX 和 Windows 上的內存分段會將最大緩沖池的大小限制在 4 GB 以內。即使是在 32 位世界中擁有十分干凈的內存模型的 Solaris 上，用于 DB2 緩沖池的內存也不能超過 3.35 GB；4 GB 內存空間的其余內存必須專用于 DB2 的其它共享內存用途。（幸運的是，對于 64 位世界中的所有操作系統，內存模型都更干凈。）在 HP-UX 上，32 位 DB2 實例所能夠創建的最大緩沖池大約是 800 MB。在 HP-UX 上，只有通過使用 32 位 HP-UX 上的 Memory Windows 來運行多個實例，才能使用 1 GB 以上的緩沖池。（DB2 發行說明（Release Notes）中描述了 HP Memory Windows。）在 Windows 上，緩沖池被限制為 3 GB，AIX 上是 1.75 GB，而 Linux 上大約是 1 GB。在運行 32 位 DB2 的大內存系統上，要將大量內存給予緩沖池，最簡單方式就是在一個 DB2 企業擴展版（Enterprise-Extended Edition (EEE)）配置中運行多個邏輯 DB2 實例。只需要運行操作系統的一個實例，這將有助于節省開銷和答應多個 DB2 實例之間通過共享內存而不是通過 TCP/IP 或通信交換機來彼此通信。使用 DB2 的無共享體系結構，每個實例可以在它自己的數據庫分區之內愉快地對 4 GB 內存尋址。在大多數 DB2 TPC-H 基準測試中 — 它通常讓 DB2 EEE 在規模達 300 GB 或更大的數據庫上運行決策支持查詢 — 一個大型 SMP 為每個 DB2 節點劃分多至 4 GB 內存（每個節點都是一個運行它自己的 DB2 實例的數據庫分區）。DB2 還可以使用其它三種方法來利用大內存機器。在 AIX、Solaris 和 Windows 上，DB2 支持擴充存儲器（Extended Storage）（也稱為 ESTORE）。這答應 DB2 將超過 32 位內存模型中最大可用內存的內存用于系統臨時表（用于排序）和只讀用戶數據。在 DB2 從磁盤獲取數據時就由 DB2 判定哪些數據是可以認為是只讀，但是需要配置 DB2 以使用擴充存儲器。 上一頁123456下一頁 讓我們考慮一種典型情況：您正在設計一個數據庫，在其中希望將一個表盡可能多地放入內存。首先，更新數據庫治理器配置并告訴它要使用多少擴充存儲段（num_estore_segs）。這個值的缺省設置為零。n 取多大值將取決于表有多大、可用的內存有多少以及您希望這個特定表用多少內存。假定我們正在使用 Solaris，它有 6 GB 內存 — 在 4 GB 內存空間之上的 2GB 內存用于擴充存儲器（也稱為 estore）：update db cfg for sample using num_estore_segs n用“擴充存儲器存儲段大小（estore_seg_sz）數據庫配置參數來定義 estore 段的大小：update db cfg for sample using estore_seg_sz 32000現在您創建了一個緩沖池。對于本示例，我們將使用 8K 頁面大小，盡管 16K 和 32K 頁面大小也是答應的。（假如是在 Windows 上，要使用 2GB 以上的內存，則必須使用大于 4K 的頁面大小。）必須為擴充存儲器啟用緩沖池，可以使用 EXTENDED STORAGE 要害字做到。 highmem 是我為這個緩沖池選擇的名稱。其大小 n 取決于您希望這個緩沖池占用的內存數量：CREATE BUFFERPOOL highmem SIZE nPAGESIZE 8K EXTENDED STORAGE現在創建一個表空間，并將它分配到這個緩沖池：CREATE TABLESPACE highmem_tbsp PAGESIZE 8KMANAGED BY SYSTEMUSING ('C:highmemdir)BUFFERPOOL highmem注：表空間的頁面大小必須與該緩沖池的頁面大小相匹配，并且該緩沖池由名稱來標識。假如您只在這個表空間中創建一個表，而這個表空間又是該緩沖池中唯一的表空間，那么當訪問這個表中的數據時，就增大了數據留在內存中的機會。但對表進行排序時仍可能會溢出，因此請確保有一個已創建了相匹配的頁面大小的系統臨時表空間： 上一頁123456下一頁 CREATE SYSTEM TEMPORARY TABLESPACE highmem_temp PAGESIZE 8KMANAGED BY SYSTEMUSING ('C:highmemtemp') BUFFERPOOL highmem現在預備在該表空間中創建表：create table memory_hog (col1 int) in highmem_tbsp部分還是全部 AWE？由您來判定。Windows 2000 能夠通過 Microsoft Address Windowing Extensions（AWE）在 32 位世界中映射越過 4 GB 內存界線的數據。DB2 版本 7.2（或帶有修訂包 3 的版本 7.1）支持這個特性。Windows 2000 Advanced Server 最多支持 8 GB 內存，而 Windows 2000 Data Center Server 最多支持 64 GB 內存。在最終的分析中，您可能需要做一個選擇，這個選擇與高性能數據庫設計所需的顆粒度是背道而馳的。可以假定，您將考慮的用于上述技術的數據庫需要最佳性能 — 最終，假如性能不重要，為什么要將數據庫放到擁有大量內存的機器上？此類數據庫傾向于將用戶數據存儲在數據庫治理存儲器（Database Managed Storage (DMS)）中，將原始設備（raw device）用作容器。按照大多數人的意見：假如您治理一個具有眾多概要文件和用戶要求很高的數據庫，那么，需要投入大量時間對數據庫進行調整和計劃，這樣才能猜測數據的增長并在原始設備容器上分配足夠的空間。用這種思想，可以知道系統治理存儲器（SMS）表空間只適于系統數據（臨時表空間和目錄表空間）和必須對其進行少量維護的數據庫，因為，這兩者數量太多，因而無法保證對其設計和維護進行大量投資。假定您同時面臨兩種最糟糕的情況：一方面數據庫必須迅速，另一方面您又無法猜測其中的數據增長或去花費大量時間對其進行維護，那怎么辦呢？您可能會問：假如有些事情很重要，為什么不將 DBA 資源用于它呢？但老板并不總是理性的。幸運的是，關系數據庫架構設計師們并不是僅有的花費大量時間決定如何使用大內存機器的人：操作系統專家也在研究這個問題。您將需要做一個信念上的飛躍，將所有數據放置到 SMS 表空間，并將文件系統用作容器。（也可以使用 DMS 來做這件事，但是在為容器定義文件大小時，還必須計劃數據增長）。現在，查看所有 4 GB 內存地址以上的空間并將它用于文件系統高速緩存，是操作系統的任務。幸運的是，由于大多數數據庫運行在大型 SMP 上，并且能夠通過利用應用程序來達到其性能目標，這推動了系統設計師們挖掘出大內存機器的潛能，以將頻繁訪問的數據保存在內存中。而這正是人們希望數據庫緩沖池所做的：將經常訪問的數據保存在內存中，而其余的僅留在磁盤上。 上一頁123456下一頁 別在家里嘗試這個操作！（在工作中、在老板的系統上嘗試。）也許在結束關于內存的文章之前，有必要提醒您不要忘記系統里的其余部分。究竟，假如您有 96 GB 內存，而磁盤上就可能有不止 96 GB 的數據 — 正等著吞沒您的系統并將它送入頁面調度的痛苦狀態。本文的重點是盡可能多地使用內存。究竟，您為它花了錢，那么為什么不使用它并使之物有所值呢？按照這種思想，不要忘記您購買的其余硬件。您希望軟件使用所有的內存，但也希望所有處理器做它們的那部分工作 — 對所有的磁盤也是如此。正如在 1 MB PC 上將應用程序限制到 640 K 內存不能充分利用可用資源一樣（因此比它應有的速度要慢），假如您的一個處理器以 100% 運行，而其它以 25% 運行，這時，您的處境就很尷尬了 — 一個處理器的工作負載已達到了極限，而其余處理器什么也不做。（這種情景就好象您在建筑工地上看到一個人正在拿鐵鍬工作，而他的同事卻袖手旁觀。）這正是 DB2 EEE 可以幫助您的地方；它的無共享體系結構被設計成簡潔地將所有工作和數據公平地劃分給可以使用的內存、CPU 和磁盤。出于這個原因，對于決策支持無共享體系結構是很理想的。對于那些事務型工作負載，您必須監視熱點：假如發生了 CPU 或磁盤中的一個子集工作過重的現象，為什么會發生這種現象呢？是因為所有任務繁重的客戶機都連接到同一節點了嗎？幸運的是，EEE 答應您將客戶機連接分布到所有節點。是否應該將數據移到這些節點上的許多小表中，這樣在進行更新操作時，就避免了對分布在所有節點的一個大表進行操作的情況。小表的缺點在于：當您希望得到一個需要來自每個節點上行的結果集時，必須進行 UNION 操作。還有，不要怕在無共享體系結構上運行 OLTP。在撰寫本文時（2001 年 4 月），TPC-C 測試結果表明：前六名都是集群的無共享數據庫。工作負載平衡還意味著將表空間分布到多個磁盤，這樣多個磁盤可以同時返回數據，因而也就啟用了并行 I/O。這里，在三個變量之間存在創造性壓力：磁盤、內存和處理器。運氣好的話，您的每種資源都充足，并且可以在它們之間進行工作負載平衡來構建一個系統，對于您所花費的時間和投資的金錢，這個系統是物有所值的。至于還沒有使用的硬件呢？唔，至少它使硬件銷售代表掙得大筆傭金可以到夏威夷度假。而且，假如沒有其它原因，那么您是否曾發現自己在夏威夷釣魚而您的小艇和海浪搏斗時，這些額外的硬件和一根繩索就會形成一個可靠的錨。關于作者Blair Adamache 是 IBM多倫多實驗室里有十七年工作經驗的老手。他相信假如從 1970 年到 1995 年的每次棒球賽都統計到一個關系表而每次投擲都占一行的話，那么我們將可以證實 Dwight Evans 和 Bobby Grich 應當進棒球名人堂（Baseball Hall of Fame）。 本文最初發表于 DB2 開發者園地，須經許可才能轉載。本文所表達的是作者的觀點，而非 IBM 觀點。 上一頁123456