Problems with execution plans of OL queries in MGP

Question

I'm just facing some strange behavior of OL MGP process. Its' performance is really poor on one of our servers and I just executed Consperf to figure out that the execution plans looks really weird. It looks like OL doesn't use available indexes at all even though statistics are ok and even when I execute the same SQL manually I can see that the execution plan looks totally different - there are almost none TABLE ACCESS FULL lookups. Is there any OL setup property which could cause this strange behavior?
Consperf explain plan output for one of the snapshots:
********** BASE - Publication item query ***********
SELECT d.VISITID, d.TASKID, d.QTY FROM HEINAPS.PA_TASKS d
WHERE d.VisitID IN (SELECT h.VisitID FROM HEINAPS.PA_VISITS_H_LIST h WHERE h.DSM = ?)
| Operation | Name | Rows | Bytes| Cost | Optimizer
| SELECT STATEMENT | | 1 | 24 | 0 |ALL_ROWS
| FILTER | | | | |
| HASH JOIN RIGHT SEMI | | 2M| 61M| 20743 |
| TABLE ACCESS FULL |PA_VISITS_H_LIST | 230K| 2M| 445 |ANALYZED
| TABLE ACCESS FULL |PA_TASKS | 11M| 134M| 6522 |ANALYZED
explain plan result of the same query executed in Pl/SQL Developer:
UPDATE STATEMENT, GOAL = ALL_ROWS               Cost=3345     Cardinality=39599     Bytes=2969925
UPDATE     Object owner=MOBILEADMIN     Object name=CMP$JPHSK_PA_TASKS               
HASH JOIN ANTI               Cost=3345     Cardinality=39599     Bytes=2969925
TABLE ACCESS BY INDEX ROWID     Object owner=MOBILEADMIN     Object name=CMP$JPHSK_PA_TASKS     Cost=1798     Cardinality=39599     Bytes=910777
INDEX RANGE SCAN     Object owner=MOBILEADMIN     Object name=CMP$1527381C     Cost=239     Cardinality=49309     
VIEW     Object owner=SYS     Object name=VW_SQ_1     Cost=1547     Cardinality=29101     Bytes=1513252
NESTED LOOPS               Cost=1547     Cardinality=29101     Bytes=640222
INDEX RANGE SCAN     Object owner=HEINAPS     Object name=IDX_PAVISITSHL_DSM_VISITID     Cost=39     Cardinality=1378     Bytes=16536
INDEX RANGE SCAN     Object owner=HEINAPS     Object name=PK_PA_TASKS     Cost=2     Cardinality=21     Bytes=210
This query and also few others run in MGP for few minutes for each user, because of the poor execution plan. Is there any method how to force OL to use "standard" execution plans the DB produces to get MGP back to usable performance?

Answer 1

The problem is that the MGP process does not run the publication item query as such. What id does is wrap it up inside insert and update statements and then execute via java, and this is what can cause problems.
Set the trace to all for MGPCOMPOSE on a user, wait for the MGP cycle and you will find in the trace files a series of files for the user. Look through this and you should find the actual wrapped up query that is executed. This should also be in the consperf file. Consperf should give a few different execution stats for the query (ins_1, ins_2) if these are better then set these in c$consperf. The automatic setting does nort always choose the best one.
If all else fails, try expressing the query in other ways and test them in the MGP process. I have found that this kind of trial and error is the only approach
couple of bits about the query below
1) do you sopecifically need to restrict the columns from HEINAPS.PA_TASKS ? if not use select * in the PI select statement as it tends to bind better
2) what is the data type of HEINAPS.PA_VISITS_H_LIST.DSM. If numberic, then do a to_number() on the bind variable and the type casting is not very efficient