SQL statement is not performing

Question

Hi community,
I've a problem with a SQL statement.
First of all here's the statement and the explain plan for it:
select PPRJPOI.BBASE , PPRJPOI.CONTROLLINGAREA, PPRJPOI.COSTOBJTYPE , PPRJPOI.COSTOBJMAINPATH , PPRJPOI.COSTOBJSUBPATH ,
PPRJPOI.PPOSNUM , PPRJPOI.PPOSTXT , PPRJPOI.PPOSBTG , PPRJPOI.PDCWABL , PPRJPOI.PDCWNUM , PPRJPOI.PDCWBUD , PPRJPOI.PKTOORI ,
PPRJPOI.REFKEY1 , PPRJ.COSTCENTER , PPRJ.PATHELEM1 , PPRJSUB.PTPRTXT , LSUPPLIER.AADDRLINE1
from PPRJPOI
inner join PPRJ on PPRJ.BBASE = PPRJPOI.BBASE and PPRJ.CONTROLLINGAREA = PPRJPOI.CONTROLLINGAREA
and PPRJ.COSTOBJTYPE = PPRJPOI.COSTOBJTYPE and PPRJ.COSTOBJMAINPATH = PPRJPOI.COSTOBJMAINPATH
and PPRJ.COORGPATHELEM1 = ? and PPRJ.COORGPATHELEM2 = ? and PPRJ.COORGPATHELEM3 = ?
and PPRJ.COORGPATHELEM4 = ? and PPRJ.COORGPATHELEM5 = ?
inner join PPRJSUB on PPRJSUB.BBASE = PPRJPOI.BBASE and PPRJSUB.CONTROLLINGAREA = PPRJPOI.CONTROLLINGAREA
and PPRJSUB.COSTOBJTYPE = PPRJPOI.COSTOBJTYPE and PPRJSUB.COSTOBJMAINPATH = PPRJPOI.COSTOBJMAINPATH
and PPRJSUB.COSTOBJSUBPATH = PPRJPOI.COSTOBJSUBPATH
left outer join LSUPPLIER on LSUPPLIER.BBASE = PPRJPOI.BBASE and LSUPPLIER.LSUPPLIERNUM = PPRJPOI.PLFTNUM
where PPRJPOI.BBASE = ? and PPRJPOI.CONTROLLINGAREA = ? and PPRJPOI.COSTOBJTYPE = ?
and PPRJPOI.SUMSTS = ? and (PPRJPOI.MOVCOSTOBJMAINPATH is null or PPRJPOI.CLEAREDITEM = ?)
and (PPRJPOI.CLEAREDITEM ? or PPRJPOI.CLEAREDITEM is null)
and PPRJPOI.COYEARID = ? and (PPRJPOI.COPERIODNUM between ? and ? )
and PPRJPOI.BTS_CREATE <= TO_TIMESTAMP('27.10.2008 17:00:00')
and PPRJPOI.PATHELEM2 = ? and PPRJPOI.PATHELEM3 = ?
order by PPRJPOI.BBASE, PPRJPOI.CONTROLLINGAREA, PPRJPOI.COSTOBJTYPE,
PPRJPOI.COSTOBJMAINPATH, PPRJPOI.COSTOBJSUBPATH
| Id  | Operation                        | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                 |              |     1 |   489 |    40   (5)| 00:00:01 |
|   1 |  SORT ORDER BY                   |              |     1 |   489 |    40   (5)| 00:00:01 |
|*  2 |   FILTER                         |              |       |       |            |          |
|   3 |    NESTED LOOPS OUTER            |              |     1 |   489 |    39   (3)| 00:00:01 |
|   4 |     NESTED LOOPS                 |              |     1 |   439 |    38   (3)| 00:00:01 |
|*  5 |      HASH JOIN                   |              |     1 |   262 |    37   (3)| 00:00:01 |
|   6 |       TABLE ACCESS BY INDEX ROWID| PPRJ         |     1 |    95 |     1   (0)| 00:00:01 |
|*  7 |        INDEX RANGE SCAN          | PPRJ_ORA4    |     1 |       |     1   (0)| 00:00:01 |
|*  8 |       TABLE ACCESS BY INDEX ROWID| PPRJPOI      |    41 |  6847 |    36   (3)| 00:00:01 |
|*  9 |        INDEX SKIP SCAN           | PPRJPOI_ORA3 |    83 |       |    26   (0)| 00:00:01 |
|  10 |      TABLE ACCESS BY INDEX ROWID | PPRJSUB      |     1 |   177 |     1   (0)| 00:00:01 |
|* 11 |       INDEX UNIQUE SCAN          | PK_233       |     1 |       |     1   (0)| 00:00:01 |
|  12 |     TABLE ACCESS BY INDEX ROWID  | LSUPPLIER    |     1 |    50 |     1   (0)| 00:00:01 |
|* 13 |      INDEX UNIQUE SCAN           | PK_177597    |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(:13<=:14)
   5 - access("PPRJ"."BBASE"="PPRJPOI"."BBASE" AND
              "PPRJ"."CONTROLLINGAREA"="PPRJPOI"."CONTROLLINGAREA" AND
              "PPRJ"."COSTOBJTYPE"="PPRJPOI"."COSTOBJTYPE" AND
              "PPRJ"."COSTOBJMAINPATH"="PPRJPOI"."COSTOBJMAINPATH")
   7 - access("PPRJ"."BBASE"=:6 AND "PPRJ"."CONTROLLINGAREA"=:7 AND
              "PPRJ"."COSTOBJTYPE"=:8 AND "PPRJ"."COORGPATHELEM1"=:1 AND "PPRJ"."COORGPATHELEM2"=:2
              AND "PPRJ"."COORGPATHELEM3"=:3 AND "PPRJ"."COORGPATHELEM4"=:4 AND
              "PPRJ"."COORGPATHELEM5"=:5)
   8 - filter("PPRJPOI"."SUMSTS"=:9 AND ("PPRJPOI"."MOVCOSTOBJMAINPATH" IS NULL OR
              "PPRJPOI"."CLEAREDITEM"=:10) AND ("PPRJPOI"."CLEAREDITEM" IS NULL OR
              "PPRJPOI"."CLEAREDITEM"<>:11) AND "PPRJPOI"."BTS_CREATE"<=TO_TIMESTAMP('27.10.2008
              17:00:00'))
   9 - access("PPRJPOI"."BBASE"=:6 AND "PPRJPOI"."CONTROLLINGAREA"=:7 AND
              "PPRJPOI"."COSTOBJTYPE"=:8 AND "PPRJPOI"."COYEARID"=:12 AND "PPRJPOI"."COPERIODNUM">=:13
              AND "PPRJPOI"."PATHELEM2"=:15 AND "PPRJPOI"."PATHELEM3"=:16 AND
              "PPRJPOI"."COPERIODNUM"<=:14)
       filter("PPRJPOI"."PATHELEM3"=:16 AND "PPRJPOI"."PATHELEM2"=:15)
  11 - access("PPRJSUB"."BBASE"=:6 AND "PPRJSUB"."CONTROLLINGAREA"=:7 AND
              "PPRJSUB"."COSTOBJTYPE"=:8 AND "PPRJSUB"."COSTOBJMAINPATH"="PPRJPOI"."COSTOBJMAINPATH"
              AND "PPRJSUB"."COSTOBJSUBPATH"="PPRJPOI"."COSTOBJSUBPATH")
  13 - access("LSUPPLIER"."BBASE"(+)=:6 AND "LSUPPLIER"."LSUPPLIERNUM"(+)="PPRJPOI"."PLFT
              NUM")Additional infos:
Tablesize:
PPRJPOI - 44.500.000 rows
PPRJ - 7.013 rows
PPRJSUB - 1.150.000 rows
LSUPPLIER - 115.000 rows
Used indexes:
PPRJ_ORA4: index on PPRJ(BBASE, CONTROLLINGAREA, COSTOBJTYPE, COORGPATHELEM1, COORGPATHELEM2, COORGPATHELEM3 ,COORGPATHELEM4 , COORGPATHELEM5 , COORGPATHELEM6, COORGPATHELEM7, COORGPATHELEM8);
PPRJPOI_ORA3: index on PPRJPOI(BBASE, CONTROLLINGAREA, COSTOBJTYPE, COYEARID, COPERIODNUM, PATHELEM2, PATHELEM3, PATHELEM4, PATHELEM5, PATHELEM6, PATHELEM7, PATHELEM8);
PK_233: index on PPRJSUB(BBASE, CONTROLLINGAREA, COSTOBJTYPE, COSTOBJMAINPATH, COSTOBJSUBPATH);
PK_177597: index on LSUPPLIER(BBASE, LSUPPLIERNUM);
If I execute this statement I recieve a resultset which returns 5800 rows and takes about 70 seconds. Executing the same statement on DB2 returns the same number of rows but lasts only 15 seconds.
I would really appreciate, if anybody can help me optimizing this statement so that the execution time will be equal to the DB2..
Thanks in advance,
Tobias Schmidt
Edited by: tobiwan on Oct 31, 2008 1:01 PM

Answer 1

tobiwan wrote:
The statement we use is a prepared statement and the "?" are standing for the binding variables.
I generated the explain plan by adding the prefix "explain plan for" to the statement and fetching the result by executing the statement "SELECT * FROM TABLE(dbms_xplan.display)". The plan table was created with the Oracle script ($ORACLE_HOME\RDBMS\ADMIN\utlxplan.sql).The cardinality estimates of the plan posted seem to be way off if you say that the statement returns 5,800 records, but since you're using bind variables the optimizer in the case of an "EXPLAIN PLAN" just applies default selectivities, like 1% for an equal comparison 5% for a range comparison etc.
Note that you're using (a lot of) bind variables and therefore the output of EXPLAIN PLAN is only of limited help, because it doesn't/can't use the "bind variable peeking" that happens when the statement is actually executed.
So you need to find out the actual execution plan(s) used at run time. You can use the convenient DBMS_XPLAN.DISPLAY_CURSOR function in 10g to obtain that information. You just need to find out the SQL_ID of your statement if it is cached in the Shared Pool, e.g. by searching the V$SQL* views available, or you can check V$SESSION if you know that the statement is currently being executed.
You should check if you've histograms in place on the columns used with the bind variables, in a different thread I've provided already this useful blog note by the Pythian Group about this issue.
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Once you've obtained the actual execution plan(s, it could be multiple if you have histograms in place), post them here to find out if the cardinality estimates are still way off or what else could be the reason for the unexpected long execution time.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/