我們今天是要和大家一起討論的是讓DB2使用所有內存的方法，我在相關網站看見讓DB2使用所有內存的方法的資料，覺得挺好，今天就拿出來供大家分享，以下就是文章的詳細內容介紹，望大家借鑒。
曾聽說過創造性壓力嗎?它屬於那些偽精神哲學之一，它宣稱互相作用的力會創造出作為斗爭副產品的事物。這有點象小人書裡面善與惡之間的斗爭。
簡介
曾聽說過創造性壓力嗎?它屬於那些偽精神哲學之一，它宣稱互相作用的力會創造出作為斗爭副產品的事物。這有點象小人書裡面善與惡之間的斗爭。現在，我不想說所有軟件工程師都是好人，或者所有硬件工程師都是壞人，但是在他們之間存在著創造性壓力。
正如 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，至少在基准測試世界中是這樣)。
現在，在 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/database/db2/udb/winos2unix/support/document.d2w/report?fn=db2q9e71frm3toc.htm
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 以使用擴充存儲器。
讓我們考慮一種典型情況：您正在設計一個數據庫，在其中希望將一個表盡可能多地放入內存。首先，更新數據庫管理器配置並告訴它要使用多少擴充存儲段(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 n
- PAGESIZE 8K EXTENDED STORAGE
現在創建一個表空間，並將它分配到這個緩沖池：
- CREATE TABLESPACE highmem_tbsp PAGESIZE 8K
- MANAGED BY SYSTEM
- USING ('C:highmemdir)
- BUFFERPOOL highmem
以上的相關內容就是對讓DB2使用所有內存的方法的介紹，望你能有所收獲。
