Ignite PI for DB2 utilizes IBM built-in functions that are executed as Fenced Mode Processes on the DB2 database.  Routines run as Fenced Mode Processes are executed in a separate memory space from the database server in order to isolate the code from the database manager process.   The DB2 database configuration parameters KEEPFENCED and FENCED_POOL determine whether or not Fenced Mode Processes are kept after a call to a fenced routine completes. 

If KEEPFENCED is set to NO, a separate Fenced Mode Process is created and destroyed on every call to a fenced routine.  If KEEPFENCED is set to YES, Fenced Mode Processses are pooled and reused for multiple calls to fenced routines. 

The number of Fenced Mode Processes in the pool is determine by the configuration parameter FENCED_POOL.   If FENCED_POOL is set to 0, then pooling will be disabled and the value of KEEPFENCED will be ignored.  FENCED_POOL defaults to MAX_COORDAGENTS which should be sufficient in most cases.

Confio suggests setting KEEPFENCED to YES to avoid the overhead of creating and destroying Fenced Mode Processses.  Setting KEEPFENCED to YES also works around some known bugs in the DB2 Fenced  Mode Processes infrastructure.  The trade off is additional memory overhead on the server due to the additional cached processses.

You should try setting KEEPFENCED to YES in the following cases:

1. You are getting unexplained connection errors when attempting to monitor a DB2 database

2. You see errors or warnings in db2diag.log referring to fmp, db2fmp, or thread/process creation

3. You see high CPU usage on the DB2 database server when monitoring with Ignite PI