关于DB2的内存分配

多分区（multi-partitioned）数据库。 
启用了内部并行（intra-parallel）处理的未分区（non-partitioned）数据库。 
支持连接集中器的数据库。
注意：当 max_connections的值大于 max_coordagents的值时，连接集中器便被启用。这两个参数可以在数据库管理器配置中找到。（使用 GET DBM CFG 显示数据库管理器配置。） 

在以上环境中，应用程序通常需要不止一个的代理来执行其任务。允许这些代理之间能够彼此通信（相互发送/接收数据）很有必要。为了实现这一点，我们将这些代理放入到一个称作 应用程序组的组中。属于相同应用程序组的所有 DB2 代理都使用 应用程序组共享内存进行通信。 

应用程序组内存集是从数据库共享内存集中分配的。其大小由 appgroup_mem_sz数据库配置参数决定。 

多个应用程序可以指派给同一个应用程序组。一个应用程序组内可以容纳的应用程序数可以这样计算： appgroup_mem_sz / app_ctl_heap_sz 

在应用程序组内，每个应用程序都有其自己的 应用程序控制堆。此外，应用程序组共享内存中有一部分要预留给应用程序组共享堆。如下图所示： 

图 3 - DB2 应用程序组共享内存


 

例 1 考虑以下数据库配置： 

最大应用程序内存集大小 (4KB) (APPGROUP_MEM_SZ) = 40000 
最大应用程序控制堆大小 (4KB) (APP_CTL_HEAP_SZ) = 512 
用于应用程序组堆的内存所占百分比 (GROUPHEAP_RATIO) = 70
可以计算出下面的值： 



应用程序组共享内存集是： 40000 页 * 4K/页 = 160 MB 
应用程序组共享堆的大小是： 40000 * 70% = 28000 4K 页 = 114MB 
该应用程序组内可容纳的应用程序数为： 40000/512 = 78 
用于每个应用程序的应用程序控制堆为： (100-70)% * 512 = 153 4K 页 = 0.6MB
不要被 app_ctrl_heap_sz 参数迷惑。这个参数不是一个应用程序组内用于每个应用程序的各应用程序控制堆的大小。它只是在计算这个应用程序组内可容纳多少应用程序时用到的一个值。每个应用程序的实际应用程序控制堆大小都是通过 图 3中给出的公式计算的，这个公式就是 ((100 - groupheap_ratio)% * app_ctrl_heap_sz)。 

因此，groupheap_ratio 越高，应用程序组共享堆就越大，从而用于每个应用程序的应用程序控制堆就越小。

例 2 假设在一天中最忙的时间里，有 200 个应用程序连接到例 1 中所描述的数据库上。由于每个应用程序组可以容纳 78 个应用程序，因此我们需要 200/78 = 3 个应用程序组来容纳总共 200 个应用程序。这里应确保系统有足够多的 RAM 来支持这一配置。否则就会发生 SQL10003N 错误。 

代理私有内存

每个 DB2 代理进程都需要获得内存，以执行其任务。代理进程将代表应用程序使用内存来优化、构建和执行访问计划，执行排序，记录游标信息（例如位置和状态），收集统计信息，等等。为响应并行环境中的一个连接请求或一个新的 SQL 请求，要为一个 DB2 代理分配代理私有内存。

代理的数量受下面两者中的较低者限制：

论坛热门帖子:	[lch203] 写得蛮好的linux学习笔记(10-21) [黑马制造] 学习java的30个目标(10-19) [笑傲股林] 做测试半年了，有点迷茫，应该再学些什么提高自己的测试水平和测试能力呢？(10-19) [udp8589] 大家用google的来吱一声? 用百度的~~也来报道下?(10-18) [沂偌掳兆] 本人总结的一些认为C++比较经典的书籍，希望对大家有用(10-18)
TAG标签:	分配 内存 关于 数据库 共享 代理 DB2 一个 应用程序