DB2 FOR LUW / DB2FORLUW / 970 - DB2

For this problem to happen, the following conditions need to be 
true: 
 
1) An interrupt (or any possible error) is received with a 
specific timing during the execution of a query. 
 
2) The query in question features an access plan that contains a 
UNION operator that is on the left (probe) side of a HJSN. 
For example: 
             HSJN 
           /      \ 
     UNION        table 
  +----+-----+ 
leg0  leg1  leg2 
 
3) Although there is a very small chance that the problem could 
exist in other configurations, it is really more likely to 
happen in DPF. 
 
In the example access plan shown in item 2) above, the exact 
symptom that may occur will depend on what access plan logic 
exists in the union legs (leg0, leg1, and leg 2) 
In one case where the problem was seen, there was a hjsn in the 
union legs, and the problem caused an infinite loop. 
Another symptom might be a crash.  For example, a stack from 
such a crash might be: 
 
        sqldRowFetch 
        sqlriFetch 
        sqlrieoqp 
        sqlriftr 
        sqlriExecThread 
        sqlriunn 
        sqlriset 
        sqlriExecThread 
        sqlrihsjn 
        sqlriExecThread 
        sqlrihsjn 
        sqlriExecThread 
        sqlrihsjn 
        sqlriExecThread 
        sqlrihsjn 
        sqlriSectInvoke 
        sqlrr_dss_router 
        sqlrr_subagent_router 
        sqleSubRequestRouter 
        sqleProcessSubRequest 
        sqeAgent::RunEDU 
        sqzEDUObj::EDUDriver 
        sqloEDUEntry 
 
Due to the nature of this problem, it really depends on what is 
inside the union legs that will influence how the problem 
manifests. It could be a crash, hang, or other unexpected 
errors.  The key functions in the above stack to identify the 
problem are: 
 
sqlriunn 
sqlriset 
sqlriExecThread 
sqlrihsjn 
 
Different functions may appear above these functions in the 
stack of a crash case and it is not necessarily always the 
sqldRowFetch that would hit the problem. The issue itself is 
that an initial interrupt situation has occured at a specific 
timing when closing a hsjn that results in a failure to clean up 
the union structions below the hjsn in the plan.  If this query 
is executed a second time, then the dirty union structures can 
lead to error/crash/hang scenario's.

For this problem to happen, the following conditions need to be 
true: 
 
1) An interrupt (or any possible error) is received with a 
specific timing during the execution of a query. 
 
2) The query in question features an access plan that contains a 
UNION operator that is on the left (probe) side of a HJSN. 
For example: 
HSJN 
/ \ 
UNION table 
+----+-----+ 
leg0 leg1 leg2 
 
3) Although there is a very small chance that the problem could 
exist in other configurations, it is really more likely to 
happen in DPF. 
 
In the example access plan shown in item 2) above, the exact 
symptom that may occur will depend on what access plan logic 
exists in the union legs (leg0, leg1, and leg 2) 
In one case where the problem was seen, there was a hjsn in the 
union legs, and the problem caused an infinite loop. 
Another symptom might be a crash. For example, a stack from 
such a crash might be: 
 
sqldRowFetch 
sqlriFetch 
sqlrieoqp 
sqlriftr 
sqlriExecThread 
sqlriunn 
sqlriset 
sqlriExecThread 
sqlrihsjn 
sqlriExecThread 
sqlrihsjn 
sqlriExecThread 
sqlrihsjn 
sqlriExecThread 
sqlrihsjn 
sqlriSectInvoke 
sqlrr_dss_router 
sqlrr_subagent_router 
sqleSubRequestRouter 
sqleProcessSubRequest 
sqeAgent::RunEDU 
sqzEDUObj::EDUDriver 
sqloEDUEntry 
 
Due to the nature of this problem, it really depends on what is 
inside the union legs that will influence how the problem 
manifests. It could be a crash, hang, or other unexpected 
errors. The key functions in the above stack to identify the 
problem are: 
 
sqlriunn 
sqlriset 
sqlriExecThread 
sqlrihsjn 
 
Different functions may appear above these functions in the 
stack of a crash case and it is not necessarily always the 
sqldRowFetch that would hit the problem. The issue itself is 
that an initial interrupt situation has occured at a specific 
timing when closing a hsjn that results in a failure to clean up 
the union structions below the hjsn in the plan. If this query 
is executed a second time, then the dirty union structures can 
lead to error/crash/hang scenario's.

First fixed in DB2 Version 9.7 Fixpack 10.

NA

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

15.07.2014
18.12.2014
18.12.2014

9.7.FP10