Performance problem with relatively simple query

Question

Hi, I've a statement that takes over 20s. It should take 3s or less. The statistics are up te date so I created an explain plan and tkprof. However, I don't see the problem. Maybe somebody can help me with this?
explain plan
SQL Statement which produced this data:
  select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id  | Operation               |  Name              | Rows  | Bytes |TempSpc| Cost  |
|   0 | SELECT STATEMENT        |                    | 16718 |   669K|       | 22254 |
|   1 |  SORT UNIQUE            |                    | 16718 |   669K|    26M| 22254 |
|   2 |   FILTER                |                    |       |       |       |       |
|*  3 |    HASH JOIN            |                    |   507K|    19M|       |  9139 |
|   4 |     TABLE ACCESS FULL   | PLATE              | 16718 |   212K|       |    19 |
|*  5 |     HASH JOIN           |                    |   507K|    13M|  6760K|  8683 |
|*  6 |      HASH JOIN          |                    |   216K|  4223K|       |  1873 |
|*  7 |       TABLE ACCESS FULL | SDG_USER           |  1007 |  6042 |       |     5 |
|*  8 |       HASH JOIN         |                    |   844K|    11M|       |  1840 |
|*  9 |        TABLE ACCESS FULL| SDG                |  3931 | 23586 |       |     8 |
|  10 |        TABLE ACCESS FULL| SAMPLE             |   864K|  6757K|       |  1767 |
|* 11 |      TABLE ACCESS FULL  | ALIQUOT            |  2031K|    15M|       |  5645 |
|  12 |    INDEX UNIQUE SCAN    | PK_OPERATOR_GROUP  |     1 |     5 |       |       |
|  13 |    INDEX UNIQUE SCAN    | PK_OPERATOR_GROUP  |     1 |     5 |       |       |
|  14 |    INDEX UNIQUE SCAN    | PK_OPERATOR_GROUP  |     1 |     5 |       |       |
|  15 |    INDEX UNIQUE SCAN    | PK_OPERATOR_GROUP  |     1 |     5 |       |       |
Predicate Information (identified by operation id):
   3 - access("SYS_ALIAS_2"."PLATE_ID"="SYS_ALIAS_1"."PLATE_ID")
   5 - access("SYS_ALIAS_3"."SAMPLE_ID"="SYS_ALIAS_2"."SAMPLE_ID")
   6 - access("SYS_ALIAS_4"."SDG_ID"="SDG_USER"."SDG_ID")
   7 - filter("SDG_USER"."U_CLIENT_TYPE"='QC')
   8 - access("SYS_ALIAS_4"."SDG_ID"="SYS_ALIAS_3"."SDG_ID")
   9 - filter("SYS_ALIAS_4"."STATUS"='C' OR "SYS_ALIAS_4"."STATUS"='P' OR "SYS_ALIA
              S_4"."STATUS"='V')
  11 - filter("SYS_ALIAS_2"."PLATE_ID" IS NOT NULL)
Note: cpu costing is off
tkprof
TKPROF: Release 9.2.0.1.0 - Production on Mon Sep 22 11:09:37 2008
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Trace file: d:\oracle\admin\nautp\udump\nautp_ora_5708.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
alter session set sql_trace true
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        1      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 61 
SELECT distinct p.name
FROM lims_sys.sdg sd, lims_sys.sdg_user sdu, lims_sys.sample sa, lims_sys.aliquot a, lims_sys.plate p
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = a.sample_id
AND a.plate_id = p.plate_id
AND sd.status IN ('V','P','C')
AND sdu.u_client_type = 'QC'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.09       0.09          0          3          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      7.67      24.63      66191      78732          0         500
total        3      7.76      24.72      66191      78735          0         500
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 61 
Rows     Row Source Operation
    500  SORT UNIQUE
520358   FILTER 
520358    HASH JOIN 
  16757     TABLE ACCESS FULL PLATE
520358     HASH JOIN 
196632      HASH JOIN 
   2402       TABLE ACCESS FULL SDG_USER
834055       HASH JOIN 
   3931        TABLE ACCESS FULL SDG
864985        TABLE ACCESS FULL SAMPLE
2037373      TABLE ACCESS FULL ALIQUOT
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (object id 33865)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (object id 33865)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (object id 33865)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (object id 33865)
select 'x'
from
dual
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          3          0           1
total        3      0.00       0.00          0          3          0           1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 61 
Rows     Row Source Operation
      1  TABLE ACCESS FULL DUAL
begin :id := sys.dbms_transaction.local_transaction_id; end;
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0         12          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0         12          0           1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 61 
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.09       0.09          0          3          0           0
Execute      4      0.00       0.00          0         12          0           1
Fetch        2      7.67      24.63      66191      78735          0         501
total        9      7.76      24.72      66191      78750          0         502
Misses in library cache during parse: 3
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       48      0.00       0.00          0          0          0           0
Execute     54      0.00       0.01          0          0          0           0
Fetch       65      0.00       0.00          0        157          0          58
total      167      0.00       0.01          0        157          0          58
Misses in library cache during parse: 16
    4  user  SQL statements in session.
   48  internal SQL statements in session.
   52  SQL statements in session.
Trace file: d:\oracle\admin\nautp\udump\nautp_ora_5708.trc
Trace file compatibility: 9.00.01
Sort options: default
       1  session in tracefile.
       4  user  SQL statements in trace file.
      48  internal SQL statements in trace file.
      52  SQL statements in trace file.
      20  unique SQL statements in trace file.
     500  lines in trace file.Edited by: RZ on Sep 22, 2008 2:27 AM

Answer 1

A few notes:
1. You seem to have either a VPD policy active or you're using views that add some more predicates to the query, according to the plan posted (the access on the PK_OPERATOR_GROUP index). Could this make any difference?
2. The estimates of the optimizer are really very accurate - actually astonishing - compared to the tkprof output, so the optimizer seems to have a very good picture of the cardinalities and therefore the plan should be reasonable.
3. Did you gather index statistics as well (using COMPUTE STATISTICS when creating the index or "cascade=>true" option) when gathering the statistics? I assume you're on 9i, not 10g according to the plan and tkprof output.
4. Looking at the amount of data that needs to be processed it is unlikely that this query takes only 3 seconds, the 20 seconds seems to be OK.
If you are sure that for a similar amount of underlying data the query took only 3 seconds in the past it would be very useful if you - by any chance - have an execution plan at hand of that "3 seconds" execution.
One thing that I could imagine is that due to the monthly data growth that you've mentioned one or more of the tables have exceeded the "2% of the buffer cache" threshold and therefore are no longer treated as "small tables" in the buffer cache. This could explain that you now have more physical reads than in the past and therefore the query takes longer to execute than before.
I think that this query could only be executed in 3 seconds if it is somewhere using a predicate that is more selective and could benefit from an indexed access path.
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/