DB2中内存的使用(10)

服务器：

• 服务器上的物理 RAM 1GB
• shmmax = 966 367 641 (1GB）
• shmseg = 120
• 服务器上的交换空间 500MB

数据库 A：

• IBMDEFAULTBP 100,000 页
• UTILHEAP 2500 页
• DBHEAP 10,000
• LOCKLIST 20,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页

数据库 B：

• IBMDEFAULTBP 160,000 页
• UTILHEAP 7,500 页
• DBHEAP 20,000 页
• LOCKLIST 10,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页

限制： 由于物理 RAM 只有 1GB，数据库共享内存集只能映射到它在物理上可以使用的空间，即 1GB + 交换空间。

计算：

• 数据库 A 共享内存 = (140,000 页 x 4KB/页) x 1.1% = ~616MB
• 数据库 B 共享内存 = (205,000 页 x 4KB/页) x 1.1% = ~902MB

问题： 分别激活或连接到数据库 A 或数据库 B 是可行的，但是不能并发进行。尝试同时激活这两个数据库将产生如下错误消息：
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

如果同时启动数据库 A 和数据库 B，需要至少 1.52GB (616MB + 902MB) 的共享内存。将数据库 A 映射到象限 4 （~0.75GB 可用共享内存）和将数据库 B 映射到象限 3 （~1GB）应该没有问题。但是，这一次，我们会受到物理内存的限制。显然，1GB 的 RAM 不足以处理 1.52GB 的共享内存映射。此外，SWAP 空间也被设置得太低。要解决这一问题：

• 尝试减少这两个数据库的缓冲池大小。或者
• 尝试将交换空间增加到物理 RAM 的两倍。或者
• 最好的解决方案是，增加更多的物理 RAM。在这种情况下，您将需要至少 2GB 的物理 RAM，才能同时启动这两个数据库。

例 3 考虑如下配置： （所有页的大小都为 4K）

服务器：

• 服务器上的物理 RAM 6GB
• Instance 1 （3 个数据库）

数据库 A：

• IBMDEFAULTBP 140,000 页
• UTILHEAP 7,500 页
• DBHEAP 20,000 页
• LOCKLIST 10,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页

数据库 B：

• IBMDEFAULTBP 80,000 页
• UTILHEAP 2500 页
• DBHEAP 10,000 页
• LOCKLIST 20,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页

数据库 C：

• IBMDEFAULTBP 130,000 页
• UTILHEAP 7,500 页
• DBHEAP 20,000 页
• LOCKLIST 10,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页

限制： 由于物理 RAM 只有 1GB，数据库共享内存集只能映射到它在物理上可以使用的那些空间，即 1GB + 交换空间。

计算：

• 数据库 A 共享内存 = (185,000 页 x 4KB/页) x 1.1% = ~814MB
• 数据库 A 应用程序组内存 = 20,000 页 x 4KB/页 = 80MB
• 数据库 B 共享内存 = (120,000 页 x 4KB/页) x 1.1% = ~528MB
• 数据库 B 应用程序组内存 = 20,000 页 x 4KB/页 = 80MB
• 数据库 C 共享内存 = (175,000 页 x 4KB/页) x 1.1% = ~770MB
• 数据库 C 应用程序组内存 = 20,000 页 x 4KB/页 = 80MB
• 要启动数据库 A，要求： 816MB + 80MB = ~894MB
• 要启动数据库 B，要求： 530MB + 80MB = ~608MB
• 要启动数据库 C，要求： 772MB + 80MB = ~850MB

问题： 启动数据库 A 和数据库 B 成功。但是启动数据库 C 时失败，并返回如下错误：
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

在这里，物理内存不是问题，因为我们有足够多的 RAM（6GB）。进一步的测试得处了以下启动组合：

• 启动 A + B ->成功
• 启动 B + C ->成功
• 启动 A + C ->不成功
• 启动 (A + B) + C ->不成功
• 启动 (B + C) + A ->不成功

组合 (A + B) 和组合 (B + C) 获得成功，因为它们初始化数据库所需的共享内存总量分别是 1.5GB (894 + 608) 和 1.46GB (608+850)。这低于 1.75GB 的共享内存限制，并且每个数据库共享内存段可以安全地连续映射到一个象限。而其他组合将失败于 SQL1478W，因为它们要么超出了 1.75GB 共享内存限制，要么不能在一个象限内为一个数据库分配连续的共享内存段。

要解决这一问题：

• 实现内存窗。最好的解决方案是定义 3 个 DB2 实例。将一个数据库恢复到每个实例。并为每个实例创建一个内存窗。这样一来，每个实例都可以完全访问它自己的 1GB 内存窗共享内存空间。注意： max_mem_windows 内核参数必须设为 2 （实例数 -1）。

32-位 Linux/Intel 中的 DB2 内存配置

图 12中展示了 32 位 Linux/Intel 上的 4GB 可寻址内存。

图 12 - Linux/Intel 中的 DB2 32 位内存地址空间

从 0x08048000 到 0x0FFFFFFF 的段是预留给 db2sysc 可执行程序的。从 0x10000000 到 0x3FFFFFFF 的段是实例共享内存，总共是 0.75GB。在默认情况下，DB2 共享库始于 0x40000000。

在低地址装载共享库，而将更多的空间留给数据库共享内存，这是可行的。（这也意味着用于实例共享内存的空间将更少。但是由于实例内存与数据库内存相比通常比较小，因此这样可以获得好处。）例如，如果在低于 0x40000000 的地址装载共享库，那么就可以在 0x38000000 装载数据库共享内存。如果在低于 0x2a000000 的地址装载共享库，那么就可以在 0x30000000 装载数据库共享内存，这样就有超过 2GB 的空间留给数据库共享内存。这些更改要求重新编译内核，我们在本文中不会对此加以讨论。请参考 Linux 手册中内核重编译那一节，以了解更多信息。

不过，对于 Redhat Advanced Server 和 SuSE SLES 8 上的 v8.1 FP2，DB2 将尝试自动将共享库重新分配到一个较低的地址，这样就不需要重新编译内核。在这些企业发行版中，有一个叫做 /proc/ pid/mapped_base 的文件包含了一个地址，共享库将从该地址装载到内存。在默认情况下，该地址是 0x40000000，但是我们可以把它降低一些（降到 0x20000000）。当 db2sysc 启动时，我们检查 mapped_base 文件是否存在。如果存在，则使用新的值并重新执行。然后，mapped_base 值发生了改变的进程中产生的每个进程都使用这个新值。

数据库共享内存（包括缓冲池）始于 0x50000000 （默认值）。它从 0x50000000 开始朝着堆栈方向向下增长。堆栈包含要执行的指令。堆栈从 0xC0000000 开始向上增长。

使数据库共享内存和堆栈不发生冲突，这一点很重要。我建议为堆栈使用 16MB 这么大的空间。在这样的情况下，我们有 ~1.73GB 用于数据库共享内存（从 0x50000000 到 0xC0000000，减去 16MB 的堆栈）。

在使用 "ulimit -a" 或 "ulimit -s" 显示限制时，这些值是以 1K 字节为单位显示的。

Stack = 16384

设置这个限制，使堆栈和共享内存地址空间不会相互冲突，这一点很重要。如果它们之间有冲突，那么实例就会崩溃，并发出信号 4 或信号 11。最后 1GB 的内存 被预留给 Linux 内核。