pajama

There is a delay being experienced when executing this command.

A DB2 FORCE APPLICATION command is an interrupt request.

When an agent executes a force, it will set a force flag for the application that it will force and depending on what the coordinator agent is doing, it will react accordingly by either waiting or sending him an interrupt.

In some cases, we will be in a wait mode. This is due to a encountering a higher priority.

When an interrupt is provided, each interrupt has priorities. The general rule of thumb DB2 will only interrupt the target if the target is working on a lower priority.

For example: If an application is in the middle of a rollback and if the user executes a DB2 FORCE APPLICATION command to force it, the database can go into a inconsistent state and therefore, we do not want that to happen. So DB2 will not interrupt the rollback. This control is implemented by the interrupt priority

In this example, just prior to the rollback, the priority will be increased so a lower priority agent in this case the force application will not interrupt him. Also, the force operation is an asynchronous operation. So if the application is in rollback processing, the agent doing the force will only mark the force flag of the application, but will not interrupt the application immediately. After the coordinator agent finishes the rollback, DB2 restores to the lower interrupt level (likely back to 0), and on various places in the code path, the agent checks for interrupt or force, so at this time, DB2 will notice the force and then react to it.

In conclusion, the delay is due to DB2 evaluating priorities prior to executing.

procstack output may show something like below:

0x0900000000251e80 semop(??, ??, ??) + 0xc0 
0x090000001535c9d4 semop@glue11(??, ??, ??) + 0x78 
0x090000001535c85c sqloSSemP__fdpr_3(??, ??, ??, ??) + 0x24 
0x09000000152981b0 sqlccipcrecv(SQLCC_COMHANDLE_T*,SQLCC_COND_T*)(??, ??) + 0xd8 
0x0900000014f579e0 sqlccrecv__fdpr_1(0x700000040000370, 
0x780000007078780, 0xf0000000f000, 0x1, 0x9000000188bcc38, 
0x8d0000000000008d, 0x0, 0x0) + 0x370 
0x0900000015a931b4sqljsDrdaAsNonCoordSPDrive(db2UCconHandle*,sqlerFmpCommInfo*)(??,
??) + 0x1b0

Some sub-agents still remain in database. These can't be forced. This is a current designed behavior of DB2 V9.5 and DB2 V9.7.

Note : DB2 V10.1 has design enhancements which will allow to force such sub-agents using the command.

Either of the following can be used to force the hanging application.

1) Recycle the instance. i.e Issue db2stop and db2start. Incase, recycling the instance is not possible then,

2) Terminate the active FMP processes which will wake up sub-agents.

For Example : Issue db2pd -fmp to find the active FMP processes. You can see output as shown below:

db2pd -fmp shows:

Database Partition 203 -- Active -- Up 3 days 23:55:01 -- Date 2012-09-27-11.34.33.831054

FMP:
Pool Size: 0
Max Pool Size: 200
Keep FMP: YES
Initialized: YES
Trusted Path: /db2home/db2inst1/sqllib/function/unfenced
Fenced User: bifenc
Shared Memory: 0x0780000000290420
IPC Pool: 0x0780000000290480

FMP Process:
Address FmpPid Bit Flags ActiveThrd PooledThrd ForcedThrd Active IPCList
0x07800000077BD000 38732016 64 0x00000002 2 1 0 Yes 0x0780000006FD1600

Active Threads:
Address FmpPid EduPid ThreadId
0x0780000006D3FDC0 38732016 13369 1029
0x0780000006FD0A80 38732016 20027 1286

Pooled Threads:
Address FmpPid ThreadId
0x07800000077BDA80 38732016 772

Forced Threads:
Address FmpPid ThreadId
No forced threads.