补充说明：对于第一个错误，如果你确信你的系统没有使用存储过程，那就不需要修改DB2_FPM_COMM_HEAPSZ这个变量。这个好像是和存储过程有关的。你只需要下面修改的2个变量就可以了，以前 我遇到这个错误时没有搞明白了，也修改了上面那个db2注册变量（其实是不用修改的，我那时也没有用到存储过程，过阵子再来看时才明白）。报这个错误主要是你的sql语句太长了，在应用程序和数据库代理程序传递的时候，ASLHEAPSZ这个缓冲区不够大，增加点就可以了。
关于第二个处理方法：可以按照作者给的值512，那个是2兆，初始值最大为256k，我们可以把他设置为1兆，不知道作者为什么要搞个2兆，当时出问题时我没搞懂就改这个参数了，现在在看看发现好像可以先改为1兆的（这2个参数主要都是sql语句太大的原因。）
错误信息：
ADM11003E DB2 failed to create the memory segment used for communication with fenced routines. If restarting DB2, ensure that no db2fmp processes are active on the instance prior to start. Otherwise,you can adjust the value through the FMP_COMM_HEAPSZ registry variable, or you can decrease the value of ASLHEAPSZ in the database manager configuration.
ADM11003E DB2 未能创建用于与受防护的例程通信的内存段。如果正在重新启动 DB2，则确保在启动之前没有 db2fmp 进程在实例上活动。否则，可通过 DB2_FMP_COMM_HEAPSZ 注册表变量调整值，也可以减小数据库管理器配置中的 ASLHEAPSZ 值。
ADM0501C A stack overflow exception has occurred. The DB2 instance has terminated abnormally. To remedy this problem, you may increase the default stack size for db2syscs.exe using the db2hdr utility as follows: db2hdr \sqllib\bin\db2syscs.exe /s:
ADM0501C 发生了堆栈溢出异常。DB2 实例已异常终止。要解决此问题，可以按如下所示使用 db2hdr 实用程序增加 db2syscs.exe 的缺省堆栈大小：db2hdr \sqllib\bin\db2syscs.exe /s:
在出现上述错误后，我们的连接程序在操作数据库是总是报：
SQL30081N 检测到通信错误。正在使用的通信协议："TCP/IP"。正在使用的通信API："SOCKETS"。检测到错误的位置："127.0.0.1"。检测到错误的通信函数："connect"。协议特定的错误代码："10061"、"*"、"*"。 SQLSTATE=08001
通过在DB2的帮助中心查询后：都是由于配置引起的错误。
针对错误ADM11003E在网上可以找到相关的信息，但是没有明确的指出解决的办法，但是知道了可以在系统崩溃以后通过杀死db2fmp进程后，DB2数据库可以重新启动。
我解决问题的方法是进行了下面俩项设置：
db2 update dbm cfg USING ASLHEAPSZ 20 IMMEDIATE
db2 update dbm cfg USING query_heap_sz 4000 IMMEDIATE
后经过跟踪，基本上没有再发生这个问题。
针对错误ADM0501C我在网上找到了一个很重要的资料，详细请见附件一，这个错误是由在我们进行复杂的查询时，系统报错，说我们的每个查询引起了一长串的RDS UCINTFC: pStatementText =DATA #1 : Hexdump, 3534 bytes从而数据库自动关闭了，我解决这个问题时只修改了一个参数配置：
db2 update dbm cfg USING agent_stack_sz 512 IMMEDIATE
后经过跟踪，基本上没有再发生这个问题。
以上是我在使用DB2遇到的一点问题的处理心得，仅供大家参考。
至于怎么执行DB2的命令，就是在运行了执行 db2cmd 就可以在启动的命令窗体执行命令了，详细资料请参考IBM Support网站http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
蚕豆：2006-6
附件1：
When dealing with stack overflow scenarios where the stack size needs to be increased, the executable of the header should only be modified if virtual address space is a concern, i.e. if there are many agents / databases living within an instance. Otherwise, it is sufficient to increase agent_stack_sz to something above 256K, eg. 512K. Note however, that increasing agent_stack_sz actually commits the space, i.e. uses real memory.
The PROBLEM::
-by default a stack space of 256K is reserved for each thread in db2syscs.exe regardless of agent_stack_sz. This information is stored in the header of executable. The Windows default is 1MB, and we override this to conserve virtual address space. AGENT_STACK_SZ is only the committed stack - it does not represent the limit.
-If we set agent_stack_sz to 512K, the reserved stack space is actually 1MB (the granularity for reserved stack space when specified on CreateThread is 256K -> 1MB -> 2MB -> 4MB)
-This means that if we only really need 512K, we are wasting 0.5MB of address space per agent, and this can add up - All resources for databases in an instance and ALL threads (agents,prefetchers, etc.) must live within the same 2GB address space on 32-bit Windows (3GB for NT / Win2K Advanced Server / Datacenter with /3GB switch in boot.ini).
There are two ways to increase the stack size. It is not necessary to do both.
Note the committed stack will be the value of agent_stack_sz regardless,
i.e. the committed memory will be max(agent_stack_sz, stack actually used).
1. modify the header of the executable (db2hdr will do this) - this is the default reserved stack space per thread. This affects ALL threads.
2. increase agent stack size. This only affects AGENT threads. This is the simplest and is the preferred method.
Disadvantages to (1):
- must be repeated after any upgrades
- increases stack space for *ALL* threads, not just agents, which may be significant if there are a large number of prefetchers & pagecleaners. This increases use of virtual address space.
Advantages to (1):
- more granularity - saves virtual address space by requiring less stack space for agents
Disadvantages to (2):
- wastes virtual address space by reserving excess stack space which may be unacceptable if there are a large number of agents and/or address space is otherwise constrained .
Advantages to (2):
- nothing to ship, supported and documented, change carries through upgrades
- affects only agents, which usually need the extra stack space during statement compilation
SUMMARY: Use agent_stack_sz to increase stack space unless there is a concern with virtual address space.
Examples. (assuming 2GB address space) Monitor Virtual bytes using perfmon.
1. 10 agents max - increase agent_stack_sz
2. 100 agents, 1 GB current private bytes max for db2syscs.exe - increase agent_stack_sz
3. 100 agents, 1.5GB current private bytes max for db2syscs.exe - modify the header
4. 500 agents, 1GB, current private bytes max for db2syscs.exe - modify the header
IMPORTANT:
when setting agent_stack_sz , set the value to be 1 4K page less than the desired maximum.
Windows adds an additional "guard page" to the specified size.
i.e. setting a value of 256K will mean 260K, and we jump up to the next level of granularity for reserved stack, eg. 1MB.
Examples:
agent_stack_sz <= 63 to stay within the range of reserving 256K of stack space.
agent_stack_sz <= 255 to stay withini the range of reserving 1MB of stack space
agent_stack_sz <= ( 1 4K page less than the default reserved stack space set with db2hdr )
SIMPLE FIX: set agent_stack_sz to 64, which is the minimum value which will increase the reserved stack to 1MB.
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=868931