關(guān)于DB2的內(nèi)存分配

nic518

這兩天在看DB2的內(nèi)存管理的內(nèi)容,看的很是模糊,有以下問題不明白,請(qǐng)教
是不是數(shù)據(jù)庫管理器的共享內(nèi)存就是DB2能夠使用的最大內(nèi)容呢,然后數(shù)據(jù)庫全局內(nèi)存從管理器內(nèi)存那里獲得分配的內(nèi)存,然后應(yīng)用程序全局內(nèi)存又從數(shù)據(jù)庫全局內(nèi)存那里獲得分配內(nèi)存的,也就是說他們是一層一層的包含關(guān)系.還是我理解有問題,是并列關(guān)系的呢?
PS 現(xiàn)在DB2好的教材比較少,找了幾本書上寫的都不是很清楚,誰要要好的資料共享下,先謝了

nic518

【導(dǎo)讀】本文將向您講解 DB2 內(nèi)存使用的基礎(chǔ)，以及共享內(nèi)存和私有內(nèi)存的概念。這些內(nèi)容同時(shí)適用于 32 位和 64 位的系統(tǒng)。
簡(jiǎn)介

理解 DB2 如何使用內(nèi)存，可以防止過度分配內(nèi)存，并有助于對(duì)內(nèi)存的使用進(jìn)行調(diào)優(yōu)，從而獲得更好的性能。

本文將向您傳授 DB2 內(nèi)存使用的基礎(chǔ)，以及共享內(nèi)存和私有內(nèi)存的概念。這些內(nèi)容同時(shí)適用于 32 位和 64 位的系統(tǒng)。雖然對(duì)于 64 位系統(tǒng)有一些限制，但是在未來的一段時(shí)間內(nèi)還不大可能觸及這些限制。因此，我們將焦點(diǎn)放在影響 32 位系統(tǒng)的內(nèi)存限制，并對(duì)之進(jìn)行詳細(xì)的討論。

我們首先討論一般情況下 DB2 如何使用內(nèi)存，接著討論內(nèi)存管理如何隨著平臺(tái)（AIX、Sun、HP、Linux 和 Windows）的不同而變化，以及它們對(duì) DB2 的影響。最后，我們將給出一些實(shí)際生活中客戶處境/問題以及他們的解決方案的有意義的例子。本文的內(nèi)容適用于 DB2 version 8。

DB2 內(nèi)存結(jié)構(gòu)概述

圖 1中說明了 DB2 內(nèi)存結(jié)構(gòu)。這種內(nèi)存結(jié)構(gòu)在所有平臺(tái)上都是一致的。 注意：在多分區(qū)環(huán)境中，下面的圖適用于多分區(qū)實(shí)例中的每個(gè)分區(qū)。

圖 1 - DB2 內(nèi)存結(jié)構(gòu)




DB2 在 4 種不同的內(nèi)存集（memory set）內(nèi)拆分和管理內(nèi)存。這 4 種內(nèi)存集分別是：

實(shí)例共享內(nèi)存（instance shared memory）
數(shù)據(jù)庫共享內(nèi)存（database shared memory）
應(yīng)用程序組共享內(nèi)存（application group shared memory）
代理私有內(nèi)存（agent private memory）
每種內(nèi)存集由各種不同的內(nèi)存池（亦稱堆）組成。圖 1 也給出了各內(nèi)存池的名稱。例如， locklist是屬于數(shù)據(jù)庫共享內(nèi)存集的一個(gè)內(nèi)存池。 sortheap是屬于代理私有內(nèi)存集的一個(gè)內(nèi)存池。

我們將詳細(xì)討論每一種內(nèi)存集。

實(shí)例共享內(nèi)存

每個(gè) DB2 實(shí)例都有一個(gè)實(shí)例共享內(nèi)存。實(shí)例共享內(nèi)存是在數(shù)據(jù)庫管理器啟動(dòng)（db2start）時(shí)分配的，并隨著數(shù)據(jù)庫管理器的停止（db2stop）而釋放。這種內(nèi)存集用于實(shí)例級(jí)的任務(wù)，例如監(jiān)控、審計(jì)和節(jié)點(diǎn)間通信。下面的數(shù)據(jù)庫管理器配置（dbm cfg）參數(shù)控制著對(duì)實(shí)例共享內(nèi)存以及其中個(gè)別內(nèi)存池的限制：

實(shí)例內(nèi)存（ instance_memory）。
監(jiān)視器堆（ mon_heap_sz）：用于監(jiān)控。
Audit Buffer（ audit_buf_sz）：用于 db2audit 實(shí)用程序。
Fast Communication buffers （ fcm_num_buffers）：用于分區(qū)之間的節(jié)點(diǎn)間通信。僅適用于分區(qū)的實(shí)例。
instance_memory參數(shù)指定為實(shí)例管理預(yù)留的內(nèi)存數(shù)量。默認(rèn)值是 AUTOMATIC。這意味著 DB2 將根據(jù)監(jiān)視器堆、審計(jì)緩沖區(qū)和 FCM 緩沖區(qū)的大小計(jì)算當(dāng)前配置所需的實(shí)例內(nèi)存數(shù)量。此外，DB2 還將分配一些額外的內(nèi)存，作為溢出緩沖區(qū)。每當(dāng)某個(gè)堆超出了其配置的大小時(shí)，便可以使用溢出緩沖區(qū)來滿足實(shí)例共享內(nèi)存區(qū)內(nèi)任何堆的峰值需求。在這種情況下，個(gè)別堆的設(shè)置是 軟限制的，它們可以在內(nèi)存使用的峰值期間進(jìn)一步增長(zhǎng)。

如果 instance_memory被設(shè)置為某一個(gè)數(shù)字，則采用 instance_memory與 mon_heap_sz、 audit_buf_sz和 fcm_num_buffers的和之間的較大者。這時(shí)，對(duì)實(shí)例內(nèi)存就施加了一個(gè)硬性的限制，而不是軟限制。當(dāng)達(dá)到這個(gè)限制時(shí)，就會(huì)收到內(nèi)存分配錯(cuò)誤。出于這個(gè)原因，建議將 instance_memory的設(shè)置保留為 AUTOMATIC。

如果 instance_memory被設(shè)為 AUTOMATIC，則可以使用下面的命令來確定它的值：

db2 attach to instance_name（其中 instance_name是實(shí)例的名稱）
db2 get dbm cfg show detail
下面的輸出表明有 42 MB 的內(nèi)存被預(yù)留給實(shí)例共享內(nèi)存集（10313 頁 * 4096 字節(jié)/頁）：

Size of instance shared memory (4KB) (INSTANCE_MEMORY) = AUTOMATIC(10313) AUTOMATIC(10313)
instance_memory參數(shù)只是設(shè)置了實(shí)例共享內(nèi)存的限制。它并沒有說出當(dāng)前使用了多少內(nèi)存。要查明一個(gè)實(shí)例的內(nèi)存使用情況，可以使用 DB2 內(nèi)存跟蹤器工具 db2mtrk。例如，

db2start
db2mtrk -i -v
Memory for instance
FCMBP Heap is of size 17432576 bytes
Database Monitor Heap is of size 180224 bytes
Other Memory is of size 3686400 bytes
Total: 21299200 bytes
上面的例子表明，雖然預(yù)留給實(shí)例共享內(nèi)存集的內(nèi)存有 42 MB，但在 db2mtrk運(yùn)行時(shí)只用到了大約 21 MB。注意：在某些情況下，db2mtrk 顯示的大小會(huì)大于指定給配置參數(shù)的值。在這種情況下，賦予配置參數(shù)的值被作為一種軟限制，內(nèi)存池實(shí)際使用的內(nèi)存可能會(huì)增長(zhǎng)，從而超出配置的大小。

數(shù)據(jù)庫共享內(nèi)存

每個(gè)數(shù)據(jù)庫有一個(gè)數(shù)據(jù)庫共享內(nèi)存集。數(shù)據(jù)庫共享內(nèi)存是在數(shù)據(jù)庫被激活或者第一次被連接上的時(shí)候分配的。該內(nèi)存集將在數(shù)據(jù)庫處于非激活狀態(tài)時(shí)釋放（如果數(shù)據(jù)庫先前是處于激活狀態(tài)）或者最后一個(gè)連接被斷開的時(shí)候釋放。這種內(nèi)存用于數(shù)據(jù)庫級(jí)的任務(wù)，例如備份/恢復(fù)、鎖定和 SQL 的執(zhí)行。

圖2展示了數(shù)據(jù)庫共享內(nèi)存集內(nèi)的各種內(nèi)存池。括號(hào)中顯示了控制這些內(nèi)存池大小的配置參數(shù)。

圖 2 - DB2 數(shù)據(jù)庫共享內(nèi)存




完整的綠色方框意味著，在數(shù)據(jù)庫啟動(dòng)的時(shí)候，該內(nèi)存池是完全分配的，否則，就只分配部分的內(nèi)存。例如，當(dāng)一個(gè)數(shù)據(jù)庫第一次啟動(dòng)時(shí)，不管 util_heap_sz的值是多少，只有大約 16 KB 的內(nèi)存被分配給實(shí)用程序堆。當(dāng)一個(gè)數(shù)據(jù)庫實(shí)用程序（例如備份、恢復(fù)、導(dǎo)出、導(dǎo)入和裝載）啟動(dòng)時(shí)，才會(huì)按 util_heap_sz指定的大小分配全額的內(nèi)存。

主緩沖池
數(shù)據(jù)庫緩沖池通常是數(shù)據(jù)庫共享內(nèi)存中最大的一塊內(nèi)存。DB2 在其中操縱所有常規(guī)數(shù)據(jù)和索引數(shù)據(jù)。一個(gè)數(shù)據(jù)庫必須至少有一個(gè)緩沖池，并且可以有多個(gè)緩沖池，這要視工作負(fù)載的特征、數(shù)據(jù)庫中使用的數(shù)據(jù)庫頁面大小等因素而定。例如，頁面大小為 8KB 的表空間只能使用頁面大小為 8KB 的緩沖池。

可以通過 CREATE BUFFERPOOL 語句中的 EXTENDED STORAGE 選項(xiàng)“擴(kuò)展”緩沖池。擴(kuò)展的存儲(chǔ)（ESTORE）充當(dāng)?shù)氖菑木彌_池中被逐出的頁的輔助緩存，這樣可以減少 I/O。ESTORE 的大小由 num_estore_segs 和 estore_seg_sz 這兩個(gè)數(shù)據(jù)庫配置參數(shù)來控制。如果使用 ESTORE，那么就要從數(shù)據(jù)庫共享內(nèi)存中拿出一定的內(nèi)存，用于管理 ESTORE，這意味著用于其他內(nèi)存池的內(nèi)存將更少。

這時(shí)您可能要問，為什么要這么麻煩去使用 ESTORE？為什么不分配一個(gè)更大的緩沖池呢？答案跟可尋址內(nèi)存（而不是物理內(nèi)存）的限制有關(guān)，我們?cè)诤竺鏁?huì)加以討論。

隱藏的緩沖池

當(dāng)數(shù)據(jù)庫啟動(dòng)時(shí)，要分配 4 個(gè)頁寬分別為 4K、8K、16K 和 32K 的小型緩沖池。這些緩沖池是“隱藏”的，因?yàn)樵谙到y(tǒng)編目中看不到它們（通過 SELECT * FROM SYSCAT.BUFFERPOOLS 顯示不出）。

如果主緩沖池配置得太大，則可能出現(xiàn)主緩沖池不適合可尋址內(nèi)存空間的情況。（我們?cè)诤竺鏁?huì)談到可尋址內(nèi)存。）這意味著 DB2 無法啟動(dòng)數(shù)據(jù)庫，因?yàn)橐粋�(gè)數(shù)據(jù)庫至少必須有一個(gè)緩沖池。如果數(shù)據(jù)庫沒有啟動(dòng)，那么就不能連接到數(shù)據(jù)庫，也就不能更改緩沖池的大小。由于這個(gè)原因，DB2 預(yù)先分配了 4 個(gè)這樣的小型緩沖池。這樣，一旦主緩沖池?zé)o法啟動(dòng)，DB2 還可以使用這些小型的緩沖池來啟動(dòng)數(shù)據(jù)庫。（在此情況下，用戶將收到一條警告（SQLSTATE 01626））。這時(shí)，應(yīng)該連接到數(shù)據(jù)庫，并減少主緩沖池的大小。

nic518

排序堆的閾值（ sheapthres， sheapthres_shr）

如果沒有索引滿足所取的行的要求順序，或者優(yōu)化器斷定排序的代價(jià)低于索引掃描，那么就需要進(jìn)行排序。DB2 中有兩種排序，一種是私有排序，一種是共享排序。私有排序發(fā)生在代理的私有代理內(nèi)存（在下一節(jié)討論）中，而共享排序發(fā)生在數(shù)據(jù)庫的數(shù)據(jù)庫共享內(nèi)存中。

對(duì)于私有排序，數(shù)據(jù)庫管理器配置參數(shù) sheapthres指定了私有排序在任何時(shí)刻可以消耗的內(nèi)存總量在實(shí)例范圍內(nèi)的 軟限制。如果一個(gè)實(shí)例總共消耗的私有排序內(nèi)存達(dá)到了這一限制，那么為額外傳入的私有排序請(qǐng)求所分配的內(nèi)存將大大減少。這樣就會(huì)在 db2diag.log 中看到如下消息：

"Not enough memory available for a (private) sort heap of size size of sortheap. Trying smaller size..."

如果啟用了內(nèi)部分區(qū)并行性（intra-partition parallelism）或者集中器（concentrator），那么當(dāng) DB2 斷定共享排序比私有排序更有效時(shí)，DB2 就會(huì)選擇執(zhí)行共享排序。如果執(zhí)行共享排序，那么就會(huì)在數(shù)據(jù)庫共享內(nèi)存中分配用于這種排序的排序堆。用于共享排序的最大內(nèi)存量是由 sheapthres_shr數(shù)據(jù)庫參數(shù)指定的。這是對(duì)共享排序在任何時(shí)刻可以消耗的內(nèi)存總量在數(shù)據(jù)庫范圍內(nèi)的 硬限制。當(dāng)達(dá)到這個(gè)限制時(shí)，請(qǐng)求排序的應(yīng)用程序?qū)⑹盏藉e(cuò)誤 SQL0955 (rc2)。之后，在共享內(nèi)存總消耗量回落到低于由 sheapthres_shr指定的限制之前，任何共享排序內(nèi)存的請(qǐng)求都得不到允許。

下面的公式可以計(jì)算出數(shù)據(jù)庫共享內(nèi)存集大致需要多少內(nèi)存：數(shù)據(jù)庫共享內(nèi)存 = (主緩沖池 + 4 個(gè)隱藏的緩沖池 + 數(shù)據(jù)庫堆 +實(shí)用程序堆 + locklist + 包緩存 + 編目緩存) + (estore 的頁數(shù) * 100 字節(jié)) + 大約 10% 的開銷

對(duì)于啟用了 intra_parallel 或集中器情況下的數(shù)據(jù)庫，共享排序內(nèi)存必須作為數(shù)據(jù)庫共享內(nèi)存的一部分預(yù)先分配，因而上述公式變?yōu)椋簲?shù)據(jù)庫共享內(nèi)存 = (主緩沖池 + 4 個(gè)隱藏的緩沖池 + 數(shù)據(jù)庫堆 +實(shí)用程序堆 + locklist + 包緩存 + 編目緩存 + sheapthres_shr) + (estore 的頁數(shù) * 100 字節(jié)) + 大約 10% 的開銷

提示： 為了發(fā)現(xiàn)分配給主緩沖池的內(nèi)存有多少，可以發(fā)出：

SELECT * FROM SYSCAT.BUFFERPOOLS

雖然大多數(shù)內(nèi)存池的大小是由它們的配置參數(shù)預(yù)先確定的，但下面兩種內(nèi)存池的大小在默認(rèn)情況下卻是動(dòng)態(tài)的：

包緩存： pckcachesz = maxappls * 8
編目緩存： catalogcache_sz = maxappls * 4
活動(dòng)應(yīng)用程序的最大數(shù)量： maxappls = AUTOMATIC
將 maxappls設(shè)為 AUTOMATIC的效果是，允許任意數(shù)量的連接數(shù)據(jù)庫的應(yīng)用程序。DB2 將動(dòng)態(tài)地分配所需資源，以支持新的應(yīng)用程序。因此，包緩存和編目的大小可以隨著 maxappls的值而變化。

除了上述參數(shù)以外，還有一個(gè)參數(shù)也會(huì)影響數(shù)據(jù)庫共享內(nèi)存的數(shù)量。這個(gè)參數(shù)就是 database_memory。該參數(shù)的缺省值是 AUTOMATIC。這意味著 DB2 將根據(jù)以上列出的各內(nèi)存池的大小來計(jì)算當(dāng)前配置所需的數(shù)據(jù)庫內(nèi)存量。此外，DB2 還將為溢出緩沖區(qū)分配一些額外的內(nèi)存。每當(dāng)某個(gè)堆超出了其配置的大小時(shí)，便可以使用溢出緩沖區(qū)來滿足實(shí)例共享內(nèi)存區(qū)內(nèi)任何堆的峰值需求。

如果 database_memory被設(shè)為某個(gè)數(shù)字，則采用 database_memory與各內(nèi)存池之和這兩者之間的較大者。

如果 database_memory被設(shè)為 AUTOMATIC，則可以使用以下命令來顯示它的值：

db2 connect to dbnameuser useridusing pwd
db2 get db cfg for dbnameshow detail
使用 db2mtrk 工具顯示當(dāng)前使用的內(nèi)存量： db2mtrk -i -d -v （在 Windows 中，-i 必須指定。在 UNIX 中，-i 是可選的。）


Memory for database： SAMPLE
   Backup/Restore/Util Heap is of size 16384 bytes
   Package Cache is of size 81920 bytes
   Catalog Cache Heap is of size 65536 bytes
   Buffer Pool Heap is of size 4341760 bytes
   Buffer Pool Heap is of size 655360 bytes
   Buffer Pool Heap is of size 393216 bytes
   Buffer Pool Heap is of size 262144 bytes
   Buffer Pool Heap is of size 196608 bytes
   Lock Manager Heap is of size 491520 bytes
   Database Heap is of size 3637248 bytes
   Other Memory is of size 16384 bytes
   Application Control Heap is of size 327680 bytes
    Application Group Shared Heap is of size 57344000 bytes
   Total: 67829760 bytes


應(yīng)用程序組共享內(nèi)存

這種共享內(nèi)存集僅適用于以下環(huán)境。（對(duì)于其他環(huán)境，這種內(nèi)存集不存在。）

多分區(qū)（multi-partitioned）數(shù)據(jù)庫。
啟用了內(nèi)部并行（intra-parallel）處理的未分區(qū)（non-partitioned）數(shù)據(jù)庫。
支持連接集中器的數(shù)據(jù)庫。
注意：當(dāng) max_connections的值大于 max_coordagents的值時(shí)，連接集中器便被啟用。這兩個(gè)參數(shù)可以在數(shù)據(jù)庫管理器配置中找到。（使用 GET DBM CFG 顯示數(shù)據(jù)庫管理器配置。）

在以上環(huán)境中，應(yīng)用程序通常需要不止一個(gè)的代理來執(zhí)行其任務(wù)。允許這些代理之間能夠彼此通信（相互發(fā)送/接收數(shù)據(jù)）很有必要。為了實(shí)現(xiàn)這一點(diǎn)，我們將這些代理放入到一個(gè)稱作 應(yīng)用程序組的組中。屬于相同應(yīng)用程序組的所有 DB2 代理都使用 應(yīng)用程序組共享內(nèi)存進(jìn)行通信。

應(yīng)用程序組內(nèi)存集是從數(shù)據(jù)庫共享內(nèi)存集中分配的。其大小由 appgroup_mem_sz數(shù)據(jù)庫配置參數(shù)決定。

多個(gè)應(yīng)用程序可以指派給同一個(gè)應(yīng)用程序組。一個(gè)應(yīng)用程序組內(nèi)可以容納的應(yīng)用程序數(shù)可以這樣計(jì)算： appgroup_mem_sz / app_ctl_heap_sz

在應(yīng)用程序組內(nèi)，每個(gè)應(yīng)用程序都有其自己的 應(yīng)用程序控制堆。此外，應(yīng)用程序組共享內(nèi)存中有一部分要預(yù)留給應(yīng)用程序組共享堆。如下圖所示：

圖 3 - DB2 應(yīng)用程序組共享內(nèi)存




例 1 考慮以下數(shù)據(jù)庫配置：

最大應(yīng)用程序內(nèi)存集大小 (4KB) (APPGROUP_MEM_SZ) = 40000
最大應(yīng)用程序控制堆大小 (4KB) (APP_CTL_HEAP_SZ) = 512
用于應(yīng)用程序組堆的內(nèi)存所占百分比 (GROUPHEAP_RATIO) = 70
可以計(jì)算出下面的值：



應(yīng)用程序組共享內(nèi)存集是： 40000 頁 * 4K/頁 = 160 MB
應(yīng)用程序組共享堆的大小是： 40000 * 70% = 28000 4K 頁 = 114MB
該應(yīng)用程序組內(nèi)可容納的應(yīng)用程序數(shù)為： 40000/512 = 78
用于每個(gè)應(yīng)用程序的應(yīng)用程序控制堆為： (100-70)% * 512 = 153 4K 頁 = 0.6MB
不要被 app_ctrl_heap_sz 參數(shù)迷惑。這個(gè)參數(shù)不是一個(gè)應(yīng)用程序組內(nèi)用于每個(gè)應(yīng)用程序的各應(yīng)用程序控制堆的大小。它只是在計(jì)算這個(gè)應(yīng)用程序組內(nèi)可容納多少應(yīng)用程序時(shí)用到的一個(gè)值。每個(gè)應(yīng)用程序的實(shí)際應(yīng)用程序控制堆大小都是通過 圖 3中給出的公式計(jì)算的，這個(gè)公式就是 ((100 - groupheap_ratio)% * app_ctrl_heap_sz)。

因此，groupheap_ratio 越高，應(yīng)用程序組共享堆就越大，從而用于每個(gè)應(yīng)用程序的應(yīng)用程序控制堆就越小。

例 2 假設(shè)在一天中最忙的時(shí)間里，有 200 個(gè)應(yīng)用程序連接到例 1 中所描述的數(shù)據(jù)庫上。由于每個(gè)應(yīng)用程序組可以容納 78 個(gè)應(yīng)用程序，因此我們需要 200/78 = 3 個(gè)應(yīng)用程序組來容納總共 200 個(gè)應(yīng)用程序。這里應(yīng)確保系統(tǒng)有足夠多的 RAM 來支持這一配置。否則就會(huì)發(fā)生 SQL10003N 錯(cuò)誤。

代理私有內(nèi)存

每個(gè) DB2 代理進(jìn)程都需要獲得內(nèi)存，以執(zhí)行其任務(wù)。代理進(jìn)程將代表應(yīng)用程序使用內(nèi)存來優(yōu)化、構(gòu)建和執(zhí)行訪問計(jì)劃，執(zhí)行排序，記錄游標(biāo)信息（例如位置和狀態(tài)），收集統(tǒng)計(jì)信息，等等。為響應(yīng)并行環(huán)境中的一個(gè)連接請(qǐng)求或一個(gè)新的 SQL 請(qǐng)求，要為一個(gè) DB2 代理分配代理私有內(nèi)存。

代理的數(shù)量受下面兩者中的較低者限制：

所有活動(dòng)數(shù)據(jù)庫的數(shù)據(jù)庫配置參數(shù) maxappls 的總和，這指定了允許的活動(dòng)應(yīng)用程序的最大數(shù)量。
數(shù)據(jù)庫管理器配置參數(shù) maxagents 的值，這指定了允許的最大代理數(shù)。
代理私有內(nèi)存集由以下內(nèi)存池組成。這些內(nèi)存池的大小由括號(hào)中的數(shù)據(jù)庫配置參數(shù)指定：

Application Heap （ applheapsz）
Sort Heap （ sortheap）
Statement Heap （ stmtheap）
Statistics Heap （ stat_heap_sz）
Query Heap （ query_heap_sz）
Java Interpreter Heap （ java_heap_sz）
Agent Stack Size （ agent_stack_sz） （僅適用于 Windows）
我們?cè)�提到，私有�?nèi)存是在一個(gè) DB2 代理被“指派”執(zhí)行任務(wù)時(shí)分配給該代理的。那么，私有內(nèi)存何時(shí)釋放呢？答案取決于 dbm cfg 參數(shù) num_poolagents的值。該參數(shù)的值指定任何時(shí)候可以保留的閑置代理的最大數(shù)目。如果該值為 0，那么就不允許有限制代理。只要一個(gè)代理完成了它的工作，這個(gè)代理就要被銷毀，它的內(nèi)存也要返回給操作系統(tǒng)。如果該參數(shù)被設(shè)為一個(gè)非零值，那么一個(gè)代理在完成其工作后不會(huì)被銷毀。相反，它將被返回到閑置代理池，直到閑置代理的數(shù)目到達(dá) num_poolagents指定的最大值。當(dāng)傳入一個(gè)新的請(qǐng)求時(shí)，就要調(diào)用這些閑置代理來服務(wù)該新請(qǐng)求。這樣就減少了創(chuàng)建和銷毀代理的開銷。

當(dāng)代理變成閑置代理時(shí)，它仍然保留了其代理的私有內(nèi)存。這樣設(shè)計(jì)是為了提高性能，因?yàn)楫?dāng)代理被再次調(diào)用時(shí)，它便有準(zhǔn)備好的私有內(nèi)存。如果有很多的閑置代理，并且所有這些閑置代理都保留了它們的私有內(nèi)存，那么就可能導(dǎo)致系統(tǒng)耗盡內(nèi)存。為了避免這種情況，DB2 使用一個(gè)注冊(cè)表變量來限制每個(gè)閑置代理可以保留的內(nèi)存量。這個(gè)變量就是 DB2MEMMAXFREE。它的默認(rèn)值是 8 388 608 字節(jié)。這意味著每個(gè)閑置代理可以保留最多 8MB 的私有內(nèi)存。如果有 100 個(gè)閑置代理，那么這些代理將保留 800MB 的內(nèi)存，因此它們很快就會(huì)耗盡 RAM。您可能希望降低或增加這一限制，這取決于 RAM 的大小。

圖 1展示了一個(gè) DB2 實(shí)例的 DB2 內(nèi)存結(jié)構(gòu)。 圖 4將展示在同一個(gè)系統(tǒng)上有兩個(gè)實(shí)例并發(fā)運(yùn)行的情況。虛擬內(nèi)存包括物理 RAM 和調(diào)頁空間（paging space）。共享內(nèi)存“傾向于”留在 RAM 中，因?yàn)閷?duì)它們的訪問更頻繁。如果代理閑置了較長(zhǎng)的一段時(shí)間，則其代理私有內(nèi)存將被調(diào)出。

圖 4 - 并發(fā)運(yùn)行的兩個(gè) DB2 實(shí)例


[img] [/img]

共享內(nèi)存與私有內(nèi)存

至此，我們已經(jīng)討論了實(shí)例共享內(nèi)存、數(shù)據(jù)庫共享內(nèi)存和應(yīng)用程序組共享內(nèi)存以及代理私有內(nèi)存。但是共享內(nèi)存和私有內(nèi)存的意義是什么呢？

為了理解共享內(nèi)存與私有內(nèi)存之間的不同之處，首先讓我們通過快速閱讀 DB2 進(jìn)程 model來了解一下 DB2 代理進(jìn)程。在 DB2 中，所有數(shù)據(jù)庫請(qǐng)求都是由 DB2 代理或子代理來服務(wù)的。例如，當(dāng)一個(gè)應(yīng)用程序連接到一個(gè)數(shù)據(jù)庫時(shí)，就有一個(gè) DB2 代理指派給它。當(dāng)該應(yīng)用程序發(fā)出任何數(shù)據(jù)庫請(qǐng)求（例如一個(gè) SQL 查詢）時(shí)，該代理就會(huì)出來執(zhí)行完成這個(gè)查詢所需的所有任務(wù) —— 它代表該應(yīng)用程序工作。（如果數(shù)據(jù)庫是分區(qū)的，或者啟用了 intra-parallel，那么可以分配不止一個(gè)的代理來代表應(yīng)用程序工作。這些代理叫做 子代理。）

每個(gè)代理或子代理都被當(dāng)作一個(gè) DB2 進(jìn)程，它獲得一定數(shù)量的內(nèi)存來執(zhí)行工作。這種內(nèi)存被稱作 代理私有內(nèi)存—— 它不能與其他任何代理共享。之前我們?cè)�提到過，代理私有內(nèi)存包括一些內(nèi)存池，例如應(yīng)用程序堆大小、排序堆大小和語句堆大小。（參見 圖 1）

除了私有內(nèi)存（代理在其中使用 排序堆執(zhí)行“私有”任務(wù)，例如私有排序）外，代理還需要數(shù)據(jù)庫級(jí)的資源，例如緩沖池、 locklist和日志緩沖區(qū)。這些資源在數(shù)據(jù)庫共享內(nèi)存中（參見 圖 1）。 DB2 的工作方式是，數(shù)據(jù)庫共享內(nèi)存中的所有資源都由連接到相同數(shù)據(jù)庫的所有代理或子代理共享。因此，該內(nèi)存集被稱作共享內(nèi)存，而不是私有內(nèi)存。例如，連接到數(shù)據(jù)庫 A 的代理 x 使用數(shù)據(jù)庫 A 的數(shù)據(jù)庫共享內(nèi)存中的資源。現(xiàn)在又有一個(gè)代理，即代理 y 也連接到數(shù)據(jù)庫 A。那么代理 y 將與代理 x 共享數(shù)據(jù)庫 A 的數(shù)據(jù)庫內(nèi)存。（當(dāng)然，代理 x 和代理 y 都有其自己的代理私有內(nèi)存，這些代理私有內(nèi)存不是共享的。）

這樣的邏輯同樣適用于實(shí)例共享內(nèi)存和應(yīng)用程序組共享內(nèi)存。

下圖展示了當(dāng)兩個(gè) DB2 代理（代理 x 和代理 y）連接到數(shù)據(jù)庫 A 時(shí)分配的 DB2 內(nèi)存集。假設(shè)：
數(shù)據(jù)庫 A 屬于實(shí)例 db2inst1。
數(shù)據(jù)庫 A 為應(yīng)用程序組 1 啟用了 intra-parallel。
代理 x 和 代理 y 都屬于應(yīng)用程序組 1。
圖 5 - DB2 代理進(jìn)程內(nèi)存地址空間

nic518

圖 5 展示了在 RAM 中分配的以下內(nèi)存集：

用于實(shí)例 db2inst1 的實(shí)例共享內(nèi)存集。
用于 數(shù)據(jù)庫 A 的數(shù)據(jù)庫共享內(nèi)存集。
用于 應(yīng)用程序組 1 的應(yīng)用程序組共享內(nèi)存。
用于代理 x 的代理私有內(nèi)存集。
用于代理 y 的代理私有內(nèi)存集。
為內(nèi)核和庫之類的東西預(yù)留的內(nèi)存。
代理 x 和代理 y 共享相同的實(shí)例內(nèi)存、數(shù)據(jù)庫內(nèi)存和應(yīng)用程序組內(nèi)存，因?yàn)樗鼈儗儆谙嗤�的�?shí)例、相同的數(shù)據(jù)庫和相同的應(yīng)用程序組。此外，它們有其自己的代理私有內(nèi)存。

每個(gè) DB2 代理進(jìn)程都有其自己的內(nèi)存地址空間。在內(nèi)存空間中的內(nèi)存地址允許代理訪問物理 RAM 中的內(nèi)存。我們可以把這些地址看作指向 RAM 的指針，如 圖 5所示。對(duì)于任何 DB2 進(jìn)程，這個(gè)地址空間必須能夠容納上述所有 4 種內(nèi)存集。

前面已提到，ESTORE 是用于擴(kuò)展緩沖池的大小。那么您可能要問，為什么不創(chuàng)建一個(gè)更大的緩沖池呢。答案是：因?yàn)榈刂房臻g受到限制，地址空間可能容不下一個(gè)更大的緩沖池！在此情況下，需要定義一個(gè)較小的地址空間能夠容納的緩沖池。如果有過量的物理內(nèi)存，那么可以用該內(nèi)存來配置 ESTORE。

那么，我們?cè)趺粗�道一個(gè) DB2 代理的地址空間是多大呢？地址空間的大小取決于當(dāng)前的實(shí)例是 32 位的實(shí)例還是 64 位的實(shí)例。我們將在下一節(jié)對(duì)此進(jìn)行解釋。

32 位體系結(jié)構(gòu)與 64 位體系結(jié)構(gòu)中的可尋址內(nèi)存

如果有一個(gè) 64 位的 DB2 實(shí)例，則意味著 DB2 使用的是 64 位的內(nèi)存體系結(jié)構(gòu)。在這種體系結(jié)構(gòu)中，對(duì)于所有平臺(tái)，每個(gè)進(jìn)程的地址空間都是 2 的 64 次方，或者 18,446,744,073 GB。這是一個(gè)相當(dāng)巨大的內(nèi)存。將所有 DB2 內(nèi)存集放入這個(gè)地址空間應(yīng)該沒有問題。

另一方面，如果有一個(gè) 32 位 DB2 實(shí)例，則對(duì)于所有平臺(tái)，地址空間只有 2 的 32 次方，或者 4 GB（Linux/390 平臺(tái)除外，在此平臺(tái)下地址空間實(shí)際上只有 2 的 31 次方。不過，在本文中我們不討論 Linux/390 中的 DB2）。所以，不管物理 RAM 有多大，要使一個(gè) DB2 進(jìn)程能夠訪問它所需的所有資源，包括實(shí)例共享內(nèi)存、數(shù)據(jù)庫共享內(nèi)存、應(yīng)用程序組共享內(nèi)存、它自己的代理私有內(nèi)存以及用于內(nèi)核的內(nèi)存等，所有這些資源必須能放入到 4GB 的地址空間內(nèi)。

這就導(dǎo)致了兩個(gè)非常重要的問題：

應(yīng)該為實(shí)例內(nèi)存、數(shù)據(jù)庫內(nèi)存和應(yīng)用程序共享內(nèi)存分配多少的內(nèi)存，以使它們能放入到 4GB 的可尋址空間？
應(yīng)該如何配置 圖 1中列出的每個(gè)參數(shù)，以最有效地利用可用的內(nèi)存？
雖然 4GB 的地址空間限制適用于所有平臺(tái)，但是對(duì)于上述問題的回答卻與平臺(tái)有關(guān)。例如，在 AIX 系統(tǒng)上可以分配給 DB2 數(shù)據(jù)庫的最大數(shù)據(jù)庫內(nèi)存數(shù)就與 Solaris 系統(tǒng)上的數(shù)據(jù)庫不同。接下來的幾節(jié)將討論不同的平臺(tái)對(duì) DB2 中的內(nèi)存配置有何影響。注意：本文的后續(xù)部分只針對(duì) 32 位內(nèi)存體系結(jié)構(gòu)。我們即將討論的問題不適用于 64 位的體系結(jié)構(gòu)。

32 位 AIX 中的 DB2 內(nèi)存配置

在 32 位的 AIX 上，4GB 的可尋址內(nèi)存空間被拆分為 16 個(gè)段，每段 256MB。 圖 6展示了用于一個(gè) DB2 代理進(jìn)程的 32位 內(nèi)存地址空間。（假設(shè) DB2_MMAP_READ 和 DB2_MMA_WRITE 這兩個(gè) DB2 注冊(cè)表變量都被設(shè)為 NO。如果這兩個(gè)變量沒有設(shè)為 NO，則表示方法會(huì)有點(diǎn)不同。我們將在后面解釋。）

圖 6 - AIX 中的 DB2 32 位內(nèi)存地址空間




段 0 - 預(yù)留給 AIX 內(nèi)核。

段 1 - 預(yù)留給 db2sysc 進(jìn)程。

段 2 - 預(yù)留給代理私有內(nèi)存。

段 3 - 預(yù)留給實(shí)例共享內(nèi)存。

段 4 到段 B - 數(shù)據(jù)庫共享內(nèi)存始于段 4，這些段必須緊挨在一起。所有這 8 個(gè)段（2GB）可能都被用于數(shù)據(jù)庫共享內(nèi)存。但是，下面的每種配置都會(huì)從數(shù)據(jù)庫共享內(nèi)存中拿出一個(gè)段（256MB）。

注意： 對(duì)于下面的每種配置，DB2 將從數(shù)據(jù)庫共享內(nèi)存中拿出一個(gè)段，這個(gè)段始于段 B。

如果數(shù)據(jù)庫是分區(qū)的，或者啟用了 intra-parallel 或連接集中器，那么數(shù)據(jù)庫共享內(nèi)存中有一個(gè)段被預(yù)留給應(yīng)用程序組共享內(nèi)存。
Fast Communication Manager (FCM)：FCM 用于系統(tǒng)物理節(jié)點(diǎn)上不同分區(qū)之間的通信。默認(rèn)情況下，這種通信是通過 UNIX socket 進(jìn)行的。如果 DB2_FORCE_FCM_BP 被設(shè)為 YES，那么 FCM 通信發(fā)生在共享內(nèi)存內(nèi)。這意味著數(shù)據(jù)庫共享內(nèi)存中有一個(gè)段被預(yù)留給 FCM 通信。雖然 FCM 通信變得更快，但是它也令數(shù)據(jù)庫共享內(nèi)存減少了一個(gè)段。
fenced UDF 和存儲(chǔ)過程：如果數(shù)據(jù)庫上運(yùn)行著一個(gè) fenced 函數(shù)或過程，那么數(shù)據(jù)庫共享內(nèi)存中有一個(gè)段要預(yù)留給 fenced 模式的通信。
如果數(shù)據(jù)庫允許任何本地連接，那么數(shù)據(jù)庫共享內(nèi)存中有一個(gè)段要預(yù)留給代理/本地應(yīng)用程序通信。如果將所有本地連接配置為 loopback 連接，那么就可以為這些連接使用 TCP/IP，而不需要共享內(nèi)存（即使數(shù)據(jù)庫就在服務(wù)器本地）。這樣就有效地為數(shù)據(jù)庫共享內(nèi)存空出一個(gè)段來。 然而，如果您不想使用 loopback 解決方案，還有一種方法可以迫使 DB2 選擇段 E 來用于代理/本地應(yīng)用程序通信，這樣數(shù)據(jù)庫共享內(nèi)存就不受影響（即不會(huì)減少）。請(qǐng)參閱后面的解釋。
如果啟用了 ESTORE，那么還要從數(shù)據(jù)庫共享內(nèi)存中拿出另一個(gè)段。因此，如果啟用 ESTORE，則應(yīng)確保它至少是 256MB，否則就不起作用，因?yàn)橐獜臄?shù)據(jù)庫共享內(nèi)存中拿出一個(gè) 256 MB 的段來僅用于管理這個(gè) ESTORE。建議將 estore 段的大小（ estore_seg_sz）設(shè)為 256MB，然后根據(jù)可用的內(nèi)存更改段的數(shù)目（ num_estore_segs）。
段 C - 預(yù)留給 DB2 跟蹤使用程序。

段 D 和 F- 預(yù)留給 DB2 共享庫

段 E - 在默認(rèn)情況下，這個(gè)段是不用的。不過，如果設(shè)置 DB2_MMAP_READ=NO 和 DB2_MMAP_WRITE=NO，那么該段用于 DB2 代理以及本地應(yīng)用程序之間的通信（如 圖 6所示）。這將有效地為數(shù)據(jù)庫共享內(nèi)存一個(gè)段。

注意： 為了最大化數(shù)據(jù)庫共享內(nèi)存的空間，應(yīng)使用以下注冊(cè)表變量設(shè)置：DB2_FORCE_FCM_BP=NO （該值是默認(rèn)值），DB2_MMAP_READ=NO，DB2_MMAP_WRITE=NO。

需要從這種結(jié)構(gòu)中了解到的最重要的事情是：

對(duì)于禁用了 intra-parallel 的單分區(qū)系統(tǒng)，我們可以得到至多 2GB 的空間用于數(shù)據(jù)庫共享內(nèi)存（段 4 到段 B）。
下面每種配置都將數(shù)據(jù)庫共享內(nèi)存減少了一個(gè)段（256MB）：帶 fenced UDF 或存儲(chǔ)過程的數(shù)據(jù)庫、帶本地連接的數(shù)據(jù)庫、DB2_FORCE_FCM_BP=YES 情況下的數(shù)據(jù)庫、支持 intra_parallel、或支持集中器以及分區(qū)的數(shù)據(jù)庫，以及啟用了 ESTORE 的數(shù)據(jù)庫。
如果允許與數(shù)據(jù)庫進(jìn)行本地連接，那么應(yīng)該將 DB2_MMAP_READ 和 DB2_MMAP_WRITE 都設(shè)置成 NO，以便使用段 E。否則，任何本地連接都要從數(shù)據(jù)庫共享內(nèi)存中拿走一個(gè)段。
這些限制規(guī)定了我們?cè)撊绾闻渲脭?shù)據(jù)庫共享內(nèi)存集中的每個(gè)內(nèi)存池�？梢允褂们懊娼o出的公式來計(jì)算數(shù)據(jù)庫共享內(nèi)存。得到的總和不能超過這個(gè)限制。

注意：內(nèi)存可以分配，釋放，也可以當(dāng)數(shù)據(jù)庫正在運(yùn)行時(shí)在不同區(qū)域之間交換。例如，您可以減少 locklist 而增加相同數(shù)量的任何一個(gè)給定的緩沖池。

使用 svmon 監(jiān)控 AIX 上的內(nèi)存使用情況

在 AIX 上，除了 db2mtrk 工具外，還可以使用 svmon 工具來監(jiān)控 DB2 代理進(jìn)程的內(nèi)存消耗情況（需要 root 權(quán)限）。這個(gè)命令是： "svmon -P PID"，其中 PID是 DB2 代理（db2agent 或 db2agentp）的進(jìn)程 ID。

圖 7 展示了 svmon 對(duì)于一個(gè)名為 db2agent 的進(jìn)程的示例輸出。與這個(gè) db2agent 進(jìn)程相關(guān)的數(shù)據(jù)庫有如下特征：


數(shù)據(jù)庫名是 TEST。
INTRAP_PARALLEL = YES (get dbm cfg)
DB2_FORCE_FCM_BP = YES (db2set -all)
DB2_MMAP_READ=NO, DB2_MMAP_WRITE=NO (db2set -all)
圖 7 - svmon 對(duì)于一個(gè) DB2 代理進(jìn)程 (svmon -P 11649046) 的輸出



從 圖 7中觀察到的一些情況：

進(jìn)程 ID 是 11649046，進(jìn)程名為 db2agent（左上角）。這個(gè)代理被連接到數(shù)據(jù)庫 TEST（數(shù)據(jù)庫的名稱在 svmon 輸出中已經(jīng)被截?cái)啵�只顯示了 'TES'）。
Esid 列顯示已經(jīng)分配的內(nèi)存段：
段 4 （綠色）被分配給數(shù)據(jù)庫共享內(nèi)存。
段 2 （橙色）被分配給代理私有內(nèi)存。
段 3 （藍(lán)色）被分配給實(shí)例共享內(nèi)存。
段 B （紫色）被分配給應(yīng)用程序組共享內(nèi)存，因?yàn)閿?shù)據(jù)庫支持 intra_parallel。
段 A （粉紅色）被分配給 FCM，因?yàn)?DB2_FORCE_FCM_BP=YES。
本地連接段被移到段 E（紅色）。這是因?yàn)?DB2_MMAP_READ 和 DB2_MMAP_WRITE 都被設(shè)為 NO。否則，就必須將段 8 用于代理和本地連接通信，因?yàn)槎?A 和段 B 都已經(jīng)被占用，而段 9 被預(yù)留給 fenced 模式的通信。
觀察到的這些情況與 圖 6中說明的相匹配。

設(shè)置 32 位 AIX 系統(tǒng)上數(shù)據(jù)和堆棧的 ulimit

我們?cè)缦日f過， 圖 6中的段 #2 是用于代理私有內(nèi)存的。實(shí)際上，并非完全如此。

確切地說，段 #2 被預(yù)留給數(shù)據(jù)和堆棧。數(shù)據(jù)包含用戶數(shù)據(jù)（即代理私有內(nèi)存）。而堆棧則包含要執(zhí)行的指令。在這個(gè) 256M 的段中，數(shù)據(jù)是從地址 0x20000000 向下增長(zhǎng)的。而堆棧是從地址 0x2FFFFFFF 向上增長(zhǎng)的。為了不讓數(shù)據(jù)和堆棧有沖突，設(shè)置它們的限制就十分重要。如果數(shù)據(jù)和堆棧真的有沖突，那么實(shí)例就會(huì)崩潰，并產(chǎn)生信號(hào) 4 或信號(hào) 11。

圖 8 - 數(shù)據(jù)段和堆棧段




數(shù)據(jù)和堆棧的限制是在 ulimits（/etc/security/limits）中設(shè)置的。使用 SMIT 將它們?cè)O(shè)置成如下值：

Data = 491519, Stack = 32767 (512 字節(jié))

上述值以 512 字節(jié)為單位，其中對(duì)于數(shù)據(jù)是 240MB，對(duì)于堆棧是 16MB。當(dāng)使用 "ulimit -a" 顯示這兩個(gè)限制時(shí)，顯示的值以 1K 字節(jié)為單位，而不是以 512 字節(jié)為單位。因此這兩個(gè)值變?yōu)椋?

Data = 245760, Stack = 16384

注意： /etc/security/limits 包含了以 512 字節(jié)為單位的限制，而不是以 1 KB 為單位的限制。

32 位 AIX 上與分配數(shù)據(jù)庫共享內(nèi)存有關(guān)的常見問題

初始化數(shù)據(jù)庫共享內(nèi)存失敗可能產(chǎn)生如下問題：

在數(shù)據(jù)庫啟動(dòng)時(shí)（激活數(shù)據(jù)庫或第一次連接數(shù)據(jù)庫） - SQL1478W, SQL0987C, SQL1084C。
在運(yùn)行時(shí) - SQL10003N, SQL1042C。
下面的例子展示了會(huì)導(dǎo)致問題的不恰當(dāng)配置。

例 1 考慮以下配置：（所有頁的大小為 4KB）

單分區(qū)，禁用集中器，INTRA_PARALLEL OFF，DB2_MMAP_READ=NO，DB2_MMAP_WRITE=NO，無 fenced 函數(shù)或過程
IBMDEFAULTBP 450,000 頁
UTILHEAP 17,500 頁
DBHEAP 10,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
限制：在此配置中，對(duì)于數(shù)據(jù)庫共享內(nèi)存的限制是 2GB 或 8 個(gè)段。

計(jì)算：使用公式計(jì)算數(shù)據(jù)庫共享內(nèi)存，我們得到：

數(shù)據(jù)庫共享內(nèi)存 = (486,000 頁 x 4KB/頁的總數(shù)） x 1.1 （考慮到 10% 的開銷） = ~2.1GB = 9 個(gè)段

注意：我們會(huì)將 4 個(gè)隱藏緩沖池排除在計(jì)算之外，因?yàn)樗鼈兲�小了，不�?huì)產(chǎn)生明顯的不同。

問題：這超出了 2GB 的限制。當(dāng)激活數(shù)據(jù)庫或第一次連接到數(shù)據(jù)庫時(shí)，您將收到如下警告：

SQL1478W The defined buffer pools could not be started. Instead, one small buffer pool for each page size supported by DB2 has been started. SQLSTATE=01626

在 db2diag.log 中，您將看到有消息說 DB2 將利用隱藏緩沖池啟動(dòng)。要解決這個(gè)問題，可以減少主緩沖池的大小。

例 2 考慮如下配置： （所有頁的大小都是 4K）

單分區(qū)，無 fenced 函數(shù)或過程，INTRA_PARALLEL=ON
IBMDEFAULTBP 300,000 頁
UTILHEAP 17,500 頁
DBHEAP 10,000 頁
SHEAPTHRES_SHR 50,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
限制： 1.5GB （6 個(gè)段）。一個(gè)段用于應(yīng)用程序組內(nèi)存，因?yàn)?INTRA_PARALLEL 是 ON。另一個(gè)段用于本地連接，因?yàn)?DB2_MMAP_READ 和 DB2_MMAP_WRITE 都被設(shè)為 YES （該值是默認(rèn)值）。

計(jì)算：數(shù)據(jù)庫共享內(nèi)存 = (386,000 頁 x 4KB/頁的總數(shù)） x 1.1 = ~1.67GB = 7 個(gè)段

問題：這超出了 1.5GB 的限制。當(dāng)嘗試激活數(shù)據(jù)庫或第一次連接到數(shù)據(jù)庫時(shí)，您將得到以下錯(cuò)誤消息：

SQL1042C An unexpected system error occurred. SQLSTATE=58004

要解決這一問題：

使用 db2set 將 DB2_MMAP_READ 和 DB2_MMAP_WRITE 設(shè)為 NO。這樣便迫使 DB2 將段 E 用于本地連接，從而為數(shù)據(jù)庫共享內(nèi)存空出一個(gè)段。
例 3 考慮如下配置： （所有頁的大小都為 4K）
IBMDEFAULTBP 250,000 頁
INTRA_PARALLEL=ON
UTILHEAP 17,500 頁
DBHEAP 10,000 頁
SHEAPTHRES_SHR 20,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
存在 Fenced UDF
限制： 以下各占一個(gè)段：Intra-parallel ON，本地連接，以及 fenced UDFB。這樣還剩下 5 個(gè)段，或者 1.25G 給數(shù)據(jù)庫共享內(nèi)存。

計(jì)算：

數(shù)據(jù)庫共享內(nèi)存 = (306,000 頁 x 4KB/頁的總數(shù)） x 1.1% = ~1.35GB = 6 個(gè)段

問題： 引用了 fenced UDF 的查詢就會(huì)失敗，并返回錯(cuò)誤 sql10003C。要解決這個(gè)問題，可以在 unfenced 模式下運(yùn)行 UDF，或者將數(shù)據(jù)庫共享內(nèi)存減少至不多于 5 個(gè)段。

32-位 Sun Solaris Version 2.6 及及其更高版本中的 DB2 內(nèi)存配置

在 AIX 中，每個(gè)段的大小都是 256MB，而在 Solaris 中則有所不同，其內(nèi)存段的大小不是固定的。32 位 Solaris 可尋址內(nèi)存結(jié)構(gòu)如 圖 9所示。

圖 9 - 32 位 Sun SolarisDB2 中的 32 位內(nèi)存地址空間




從 0x0 到 0x00010000 之間的地址不能使用。第一個(gè)段始于 0x00010000，這個(gè)段被預(yù)留給 db2sysc 可執(zhí)行程序和代理私有內(nèi)存。在缺省情況下，這個(gè)段結(jié)束于 0x10000000，因而這個(gè)段總共是 256MB。（我們可以通過設(shè)置 DB2DBMSADDR DB2 注冊(cè)表變量使這個(gè)段更大一些，見后面）。在這個(gè)段內(nèi)，db2sysc 可執(zhí)行程序只占用很小的一片內(nèi)存，剩下的用于代理私有內(nèi)存（200MB+）。

在默認(rèn)情況下，實(shí)例共享內(nèi)存的起始地址固定于 0x10000000。不過，也可以將其改為一個(gè)更高的地址，以便有更多的空間留給代理私有內(nèi)存。例如，如果實(shí)例共享內(nèi)存始于 0x12000000，而不是 0x10000000，那么就有 0x12000000 減去 0x10000000 即 32MB 的額外內(nèi)存被用于代理私有內(nèi)存。要做到這一點(diǎn)，可以將 DB2DBMSADDR DB2 注冊(cè)表變量設(shè)為如下值：

db2set DB2DBMSADDR=0x12000000

注意： DB2DBMSADDR 值的范圍是從 0x10000000 到 0x10FFFFFF，每次遞增 0x10000。

實(shí)例共享內(nèi)存的結(jié)束地址是不固定的。這意味著實(shí)例共享內(nèi)存可能會(huì)很大。緊接著實(shí)例共享內(nèi)存的是數(shù)據(jù)庫共享內(nèi)存。因?yàn)閷?shí)例共享內(nèi)存的結(jié)束地址不固定，所以數(shù)據(jù)庫共享內(nèi)存的起始地址也是不固定的。

在數(shù)據(jù)庫共享內(nèi)存之后的是用于 DB2 跟蹤、共享庫和堆棧（即將執(zhí)行的指令）的內(nèi)存。在 AIX 中，堆棧和代理私有內(nèi)存共享相同的內(nèi)存段，而在 Solaris 中則有所不同，其中代理私有內(nèi)存和堆棧分別使用不同的內(nèi)存段。因此，這里不存在兩者之間發(fā)生沖突的風(fēng)險(xiǎn)。

由于這些內(nèi)存段的大小不是固定的，我們只能估計(jì)實(shí)例共享內(nèi)存和數(shù)據(jù)庫共享內(nèi)存的大小為：

4GB - 代理私有內(nèi)存 - DB2 跟蹤 - DB2 共享庫 - 堆棧

注意這個(gè)數(shù)量同時(shí)還包括實(shí)例共享內(nèi)存和數(shù)據(jù)庫共享內(nèi)存，并且它們的內(nèi)存段必須是鄰接的。為了看一看實(shí)際中如何使用內(nèi)存，可以對(duì) db2sysc 或 db2agent 進(jìn)程的 ID 運(yùn)行 /usr/proc/bin/pmap 命令（以 root 的身份）。

注意：在 Solaris 中，當(dāng)使用 "pe -ef | grep instance_name" 命令顯示 DB2 進(jìn)程時(shí)，所有進(jìn)程都作為 db2sysc 進(jìn)程顯示。可以使用 db2ptree命令來以“真實(shí)”名稱顯示 DB2 進(jìn)程。 圖 9展示了 pmap 命令的一個(gè)示例輸出。

nic518

圖 10 - pmap 命令對(duì)于 db2sysc 進(jìn)程的示例輸出（/usr/proc/bin/pmap -x 15444）




從 圖 10 中可以觀察到下面一些情況：

從 0x00010000 到 0x023F8000 這一部分被預(yù)留給 db2sysc 可執(zhí)行程序（~36MB）。
橙色的那部分（堆），即從 0x023F8000 到 0x10000000，被用于代理私有內(nèi)存（~220MB）。
實(shí)例共享內(nèi)存，即綠色那部分，始于默認(rèn)地址 0x10000000。這意味著沒有設(shè)置 DB2DBMSADDR。
所有 3 個(gè)綠色的段被用于共享內(nèi)存，包括實(shí)例共享內(nèi)存和數(shù)據(jù)庫共享內(nèi)存。pmap 輸出并沒有說出哪一個(gè)段是實(shí)例共享內(nèi)存，哪一個(gè)段是數(shù)據(jù)庫共享內(nèi)存。我們只知道，數(shù)據(jù)庫共享內(nèi)存在 0xFE002000 結(jié)束，因?yàn)閺倪@個(gè)地址開始的是一個(gè)用于匿名內(nèi)存的段。因此，實(shí)例共享內(nèi)存和數(shù)據(jù)庫共享內(nèi)存總共的大小是 0xFE002000 - 0x10000000 = 3,992,985,600 字節(jié) = ~3.7 GB。
從 0xFFBC0000 到 0xFFFFFFFF 是用于堆棧的內(nèi)存段（~4MB）。
注意：在 32 位 Solaris 中，我們通常將 DB2 數(shù)據(jù)庫共享內(nèi)存限制在大約 3.5 GB。

如果設(shè)置了 DB2DBMSADDR 注冊(cè)表變量，那么實(shí)例共享內(nèi)存將從該變量指定的地址開始。下面的例子展示了這一點(diǎn)是如何實(shí)現(xiàn)的。

例子 設(shè)置 DB2DBMSADDR 注冊(cè)表變量：

db2set DB2DBMSADDR = 0x12000000
db2stop
db2start （需要重新啟動(dòng)實(shí)例，以使更改生效）。
獲得 db2sys 進(jìn)程的進(jìn)程 ID

ps -ef | grep sylviaq （'sylviaq' 是實(shí)例名）。
-ef | grep sylviaq
sylviaq 13166 1 0 13:09:12 pts/2 0:00 /export/home/sylviaq/sqllib/bin/db2bp 13049C11221 5
sylviaq 13263 13256 0 13:11:02 ? 0:00 db2sysc
sylviaq 13265 13256 0 13:11:03 ? 0:00 db2sysc
sylviaq 13257 13254 0 13:10:59 pts/3 0:00 -ksh
sylviaq 13256 13253 0 13:10:59 ? 0:00 db2sysc
sylviaq 13262 13256 0 13:11:00 ? 0:00 db2sysc
sylviaq 13360 13049 0 13:11:41 pts/2 0:00 grep sylviaq
sylviaq 13264 13256 0 13:11:02 ? 0:00 db2sysc
sylviaq 13266 13261 0 13:11:03 ? 0:00 db2sysc
以 root 的身份 cd 到 /usr/proc/pmap，并對(duì)任何 db2sysc 進(jìn)程運(yùn)行 pmap：

./pmap -x 13263

pmap 輸出：

13263: db2sysc
Address Kbytes Resident Shared Private Permissions Mapped File
00010000 35808 4064 1608 2456 read/exec db2sysc
02316000 896 168 48 120 read/write/exec db2sysc
023F6000 744 264 8 256 read/write/exec [ heap ]
12000000 243472 243472 - 243472 read/write/exec/shared [shmid=0xbc3]
21000000 22512 22512 - 22512 read/write/exec/shared [shmid=0xbc4]
FCC00000 8328 8328 - 8328 read/write/exec/shared [shmid=0xa96]
FE002000 8 - - - read/write/exec [ anon ]
注意，實(shí)例共享內(nèi)存現(xiàn)在從 0x12000000 開始，而不是從默認(rèn)地址 0x10000000 開始。代理私有內(nèi)存的大�。ㄓ� 'heap' 標(biāo)出）從 220MB （ 圖 10）增加到了 252 MB。(0x12000000 - 0x023F6000 = 0xFC0A000 = 264282112 (十進(jìn)制) = ~252MB)

您可能注意到， 圖 9中給出的 4GB 地址空間沒有包括任何內(nèi)核內(nèi)存。這就對(duì)了，在 Solaris 中，內(nèi)核有其自己的地址空間，該地址空間與進(jìn)程的地址空間是分開的。這樣就將更多的空間留給了其他內(nèi)存集，例如數(shù)據(jù)庫共享內(nèi)存。

雖然與 AIX 相比，在 Solaris 中我們有更大的地址空間用于數(shù)據(jù)庫共享內(nèi)存（在 AIX 上是 2GB），但是在 Solaris 上所有共享內(nèi)存都是固定在物理 RAM 中。如果 RAM 比較小，那么對(duì)于可以并發(fā)運(yùn)行的數(shù)據(jù)庫數(shù)目就有很大的影響。請(qǐng)參閱 “Sun Solaris 中與分配數(shù)據(jù)庫共享內(nèi)存有關(guān)的常見問題”一節(jié)中的例 2。

需要從這種結(jié)構(gòu)中了解到的最重要的事情是：

與 AIX 不同，Solaris 的內(nèi)存段其大小不是固定的。我們可以通過設(shè)置 DB2DBMSADDR DB2 注冊(cè)表變量，將實(shí)例共享內(nèi)存移到更高的地址，從而增加代理私有內(nèi)存。
數(shù)據(jù)庫共享內(nèi)存的限制大約是 3.5GB。
功能內(nèi)存與 RAM 固定，因而不能交換出去。
32 位 Sun Solaris 中與分配數(shù)據(jù)庫共享內(nèi)存有關(guān)的常見問題

沒有充分配置內(nèi)核參數(shù)以及初始化數(shù)據(jù)庫共享內(nèi)存失敗可能導(dǎo)致如下失敗：

在數(shù)據(jù)庫啟動(dòng)時(shí)（激活數(shù)據(jù)庫或第一次連接到數(shù)據(jù)庫） - SQL1478W, SQL1084C, hang condition
在運(yùn)行時(shí) - SQL2043N, 掛起條件
在 Solaris 系統(tǒng)中，DB2 提供了一個(gè)叫做 db2osconf的工具。該工具根據(jù)系統(tǒng)的大小對(duì)內(nèi)核參數(shù)的值給出建議。對(duì)于一個(gè)給定的系統(tǒng)，建議的值要足夠高，以便能夠容納最合理的工作負(fù)載。

最常見的未能正確設(shè)置的內(nèi)核參數(shù)是 shmmax。該參數(shù)按字節(jié)指定系統(tǒng)中可以分配的共享內(nèi)存段的最大大小。如果把 DB2 配置成創(chuàng)建大于這個(gè)值的數(shù)據(jù)庫共享內(nèi)存，那么請(qǐng)求就會(huì)失敗。其他要知道的內(nèi)核參數(shù)是 shmseg和 shmmni。

Solaris 中另一個(gè)與分配數(shù)據(jù)庫共享內(nèi)存有關(guān)的常見問題是由于這樣的一個(gè)事實(shí)導(dǎo)致的，即共享內(nèi)存段的所有頁都是固定在物理 RAM 中的。如果在 RAM 中沒有足夠的空閑頁可用，或者沒有足夠的可以被 OS 為滿足數(shù)據(jù)庫段而調(diào)出的其他頁，那么啟動(dòng)數(shù)據(jù)庫的請(qǐng)求就會(huì)遭到失敗。

下面的例子展示了會(huì)導(dǎo)致問題的不恰當(dāng)配置。

例 1 考慮如下配置： （所有頁的大小都為 4K）

服務(wù)器：

服務(wù)器上的物理 RAM 16GB
shmsys:shminfo_shmmax = 2097152 (2GB)
數(shù)據(jù)庫：

IBMDEFAULTBP 400,000 頁
UTILHEAP 17,500 頁
DBHEAP 30,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
限制： DB2 發(fā)出的任何創(chuàng)建大于 shmmax 值（這里是 2GB）的數(shù)據(jù)庫共享內(nèi)存集的請(qǐng)求都將失敗，并返回一個(gè) out of memory type 錯(cuò)誤。

計(jì)算：

數(shù)據(jù)庫共享內(nèi)存 = (456,000 頁 x 4KB/頁) x 1.1 = ~2.0GB

問題： 可能仍然可以激活數(shù)據(jù)庫或者連接到數(shù)據(jù)庫。但是，嘗試運(yùn)行一個(gè)應(yīng)用程序時(shí)可能返回如下錯(cuò)誤消息：

SQL1224N A database agent could not be started to service request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032

這是 DB2 經(jīng)常返回的一個(gè)錯(cuò)誤。不過，如果不是在 AIX 服務(wù)器上，而是在 UNIX 服務(wù)器上，那么這就很可能與內(nèi)存資源問題有關(guān)。特別地，可能是內(nèi)核參數(shù)沒有進(jìn)行適當(dāng)?shù)恼{(diào)優(yōu)。

為解決這個(gè)問題，可以適當(dāng)?shù)嘏渲脙?nèi)核參數(shù)。設(shè)置：

shmsys:shminfo_shmmax = 15099494 (~90% of 16GB)

例 2 考慮如下配置： （所有頁的大小都為 4K）

服務(wù)器上的物理 RAM 是 1 GB。

數(shù)據(jù)庫 A：

IBMDEFAULTBP 137,500 頁
INTRA_PARALLEL ON
UTILHEAP 10,000 頁
DBHEAP 10,000 頁
SHEAPTHRES_SHR 20,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
APPGROUP_MEM_SZ 20,000 頁
數(shù)據(jù)庫 B：

IBMDEFAULTBP 92,500 頁
INTRA_PARALLEL ON
UTILHEAP 5,000 頁
DBHEAP 10,000 頁
SHEAPTHRES_SHR 15,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
APPGROUP_MEM_SZ 20,000 頁
限制： 因?yàn)楣蚕韮?nèi)存是固定到物理 RAM 的，所以這種內(nèi)存不會(huì)被換出。因此，我們只能分配最多 1GB （可用的物理 RAM）的共享內(nèi)存給數(shù)據(jù)庫使用。

計(jì)算：

數(shù)據(jù)庫 A 共享內(nèi)存 = (186,000 頁 x 4KB/頁) x 1.1% = ~818MB
數(shù)據(jù)庫 A 應(yīng)用程序組內(nèi)存 = 20,000 頁 x 4KB/頁 = 80MB
數(shù)據(jù)庫 B 共享內(nèi)存 = (131,000 頁 x 4KB/頁) x 1.1% = ~576MB
數(shù)據(jù)庫 B 應(yīng)用程序組內(nèi)存 = 20,000 頁 x 4KB/頁 = 80MB
為了啟動(dòng)數(shù)據(jù)庫 A，要求： 818MB + 80MB = ~898MB
為了啟動(dòng)數(shù)據(jù)庫 B，要求： 576MB + 80MB = ~656MB
問題： 假設(shè)數(shù)據(jù)庫 A 是激活的。至少有 898MB 的共享內(nèi)存固定在物理 RAM 中。當(dāng)嘗試激活數(shù)據(jù)庫 B 時(shí)，就會(huì)碰到如下錯(cuò)誤消息：

SQL1084C Shared memory segments cannot be allocated. SQLSTATE=57019

如果同時(shí)啟動(dòng)數(shù)據(jù)庫 A 和數(shù)據(jù)庫 B，我們將請(qǐng)求至少 1.55GB (898MB + 656MB) 的可用物理 RAM，以便同樣地將共享內(nèi)存固定在 RAM 中。顯然，1GB 的 RAM 不夠。為解決這一問題：

嘗試減少這兩個(gè)數(shù)據(jù)庫的緩沖池大小�；蛘�
嘗試減少應(yīng)用程序組內(nèi)存�；蛘�
更可能的是，增加更多的物理 RAM。在這種情況下，您將需要至少 1.55GB 的物理 RAM，才能同時(shí)啟動(dòng)這兩個(gè)數(shù)據(jù)庫。
在這種情況下，按照上面的數(shù)據(jù)庫配置參數(shù)，在任何時(shí)刻啟動(dòng)某一個(gè)數(shù)據(jù)庫（數(shù)據(jù)庫 A 或數(shù)據(jù)庫 B）是可行的，但是不能同時(shí)啟動(dòng)兩個(gè)數(shù)據(jù)庫。這是必須增加更多的物理 RAM。

這個(gè)問題在 AIX 中不會(huì)出現(xiàn)，因?yàn)樵?AIX 中共享內(nèi)存沒有固定在物理 RAM 中。在這種場(chǎng)景中，可以啟動(dòng)數(shù)據(jù)庫 B。但是，這意味著數(shù)據(jù)庫 A 的數(shù)據(jù)庫內(nèi)存必須調(diào)出。當(dāng)一個(gè)應(yīng)用程序訪問數(shù)據(jù)庫 A 時(shí)，又得將數(shù)據(jù)庫 B 的數(shù)據(jù)庫內(nèi)存調(diào)出。您可以想象未來要發(fā)生的調(diào)頁次數(shù)有多少。

例 3 考慮如下配置： （所有頁的大小都是 4K）
服務(wù)器：

服務(wù)器上的物理 RAM 16GB
shmsys:shminfo_shmmax = 15099494 (16GB 的 ~90%)
數(shù)據(jù)庫：

IBMDEFAULTBP 350,000 頁
UTILHEAP 17,500 頁
DBHEAP 10,000 頁
LOCKLIST 1000 頁
PCKCACHE 5000 頁
CATALOGCACHE 2500 頁
ESTORE_SEG_SZ = 400000 頁
NUM_ESTORE_SEGS = 1
計(jì)算：

數(shù)據(jù)庫共享內(nèi)存 = (386,000 頁 x 4KB/頁 + 400,000 頁的 estore * 100 字節(jié)) x 1.1 = ~1.66GB
ESTORE memory = 400000 x 4KB = 1.6GB
問題： 數(shù)據(jù)庫共享內(nèi)存是 1.66GB。這個(gè)數(shù)小于 3.35GB 的數(shù)據(jù)庫共享內(nèi)存限制。shmmax 參數(shù)設(shè)置得比較恰當(dāng)。但是在啟動(dòng)數(shù)據(jù)庫時(shí)可能返回下面的錯(cuò)誤消息！您可以在 db2diag.log 中看到如下錯(cuò)誤消息：

2003-12-04-10.10.13.362027 Instance:db2inst1 Node:000
PID:18327(db2agent (SAMPLE) 0) TID:1 Appid:*LOCAL.sample.047844091013
oper system services sqloVLMAttachVLMSegment Probe:20 Database:SAMPLE
sqloVLMAttachVLMSegment - shmat failed
0xFFBE833C : 0x0000000C
shmat 是一個(gè) UNIX 函數(shù)，它將與 shmid（另一個(gè) Solaris 函數(shù)）所標(biāo)識(shí)的共享內(nèi)存相關(guān)的共享內(nèi)存段附加到調(diào)用進(jìn)程的數(shù)據(jù)段上。shmat 失敗于 0x000000C，即 ENOMEM 或可用數(shù)據(jù)空間不足以容納共享內(nèi)存段。

換句話說，不能激活數(shù)據(jù)庫或連接到數(shù)據(jù)庫，因?yàn)闆]有足夠的共享內(nèi)存來滿足請(qǐng)求。

那么該怎么辦呢？答案在于我們分配 ESTORE 的方式。每個(gè) ESTORE 段必須是一個(gè)連續(xù)的塊。在我們的例子中，我們?cè)噲D為 ESTORE 分配很大的一塊（連續(xù)的）內(nèi)存（1.6GB）。即使有 16GB 的 RAM，它也可能會(huì)被分段，從而沒有一塊連續(xù)的 1.6GB 的內(nèi)存。

為解決這個(gè)問題，在數(shù)據(jù)庫配置文件中像下面這樣設(shè)置 ESTORE 的值：

ESTORE_SEG_SZ = 40000 頁
NUM_ESTORE_SEGS = 10
通過設(shè)置上面的 ESTORE 值，實(shí)際上我們?nèi)匀辉噲D為 ESTORE 分配總共 1.6 GB 的內(nèi)存。然而，我們將嘗試為 ESTORE 分配 10 塊 160MB 的內(nèi)存。這樣分配的連續(xù)空間就要小得多，因此最有可能解決問題。

johndoe

內(nèi)存說明的好文.頂

action929

好文章啊，雖然后面的看不太懂

zhong0912

ibm網(wǎng)站上的文章，很多很多
redbook寫的還可以的

971726

收藏之，回家再拜讀！

Jens

好文，正需要。