To improve performance of select

Hi all,
I premise that I'm not a Dba Administrator, but I must resolve a performance problem.
I read the Rob Van Wijk thread "When your query takes too long ..." and I'll post you my tkprof result
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4220.trc
Sort options: prsela exeela fchela
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
select a.CODI_AVVI, a.DESC_DENO_ENTE, a.DESC_DENO_ENTE_VISU, a.DESC_UFFI_ENTE, a.CODI_SIGL_PROV, a.NUME_AVVI,
a.DESC_OGGE_LAVO_VISU, a.DESC_LAVO DESC_LAVO_VISU, a.IMPO_AVVI_VISU, NVL(a.IMPO_RIBA_visu,0) IMPO_RIBA_visu,
ROUND(DECODE(a.PERC_RIBA,NULL, (((a.IMPO_AVVI-a.IMPO_RIBA)/(DECODE(a.IMPO_aVvi,0,1,a.IMPO_aVvi)))*100),a.PERC_RIBA),3) PERC_RIBA_VISU,
a.DESC_NOTE_IMPO, a.CODI_LEGG_VINC, a.CODI_TIPO_AVVI, a.CODI_AZIE, a.DESC_FINA_0001, a.DESC_FINA_0002, a.DATA_PUBL DATA_PUBL_VISU,
a.DATA_SCAD_VISU, a.DESC_SCAD_ORAA, a.DESC_SCAD_MINU, a.DATA_LICI_ESTE_RISU, a.CODI_IMPR_APPA, a.DESC_IMPR_AGGI, a.DESC_TIPO_AVVI_VISU,
a.DESC_NOTE_ENTE, a.FLAG_CATE_STIM , a.CODI_TIPO_AGGI, a.FLAG_CIRC, a.DESC_caap, a.DESC_prov, a.DESC_NUME_TELE01 , a.DESC_NUME_FAXX01 ,
a.DESC_INDI, a.DESC_ARTI_LEGG_BOLL DESC_ARTI_LEGG
FROM V_ASP_REPOANAGAVVISTAM a
WHERE (a.flag_risu in ('R','S') or (a.flag_risu='N' and a.NUME_DITT_INVI is not null))
AND (to_Date('01/01/2002','dd/mm/yyyy') <= A.DATA_SCAD OR A.DATA_SCAD is null)
and exists (select 1 from relaavvidettcate d where a.codi_avvi=d.codi_avvi and D.CODI_DETT_CATE IN ('114','115') )
and ( a.impo_avvi >= 1000 and a.impo_avvi <= 3000000 )
and decode(LENGTH(A.DATA_LICI), 10,to_date(A.DATA_LICI,'dd/mm/yyyy'), to_date(A.DATA_LICI,'mm/yyyy')) BETWEEN to_Date('04/2007','mm/yyyy') AND to_Date('05/2008','mm/yyyy')
and ( UPPER(a.desc_deno_ente) like '%COMUNE DI ROMA%' )
ORDER BY decode(LENGTH(A.DATA_LICI), 10,to_date(A.DATA_LICI,'dd/mm/yyyy'), to_date(A.DATA_LICI,'mm/yyyy')) DESC
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.37       0.38          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch       11      2.39       3.64        346     109663          0         139
total       13      2.76       4.02        346     109663          0         139
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
Rows     Row Source Operation
    139 SORT ORDER BY (cr=109663 pr=346 pw=0 time=3640309 us)
    139   NESTED LOOPS OUTER (cr=109663 pr=346 pw=0 time=3665123 us)
    139    NESTED LOOPS OUTER (cr=109659 pr=346 pw=0 time=3638446 us)
    139     NESTED LOOPS OUTER (cr=109659 pr=346 pw=0 time=3634127 us)
    139      NESTED LOOPS OUTER (cr=109379 pr=346 pw=0 time=3626615 us)
    139       NESTED LOOPS OUTER (cr=109256 pr=346 pw=0 time=3621185 us)
    139        NESTED LOOPS OUTER (cr=109115 pr=346 pw=0 time=3616587 us)
    139         HASH JOIN OUTER (cr=109005 pr=346 pw=0 time=3608065 us)
    139          NESTED LOOPS OUTER (cr=108989 pr=346 pw=0 time=36498189 us)
    139           NESTED LOOPS (cr=108848 pr=346 pw=0 time=36491383 us)
   1285            NESTED LOOPS OUTER (cr=106276 pr=346 pw=0 time=17103682 us)
   1285             NESTED LOOPS OUTER (cr=105171 pr=346 pw=0 time=17045852 us)
   1285              NESTED LOOPS (cr=103907 pr=346 pw=0 time=16979031 us)
50565               SORT UNIQUE (cr=2775 pr=0 pw=0 time=360760 us)
51193                TABLE ACCESS FULL RELAAVVIDETTCATE (cr=2775 pr=0 pw=0 time=271031 us)
   1285               TABLE ACCESS BY INDEX ROWID ANAGAVVI (cr=101132 pr=346 pw=0 time=3041988 us)
50565                INDEX UNIQUE SCAN PK_ANAGAVVI_CODIAVVI (cr=50567 pr=0 pw=0 time=762424 us)(object id 300074)
   1262              TABLE ACCESS BY INDEX ROWID PARATIPOAVVI (cr=1264 pr=0 pw=0 time=37709 us)
   1262               INDEX UNIQUE SCAN PK_PARATIPOAVVI_CODITIPO (cr=2 pr=0 pw=0 time=18013 us)(object id 300304)
   1103             TABLE ACCESS BY INDEX ROWID PARALEGG (cr=1105 pr=0 pw=0 time=35235 us)
   1103              INDEX UNIQUE SCAN PK_PARALEGG_CODILEGG (cr=2 pr=0 pw=0 time=16840 us)(object id 300245)
    139            TABLE ACCESS BY INDEX ROWID ANAGENTI (cr=2572 pr=0 pw=0 time=44695 us)
   1285             INDEX UNIQUE SCAN PK_ANAGENTI_CODIENTE (cr=1287 pr=0 pw=0 time=19447 us)(object id 300099)
    139           TABLE ACCESS BY INDEX ROWID PARAPROV (cr=141 pr=0 pw=0 time=4931 us)
    139            INDEX UNIQUE SCAN PK_CODIPROV (cr=2 pr=0 pw=0 time=1899 us)(object id 300286)
    781          TABLE ACCESS FULL ANAGIMPRPROG (cr=16 pr=0 pw=0 time=3167 us)
     54         TABLE ACCESS BY INDEX ROWID ANAGUFFIENTI (cr=110 pr=0 pw=0 time=5719 us)
     54          INDEX RANGE SCAN PK_ANAG_UFFI_ENTI_CODIUFFI (cr=56 pr=0 pw=0 time=1685 us)(object id 300135)
    139        INDEX UNIQUE SCAN PK_CODIPROVCOMU (cr=141 pr=0 pw=0 time=2599 us)(object id 300214)
     53       TABLE ACCESS BY INDEX ROWID ANAGIMPRAPPA (cr=123 pr=0 pw=0 time=3428 us)
     53        INDEX UNIQUE SCAN PK_ANAGIMPRAPPA_CODIIMPRAPPA (cr=70 pr=0 pw=0 time=1568 us)(object id 300103)
    139      TABLE ACCESS BY INDEX ROWID ANAGAZIERISU (cr=280 pr=0 pw=0 time=4380 us)
    139       INDEX UNIQUE SCAN PK_CODIAZIERISU (cr=141 pr=0 pw=0 time=2106 us)(object id 300080)
      0     TABLE ACCESS BY INDEX ROWID PARAFINA (cr=0 pr=0 pw=0 time=2975 us)
      0      INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=0 pr=0 pw=0 time=1158 us)(object id 300234)
      3    TABLE ACCESS BY INDEX ROWID PARAFINA (cr=4 pr=0 pw=0 time=3210 us)
      3     INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=1 pr=0 pw=0 time=1483 us)(object id 300234)
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 mode: ALL_ROWS
Parsing user id: 385
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.37       0.38          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch       11      2.39       3.64        346     109663          0         139
total       14      2.76       4.02        346     109663          0         139
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       34      0.03       0.03          0          0          0           0
Execute    200      0.01       0.01          0          0          0           0
Fetch      820      0.04       0.03          0       1009          0         645
total     1054      0.09       0.08          0       1009          0         645
Misses in library cache during parse: 3
Misses in library cache during execute: 3
    2 user SQL statements in session.
200 internal SQL statements in session.
202 SQL statements in session.
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4220.trc
Trace file compatibility: 10.01.00
Sort options: prsela exeela fchela
       1 session in tracefile.
       2 user SQL statements in trace file.
     200 internal SQL statements in trace file.
     202 SQL statements in trace file.
      25 unique SQL statements in trace file.
    2082 lines in trace file.
     355 elapsed seconds in trace file.I hope that I have problems on the full access of those table
ANAGAVVI (228650 records)
RELAAVVIDETTCATE (that have a PK of CODI_AVVI of ANAGAVVI and 394587records)
Well... I have yet those indexes on those table
AnagAvvi
1^ index
CREATE INDEX INDX_ANAGAVVI_NUMEAVVI
    ON ANAGAVVI("NUME_AVVI")
    TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE ( INITIAL 5120K NEXT 0K MINEXTENTS 1 MAXEXTENTS
    2147483645 PCTINCREASE 0)
    LOGGING2^ index
CREATE INDEX INDX_ANAGAVVI_NUMEAVVI02
    ON ANAGAVVI (SUBSTR("NUME_AVVI",2))
    TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE ( INITIAL 7168K NEXT 0K MINEXTENTS 1 MAXEXTENTS
    2147483645 PCTINCREASE 0)
    LOGGING3^ index PK_
CREATE UNIQUE INDEX PK_ANAGAVVI_CODIAVVI
    ON ANAGAVVI ("CODI_AVVI")
    TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE ( INITIAL 4096K NEXT 0K MINEXTENTS 1 MAXEXTENTS
    2147483645 PCTINCREASE 0)
    LOGGINGOn table RELAAVVIDETTCATE, I have only this index
CREATE UNIQUE INDEX PK_RELAAVVIDETTCATE_CODI
    ON RELAAVVIDETTCATE ("CODI_AVVI_DETT_CATE")
    TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE ( INITIAL 7168K NEXT 0K MINEXTENTS 1 MAXEXTENTS
    2147483645 PCTINCREASE 0)
    LOGGINGI have just found this configuration, so I didn't because it has done in this way.
If you need more information, I'll give all :)
Thank's for read this post
Paolo from Madrid

Hi Rob and Hi all,
sorry for the answer too late.
I'll post again my problems for the select that you'll find on the tkprof file of this post.
You can see the View V_ASP_REPOANAGAVVISTAM, in one of my messagge above.
When I produced tkprof, I have got this indexes
CREATE INDEX INDX_RELAAVVIDETTCATE_DETTCATE
    ON RELAAVVIDETTCATE("CODI_DETT_CATE")
    TABLESPACE "TS_SIAG_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE ( INITIAL 5120K NEXT 0K MINEXTENTS 1 MAXEXTENTS
    2147483645 PCTINCREASE 0)
    LOGGING
CREATE INDEX INDX_RELAAVVIPROV_CODIPROV
    ON RELAAVVIPROV("CODI_PROV")
    TABLESPACE "TS_SIAG_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE ( INITIAL 5120K NEXT 0K MINEXTENTS 1 MAXEXTENTS
    2147483645 PCTINCREASE 0)
    LOGGINGThere aren't on table AnagAvvi.
The Tkprof is this
TKPROF: Release 10.2.0.1.0 - Production on Lun Apr 28 13:50:42 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4160.trc
Sort options: prsela exeela fchela
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
select CODI_AVVI, NVL(IMPO_RIBA_visu,0) IMPO_RIBA_visu,
ROUND(DECODE(PERC_RIBA,NULL, (((IMPO_AVVI-IMPO_RIBA)/(DECODE(IMPO_aVvi,0,1,IMPO_aVvi)))*100),PERC_RIBA),3) PERC_RIBA_VISU
FROM V_ASP_REPOANAGAVVISTAM
WHERE (flag_risu in ('R','S') or (flag_risu='N' and NUME_DITT_INVI is not null))
AND (to_Date('01/01/2002','dd/mm/yyyy') <= DATA_SCAD OR DATA_SCAD is null)
and exists ( select 1 from relaavvidettcate d where codi_avvi=d.codi_avvi and D.CODI_DETT_CATE IN ('114','115') )
and ( impo_avvi >= 1000 and impo_avvi <= 3000000 )
and decode(LENGTH(DATA_LICI), 10,to_date(DATA_LICI,'dd/mm/yyyy'), to_date(DATA_LICI,'mm/yyyy')) BETWEEN to_Date('04/2007','mm/yyyy')
AND to_Date('05/2008','mm/yyyy') and ( UPPER(desc_deno_ente) like '%COMUNE DI ROMA%' )
ORDER BY decode(LENGTH(DATA_LICI), 10,to_date(DATA_LICI,'dd/mm/yyyy'), to_date(DATA_LICI,'mm/yyyy')) DESC
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.45       0.46          0          0          0           0
Execute      1      0.00       0.00          0          3          0           0
Fetch       18      0.62       0.61          0      19101          0         251
total       20      1.07       1.08          0      19104          0         251
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
Rows     Row Source Operation
    251 SORT ORDER BY (cr=19104 pr=0 pw=0 time=620275 us)
    251   FILTER (cr=19104 pr=0 pw=0 time=628996 us)
    251    NESTED LOOPS OUTER (cr=19101 pr=0 pw=0 time=627135 us)
    251     NESTED LOOPS OUTER (cr=19100 pr=0 pw=0 time=622610 us)
    251      NESTED LOOPS OUTER (cr=19100 pr=0 pw=0 time=617834 us)
    251       NESTED LOOPS OUTER (cr=18847 pr=0 pw=0 time=610298 us)
    251        NESTED LOOPS OUTER (cr=18716 pr=0 pw=0 time=605522 us)
    251         NESTED LOOPS OUTER (cr=18463 pr=0 pw=0 time=597736 us)
    251          HASH JOIN OUTER (cr=18370 pr=0 pw=0 time=591443 us)
    251           NESTED LOOPS OUTER (cr=18354 pr=0 pw=0 time=159246 us)
    251            NESTED LOOPS (cr=18352 pr=0 pw=0 time=127968 us)
   3732             NESTED LOOPS OUTER (cr=10886 pr=0 pw=0 time=536807 us)
   3732              NESTED LOOPS OUTER (cr=10884 pr=0 pw=0 time=443498 us)
   3732               TABLE ACCESS FULL ANAGAVVI (cr=10882 pr=0 pw=0 time=331524 us)
   3687               INDEX UNIQUE SCAN PK_PARATIPOAVVI_CODITIPO (cr=2 pr=0 pw=0 time=52258 us)(object id 300304)
   3158              INDEX UNIQUE SCAN PK_PARALEGG_CODILEGG (cr=2 pr=0 pw=0 time=47517 us)(object id 300245)
    251             TABLE ACCESS BY INDEX ROWID ANAGENTI (cr=7466 pr=0 pw=0 time=124877 us)
   3732              INDEX UNIQUE SCAN PK_ANAGENTI_CODIENTE (cr=3734 pr=0 pw=0 time=56423 us)(object id 300099)
    251            INDEX UNIQUE SCAN PK_CODIPROV (cr=2 pr=0 pw=0 time=3502 us)(object id 300286)
    781           TABLE ACCESS FULL ANAGIMPRPROG (cr=16 pr=0 pw=0 time=3159 us)
     91          INDEX RANGE SCAN PK_ANAG_UFFI_ENTI_CODIUFFI (cr=93 pr=0 pw=0 time=2887 us)(object id 300135)
    251         INDEX UNIQUE SCAN PK_CODIPROVCOMU (cr=253 pr=0 pw=0 time=3616 us)(object id 300214)
    102        INDEX UNIQUE SCAN PK_ANAGIMPRAPPA_CODIIMPRAPPA (cr=131 pr=0 pw=0 time=2804 us)(object id 300103)
    251       INDEX UNIQUE SCAN PK_CODIAZIERISU (cr=253 pr=0 pw=0 time=3684 us)(object id 300080)
      0      INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=0 pr=0 pw=0 time=2205 us)(object id 300234)
      6     INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=1 pr=0 pw=0 time=2330 us)(object id 300234)
      1    INLIST ITERATOR (cr=3 pr=0 pw=0 time=87 us)
      1     INDEX RANGE SCAN INDX_RELAAVVIDETTCATE_DETTCATE (cr=3 pr=0 pw=0 time=40 us)(object id 303246)
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.02          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        1      0.00       0.02          0          0          0           0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.45       0.46          0          0          0           0
Execute      2      0.00       0.02          0          3          0           0
Fetch       18      0.62       0.61          0      19101          0         251
total       21      1.07       1.10          0      19104          0         251
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       19      0.01       0.19          0          0          0           0
Execute     41      0.07       0.16          0          0          0           0
Fetch       51      0.00       0.03          0        118          0         162
total      111      0.09       0.39          0        118          0         162
Misses in library cache during parse: 5
Misses in library cache during execute: 5
    2 user SQL statements in session.
   41 internal SQL statements in session.
   43 SQL statements in session.
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4160.trc
Trace file compatibility: 10.01.00
Sort options: prsela exeela fchela
       1 session in tracefile.
       2 user SQL statements in trace file.
      41 internal SQL statements in trace file.
      43 SQL statements in trace file.
      10 unique SQL statements in trace file.
     455 lines in trace file.
      10 elapsed seconds in trace file.While the explain plain is this
PLAN_TABLE_OUTPUT
| Id | Operation                              | Name
| Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT                       |
PLAN_TABLE_OUTPUT
|     1 |   136 | 2452   (3)|
|   1 | SORT ORDER BY                         |
|     1 |   136 | 2452   (3)|
|   2 |   FILTER                               |
|       |       |            |
|   3 |    NESTED LOOPS OUTER                  |
|     1 |   136 | 2447   (3)|
PLAN_TABLE_OUTPUT
|   4 |     NESTED LOOPS OUTER                 |
|     1 |   133 | 2447   (3)|
|   5 |      NESTED LOOPS OUTER                |
|     1 |   130 | 2447   (3)|
|   6 |       NESTED LOOPS OUTER               |
|     1 |   125 | 2447   (3)|
|   7 |        NESTED LOOPS OUTER              |
|     1 |   120 | 2447   (3)|
PLAN_TABLE_OUTPUT
|   8 |         NESTED LOOPS OUTER             |
|     1 |   114 | 2447   (3)|
|   9 |          HASH JOIN OUTER               |
|     1 |   110 | 2446   (3)|
| 10 |           NESTED LOOPS OUTER           |
|     1 |   106 | 2440   (3)|
| 11 |            NESTED LOOPS                |
PLAN_TABLE_OUTPUT
|     1 |   102 | 2440   (3)|
| 12 |             NESTED LOOPS OUTER         |
|     1 |    52 | 2439   (3)|
| 13 |              NESTED LOOPS OUTER        |
|     1 |    49 | 2439   (3)|
| 14 |               TABLE ACCESS FULL        | ANAGAVVI
|     1 |    46 | 2439   (3)|
PLAN_TABLE_OUTPUT
| 15 |               INDEX UNIQUE SCAN        | PK_PARATIPOAVVI_CODITIPO
|     1 |     3 |     0   (0)|
| 16 |              INDEX UNIQUE SCAN         | PK_PARALEGG_CODILEGG
|     1 |     3 |     0   (0)|
| 17 |             TABLE ACCESS BY INDEX ROWID| ANAGENTI
|     1 |    50 |     1   (0)|
| 18 |              INDEX UNIQUE SCAN         | PK_ANAGENTI_CODIENTE
|     1 |       |     0   (0)|
PLAN_TABLE_OUTPUT
| 19 |            INDEX UNIQUE SCAN           | PK_CODIPROV
|     1 |     4 |     0   (0)|
| 20 |           TABLE ACCESS FULL            | ANAGIMPRPROG
|   781 | 3124 |     5   (0)|
| 21 |          INDEX RANGE SCAN              | PK_ANAG_UFFI_ENTI_CODIUFFI
|     1 |     4 |     1   (0)|
| 22 |         INDEX UNIQUE SCAN              | PK_CODIPROVCOMU
PLAN_TABLE_OUTPUT
|     1 |     6 |     0   (0)|
| 23 |        INDEX UNIQUE SCAN               | PK_ANAGIMPRAPPA_CODIIMPRAPPA
|     1 |     5 |     0   (0)|
| 24 |       INDEX UNIQUE SCAN                | PK_CODIAZIERISU
|     1 |     5 |     0   (0)|
| 25 |      INDEX UNIQUE SCAN                 | PK_PARAFINA_CODIFINA
|     1 |     3 |     0   (0)|
PLAN_TABLE_OUTPUT
| 26 |     INDEX UNIQUE SCAN                  | PK_PARAFINA_CODIFINA
|     1 |     3 |     0   (0)|
| 27 |    INLIST ITERATOR                     |
|       |       |            |
| 28 |     INDEX RANGE SCAN                   | INDX_RELAAVVIDETTCATE_DETTCATE
|       |       |     3   (0)|
PLAN_TABLE_OUTPUT
Note
   - 'PLAN_TABLE' is old version
[PRE]
Thank's for any suggestion

Similar Messages

Need to improve Performance of select...endselect query

Hi experts,
I have a query in my program like below with inner join of 3 tables.
In my program used select....endselect   again inside this select...endselect statements used..
While executing in production taking lot of time to fetch records. Can anyone suggest to improve performance of below query urgently...
Greatly appreciated ur help...
SELECT MVKEDWERK MVKEMATNR MVKEVKORG MVKEVTWEG MARA~MATNR
       MARAMTART ZM012MTART ZM012ZLIND ZM012ZPRICEREF
INTO (MVKE-DWERK , MVKE-MATNR , MVKE-VKORG , MVKE-VTWEG , MARA-MATNR
     , MARA-MTART , ZM012-MTART , ZM012-ZLIND , ZM012-ZPRICEREF )
FROM ( MVKE
       INNER JOIN MARA
       ON MARAMATNR = MVKEMATNR
       INNER JOIN ZM012
       ON ZM012MTART = MARAMTART )
       WHERE MVKE~DWERK IN SP$00004
         AND MVKE~MATNR IN SP$00001
         AND MVKE~VKORG IN SP$00002
         AND MVKE~VTWEG IN SP$00003
         AND MARA~MTART IN SP$00005
         AND ZM012~ZLIND IN SP$00006
         AND ZM012~ZPRICEREF IN SP$00007.
%DBACC = %DBACC - 1.
IF %DBACC = 0.
    STOP.
ENDIF.
CHECK SP$00005.
CHECK SP$00004.
CHECK SP$00001.
CHECK SP$00002.
CHECK SP$00003.
CHECK SP$00006.
CHECK SP$00007.
clear Check_PR00.
select * from A004
where kappl = 'V'
and kschl = 'PR00'
and vkorg = mvke-vkorg
and vtweg = mvke-vtweg
and matnr = mvke-matnr
and DATAB le sy-datum
and DATBI ge sy-datum.
if sy-subrc = 0.
select * from konp
where knumh = a004-knumh.
if sy-subrc = 0.
Check_PR00 = konp-kbetr.
endif.
endselect.
endif.
endselect.
CHECK SP$00008.
clear Check_ZPR0.
select * from A004
where kappl = 'V'
and kschl = 'ZPR0'
and vkorg = mvke-vkorg
and vtweg = mvke-vtweg
and matnr = mvke-matnr
and DATAB le sy-datum
and DATBI ge sy-datum.
if sy-subrc = 0.
select * from konp
where knumh = a004-knumh.
if sy-subrc = 0.
Check_ZPR0 = konp-kbetr.
endif.
endselect.
endif.
endselect.
CHECK SP$00009.
clear ZFMP.
select * from A004
where kappl = 'V'
and kschl = 'ZFMP'
and vkorg = mvke-vkorg
and vtweg = mvke-vtweg
and matnr = mvke-matnr
and DATAB le sy-datum
and DATBI ge sy-datum.
if sy-subrc = 0.
select * from konp
where knumh = a004-knumh.
if sy-subrc = 0.
ZFMP = konp-kbetr.
endif.
endselect.
endif.
endselect.
CHECK SP$00010.
clear mastercost.
clear ZDCF.
select * from A004
where kappl = 'V'
and kschl = 'ZDCF'
and vkorg = mvke-vkorg
and vtweg = mvke-vtweg
and matnr = mvke-matnr
and DATAB le sy-datum
and DATBI ge sy-datum.
if sy-subrc = 0.
select * from konp
where knumh = a004-knumh.
if sy-subrc = 0.
ZDCF = konp-kbetr.
endif.
endselect.
endif.
endselect.
CHECK SP$00011.
clear masterprice.
clear Standardcost.
select * from mbew
where matnr = mvke-matnr
and bwkey = mvke-dwerk.
Standardcost = mbew-stprs.
mastercost = MBEW-BWPRH.
masterprice = mBEW-BWPH1.
endselect.
ADD 1 TO %COUNT-MVKE.
%LINR-MVKE = '01'.
EXTRACT %FG01.
%EXT-MVKE01 = 'X'.
    EXTRACT %FGWRMVKE01.
ENDSELECT.
best rgds..
hari..

Hi there.
Some advices:
- why going to MVKE first and MARA then? You will find n rows in MVKE for 1 matnr, and then go n times to the same record in MARA. Do the oposite, i.e, go first to MARA (1 time per matnr) and then to MVKE.
- avoid select *, you will save time.
- use trace or measure performance in tcodes ST05 and SM30.
- replace:
select * from konp
where knumh = a004-knumh.
if sy-subrc = 0.
Check_ZPR0 = konp-kbetr.
endif.
endselect.
by
select * from konp
where knumh = a004-knumh.
Check_ZPR0 = konp-kbetr.
exit.
endselect.
Here, if I understood, you only need to atribute kbetr value to Check_ZPR0 if selecting anything (don't need the IF because if enters in select, subrc always equal to 0, and also don't need to do it several times from same a004-knumh - reason for the EXIT.
Hope this helps.
Regards.
Valter Oliveira.
Edited by: Valter Oliveira on Jun 5, 2008 3:16 PM

How to improve performance of select query when primary key is not referred

Hi,
There is a select query where we are unable to refrence primary key of the tables:
Since, the the below code is refrensing to vgbel and vgpos fields instead of vbeln and posnr..... the performance is very slow.
select vbeln posnr into (wa-vbeln1, wa-posnr1)
       from lips
       where ( pstyv ne 'ZBAT'
           and pstyv ne 'ZNLN' )
           and vgbel = i_vbap-vbeln
           and vgpos = i_vbap-posnr.
endselect.
Please le t me know if you have some tips..

hi,
I hope you are using the select statement inside a loop ...endloop get that outside to improve the performance ..
if not i_vbap[] is initial.
select vbeln posnr into table it_lips
from lips
for all entries in i_vbap
where ( pstyv ne 'ZBAT'
and pstyv ne 'ZNLN' )
and vgbel = i_vbap-vbeln
and vgpos = i_vbap-posnr.
endif.

How to improve Performance for Select statement

Hi Friends,
Can you please help me in improving the performance of the following query:
SELECT SINGLE MAX( policyterm ) startterm INTO (lv_term, lv_cal_date) FROM zu1cd_policyterm WHERE gpart = gv_part GROUP BY startterm.
Thanks and Regards,
Johny

long lists can not be produced with a SELECT SINGLE, there is also nothing to group.
But I guess the SINGLE is a bug
SELECT MAX( policyterm ) startterm
              INTO (lv_term, lv_cal_date)
              FROM zu1cd_policyterm
              WHERE gpart = gv_part
              GROUP BY startterm.
How many records are in zu1cd_policyterm ?
Is there an index starting with gpart?
If first answer is 'large' and second 'no'   =>   slow
What is the meaning of gpart? How many different values can it assume?
If many different values then an index makes sense, if you are allowed to create
an index.
Otherwise you must be patient.
Siegfried

How can we improve performance while selection production orders from resb

Dear all,
there is a performance issue in a report which compares sales order and production order.
Below is the code, in this while reading production order data from resb with the below select statement.
can any body tell me how can we improve the performance? should we use indexing, if yes how to use indexing.
*read sales order data
SELECT vbeln posnr arktx zz_cl zz_qty
INTO (itab-vbeln, itab-sposnr, itab-arktx, itab-zz_cl, itab-zz_qty)
FROM vbap
WHERE vbeln = p_vbeln
AND   uepos = p_posnr.
    itab-so_qty = itab-zz_cl * itab-zz_qty / 1000.
    CONCATENATE itab-vbeln itab-sposnr
       INTO itab-document SEPARATED BY '/'.
    CLEAR total_pro.
**read production order data*
    SELECT aufnr posnr roms1 roanz
    INTO (itab-aufnr, itab-pposnr, itab-roms1, itab-roanz)
    FROM resb
    WHERE kdauf = p_vbeln
    AND   ablad = itab-sposnr+2.

Himanshu,
Put a break point before these two select statements and execute in the production.This way you will come to know which select statement is taking much time to get executed.
In both the select statements the where clause is not having the primary keys.
Coming to the point of selecting the data from vbap do check the SAP note no:-185530 accordigly modify the select statement.
As far as the table RESB is concerened here also the where clause doesn't have the primary keys.Do check the SAP Note No:-187906.
I guess not using primary keys is maring the performance.
K.Kiran.

How to tune this query for the improve performance ?

Hi All,
How to tune this query for the improve performance ?
select a.claim_number,a.pay_cd,a.claim_occurrence_number,
case
when sum(case
when a.payment_status_cd ='0'
then a.payment_est_amt
else 0
end
)=0
then 0
else (sum(case
when a.payment_status_cd='0'and a.payment_est_amt > 0
then a.payment_est_amt
else 0
end)
- sum(case
when a.payment_status_cd<>'0'
then a.payment_amt
else 0
end))
end as estimate
from ins_claim_payment a
where a.as_of_date between '31-jan-03' and '30-aug-06'
and ( a.data_source = '25' or (a.data_source between '27' and '29'))
and substr(a.pay_cd,1,1) IN ('2','3','4','8','9')
group by a.claim_number, a.pay_cd, a.claim_occurrence_number
Thank you,
Mcka

Mcka
As well as EXPLAIN PLAN, let us know what proportion of rows are visited by this query. It may be that it is not using a full table scan when it should (or vice versa).
And of course we'd need to know what indexes are available, and how selective they are for the predicated you have in this query ...
Regards Nigel

Improve performance select in parameterized cursor.

DECLARE
CURSOR cur_inv_bal_ship_from(
l_num_qty_multiplier gfstmr4_eop_transaction_type.
inventory_multiplier_num%TYPE,
l_str_inventory_type gfstmr9_eop_txn_rule.inventory_type_code%TYPE,
l_str_type_code gfstmr9_eop_txn_rule.txn_type_code%TYPE)IS
SELECT /*+ USE_NL(EPP PI EPC) */ epc.currency_code,
SUM(ROUND(l_num_qty_multiplier * pi.inventory_qty * epc.cost_amt,2)) cost_amt
FROM gfstm62_eop_plant_part epp,
gfstm64_plant_inventory pi,
gfstm60_eop_part_cost epc
WHERE epp.gsdb_site_code = i_str_gsdb_site_code
AND epp.end_of_period_date = i_dt_end_of_period_date
AND pi.inventory_type_code = l_str_inventory_type
AND pi.txn_type_code = l_str_type_code
AND pi.gsdb_shipped_from_code = i_str_gsdb_site_code
AND epc.rate_set_code = i_str_rate_set_code
AND epc.financial_element_type_code = i_str_financial_element_code
AND pi.plant_eop_part_sakey = epp.eop_plant_part_sakey
AND pi.plant_inventory_sakey = epc.plant_inventory_sakey
GROUP BY currency_code;
BEGIN
FOR l_num_index IN i_tab_inv_txn_rule.FIRST .. i_tab_inv_txn_rule.LAST
LOOP
--Checking for ship from flag equal to 'Y'
IF i_tab_inv_txn_rule(l_num_index).ship_from_flag = g_con_y THEN
--Looping through ship from cursor
FOR l_rec_inv_bal_from IN cur_inv_bal_ship_from(
i_tab_inv_txn_rule(l_num_index).qty_multiplier_num,
i_tab_inv_txn_rule(l_num_index).inventory_type_code,
i_tab_inv_txn_rule(l_num_index).txn_type_code)
LOOP
--Incrementing index value
l_num_index1 := (l_num_index1 + 1);
--Assigning cursor values to PLSQL table
l_tab_inv_bal(l_num_index1).currency_code :=
l_rec_inv_bal_from.currency_code;
l_tab_inv_bal(l_num_index1).cost_amt :=
l_rec_inv_bal_from.cost_amt;
--Loop closing for ship from cursor
END LOOP;
END LOOP;
END;
The select query in the parameterized cursor taking long time. Below is the link in which i have shown the trace. Please let me know the way to improve performance.
http://performancetuning1978.blogspot.com/p/performance-tuning.html
thanks,
Vinodh

Hello,
your performance-tuning picture doesn't say much. How do your tables look like, how many rows, oracle version.
Why do you use nested-lööps as a hint?

FI-CA events to improve performance

Hello experts,
Does anybody use the FI-CA events to improve the extraction performance for datasources 0FC_OP_01 and 0FC_CI_01 (open and cleared items)?
It seems that this specific exits associated to BW events have been developped especially to improve performance.
Any documentation, guide should be appreciate.
Thanks.
Thibaud.

Thanks to all for the replies
@Sybrand
Please answer first whether the column is stored in a separate lobsegment.
No. Table,Index,LOB,LOB index uses the same TS. I missed adding this point( moving to separate TS) as part of table modifications.
@Hemant
There's a famous paper / blog post about CLOBs and Database Flashback. If I find it, I'll post the URL.
Is this the one you are referring to
http://laimisnd.wordpress.com/2011/03/25/lobs-and-flashback-database-performance/
By moving the CLOB column to different block size , I will test the performance improvement it gives and will share the results.
We dont need any data from this table. XML file contains details about finger prints and once the application server completes the job , XML data is deleted from this table.
So no need of backup/recovery operations for this table. Client will be able to replay the transactions if any problem occurs.
@Billy
We are not performing XML parsing on DB side. Gets the XML data from client -> insert into table -> client selects from table -> Upon successful completion of the Job from client ,XML data gets deleted.
Regarding binding of LOB from client side, will check on that side also to reduce round trips.
By changing the blocksize, I can keep db_32K_cache_size=2G and keep this table in CACHE. If I directly put my table to CACHE, it will age out all other operation from buffer which makes things worse for us.
This insert is part of transaction( Registration of a finger print) and this is the only statement taking time as of now compared to other statements in the transaction.
Thanks,
Arun

How to improve Performance of the Statements.

Hi,
I am using Oracle 10g. My problem is when i am Execute & fetch the records from the database it is taking so much time. I have created Statistics also but no use. Now what i have to do to improve the Performance of the SELECT, INSERT, UPDATE, DELETE Statements.
Is it make any differents because i am using WindowsXP, 1 GB RAM in Server Machine, and WindowsXP, 512 GB RAM in Client Machine.
Pls. Give me advice for me to improve Performance.
Thank u...!

What and where to change parameters and values ?Well, maybe my previous post was not clear enough, but if you want to keep your job, you shouldn't change anything else on init parameter and you shouldn't fall in the Compulsive Tuning Disorder.
Everyone who advise you to change some parameters to some value without any more info shouldn't be listen.
Nicolas.

Performance problems selecting form vbak and vbap

Hello,
I am try to select data from the vbak and vbap databasetables. The tables have more than a million of entries. I tried my best with two related selectstatements and the 'FOR All ENTRIES' syntax. The query takes more than 30 minutes. Is there a more efficient way than the following query, for example an inner join?. Tanks.
Regards, Lars.
FORM firstselect.
   SELECT kvkorg kvtweg kspart kauart k~kunnr
          kvsbed kaugru kvbeln kmandt
FROM VBAK AS k
INTO CORRESPONDING FIELDS OF TABLE t_outtab1
WHERE k~vkorg IN s_vkorg AND
         k~vtweg IN s_vtweg AND
         k~spart IN s_spart AND
         k~auart IN s_auart AND
         k~kunnr IN s_kunnr AND
         k~vsbed IN s_vsbed AND
         k~augru IN s_augru AND
         k~vbeln IN s_vbeln.
ENDFORM.
FORM secondselect.
     SELECT pposnr pvstel p~werks
              pabgru pmatnr p~kwmeng
              pzzurmeng pvrkme pmandt pvbeln
      FROM VBAP AS p
      INTO CORRESPONDING FIELDS OF TABLE t_outtab2
          FOR ALL ENTRIES IN t_outtab1
      WHERE
          p~vstel IN s_vstel AND
          p~werks IN s_werks AND
          p~matnr IN s_matnr AND
          p~abgru IN s_abgru AND
         t_outtab1-mandt = p~mandt AND
          p~vbeln = t_outtab1-vbeln.
ENDFORM.

FORM firstselect.
SELECT vkorg
       vtweg
       spart
       auart
       kunnr
       vsbed
       augru
       vbeln
       mandt
       FROM VBAK
       INTO TABLE t_outtab1
WHERE vkorg IN s_vkorg AND
vtweg IN s_vtweg AND
spart IN s_spart AND
auart IN s_auart AND
kunnr IN s_kunnr AND
vsbed IN s_vsbed AND
augru IN s_augru AND
vbeln IN s_vbeln.
ENDFORM.
FORM secondselect.
SELECT posnr
       vstel
       werks
       abgru
       matnr
       kwmeng
       zzurmeng
       vrkme
       mandt
      vbeln
FROM VBAP TABLE t_outtab2
FOR ALL ENTRIES IN t_outtab1
WHERE vbeln = t_outtab1-vbeln
AND vstel IN s_vstel AND
werks IN s_werks AND
matnr IN s_matnr AND
abgru IN s_abgru .
ENDFORM.
Hope this helps u.
I will get u back with more answers.
One more important thing see that the order which u r using in the select query is the same as that in the table this will affect the performs a lot.
<i><b>The first field should be the vbeln and then see the order and change that first and the same order should be in the internal table taht u r defining also.
If u do these things surely u can improve performance.</b></i>
Message was edited by: Judith Jessie Selvi

Performance with select in Start routine

Hi,
I open a request because i have some troubles in a update rules.
In this update rule i have several select function on master data and i takes just 3-4 minutes by packets (which is OK for my daily extraction). But my users needs now a data taht i need to extract from SD invoice ODS. and in this ODS i have 3 000000 lines.
I made the test and it takes too many times.
I try several solutions as :
Select.... into internal table --> too many times
Select ... for all entries .... into internal table...--> Too many times
I tried to create a small ODS with just the key level and data i need for my start routine based on invoice ODS. And i now from 3000000 to 300000 records. but now it takes 15 minutes by packets.
My question is do you have any idea to improve performance ?
What is the max size or number of records for an internal tables ?
Thanks
Cyril

Reading that much, you might have some memory issue.
"Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table."
if you need the link to the above doc....
http://help.sap.com/saphelp_47x200/helpdata/en/fc/eb3660358411d1829f0000e829fbfe/frameset.htm
thanks.
Wond

A64 Tweaker and Improving Performance

I noticed a little utility called "A64 Tweaker" being mentioned in an increasing number of posts, so I decided to track down a copy and try it out...basically, it's a memory tweaking tool, and it actually is possible to get a decent (though not earth-shattering by any means) performance boost with it. It also lacks any real documentation as far as I can find, so I decided to make a guide type thing to help out users who would otherwise just not bother with it.
Anyways, first things first, you can get a copy of A64 Tweaker here: http://www.akiba-pc.com/download.php?view.40
Now that that's out of the way, I'll walk through all of the important settings, minus Tcl, Tras, Trcd, and Trp, as these are the typical RAM settings that everyone is always referring to when they go "CL2.5-3-3-7", so information on them is widely available, and everyone knows that for these settings, lower always = better. Note that for each setting, I will list the measured cange in my SiSoft Sandra memory bandwidth score over the default setting. If a setting produces a change of < 10 MB/sec, its effects will be listed as "negligible" (though note that it still adds up, and a setting that has a negligible impact on throughput may still have an important impact on memory latency, which is just as important). As for the rest of the settings (I'll do the important things on the left hand side first, then the things on the right hand side...the things at the bottom are HTT settings that I'm not going to muck with):
Tref - I found this setting to have the largest impact on performance out of all the available settings. In a nutshell, this setting controls how your RAM refreshes are timed...basically, RAM can be thought of as a vast series of leaky buckets (except in the case of RAM, the buckets hold electrons and not water), where a bucket filled beyond a certain point registers as a '1' while a bucket with less than that registers as a '0', so in order for a '1' bucket to stay a '1', it must be periodically refilled (i.e. "refreshed"). The way I understand this setting, the frequency (100 MHz, 133 MHz, etc.) controls how often the refreshes happen, while the time parameter (3.9 microsecs, 1.95 microsecs, etc.) controls how long the refresh cycle lasts (i.e. how long new electrons are pumped into the buckets). This is important because while the RAM is being refreshed, other requests must wait. Therefore, intuitively it would seem that what we want are short, infrequent refreshes (the 100 MHz, 1.95 microsec option). Experimentation almost confirms this, as my sweet spot was 133 MHz, 1.95 microsecs...I don't know why I had better performance with this setting, but I did. Benchmark change from default setting of 166 MHz, 3.9 microsecs: + 50 MB/sec
Trfc - This setting offered the next largest improvement...I'm not sure exactly what this setting controls, but it is doubtless similar to the above setting. Again, lower would seem to be better, but although I was stable down to '12' for the setting, the sweet spot here for my RAM was '18'. Selecting '10' caused a spontaneous reboot. Benchmark change from the default setting of 24: +50 MB/sec
Trtw - This setting specifies how long the system must wait after it reads a value before it tries to overwrite the value. This is necessary due to various technical aspects related to the fact that we run superscalar, multiple-issues CPU's that I don't feel like getting into, but basically, smaller numbers are better here. I was stable at '2', selecting '1' resulted in a spontaneou reboot. Benchmark change from default setting of 4: +10 MB/sec
Twr - This specifies how much delay is applied after a write occurs before the new information can be accessed. Again, lower is better. I could run as low as 2, but didn't see a huge change in benchmark scores as a result. It is also not too likely that this setting affects memory latency in an appreciable way. Benchmark change from default setting of 3: negligible
Trrd - This controls the delay between a row address strobe (RAS) and a seccond row address strobe. Basically, think of memory as a two-dimensional grid...to access a location in a grid, you need both a row and column number. The way memory accesses work is that the system first asserts the column that is wants (the column address strobe, or CAS), and then asserts the row that it wants (row address strobe). Because of a number of factors (prefetching, block addressing, the way data gets laid out in memory), the system will often access multiple rows from the same column at once to improve performance (so you get one CAS, followed by several RAS strobes). I was able to run stably with a setting of 1 for this value, although I didn't get an appreciable increase in throughput. It is likely however that this setting has a significant impact on latency. Benchmark change from default setting of 2: negligible
Trc - I'm not completely sure what this setting controls, although I found it had very little impact on my benchmark score regardless of what values I specified. I would assume that lower is better, and I was stable down to 8 (lower than this caused a spontaneous reboot), and I was also stable at the max possible setting. It is possible that this setting has an effect on memory latency even though it doesn't seem to impact throughput. Benchmark change from default setting of 12: negligible
Dynamic Idle Cycle Counter - I'm not sure what this is, and although it sounds like a good thing, I actually post a better score when running with it disabled. No impact on stability either way. Benchmark change from default setting of enabled: +10 MB/sec
Idle Cycle Limit - Again, not sure exactly what this is, but testing showed that both extremely high and extremely low settings degrade performance by about 20 MB/sec. Values in the middle offer the best performance. I settled on 32 clks as my optimal setting, although the difference was fairly minimal over the default setting. This setting had no impact on stability. Benchmark change from default setting of 16 clks: negligible
Read Preamble - As I understand it, this is basically how much of a "grace period" is given to the RAM when a read is asserted before the results are expected. As such, lower values should offer better performance. I was stable down to 3.5 ns, lower than that and I would get freezes/crashes. This did not change my benchmark scores much, though in theory it should have a significant impact on latency. Benchmark change from default setting of 6.0 ns: negligible
Read Write Queue Bypass - Not sure what it does, although there are slight performance increases as the value gets higher. I was stable at 16x, though the change over the 8x default was small. It is possible, though I think unlikely, that this improves latency as well. Benchmark change from default setting of 8x: negligible
Bypass Max - Again not sure what this does, but as with the above setting, higher values perform slightly better. Again I feel that it is possible, though not likely, that this improves latency as well. I was stable at the max of 7x. Benchmark change from the default setting of 4x: negligible
Asynch latency - A complete mystery. Trying to run *any* setting other than default results in a spontaneous reboot for me. No idea how it affects anything, though presumably lower would be better, if you can select lower values without crashing.
...and there you have it. With the tweaks mentioned above, I was able to gain +160 MB/sec on my Sandra score, +50 on my PCMark score, and +400 on my 3dMark 2001 SE score. Like I said, not earth-shattering, but a solid performance boost, and it's free to boot. Settings what I felt had no use in tweaking the RAM for added performance, or which are self-explanatory, have been left out. The above tests were performed on Corsair XMS PC4000 RAM @ 264 MHz, CL2.5-3-4-6 1T.

Quote
Hm...I wonder which one is telling the truth, the BIOS or A64 tweaker.
I've wondered this myself. From my understanding it the next logic step from the WCREDIT programs. I understand how clock gen can misreport frequency because it's probably not measuring frequency itself but rather a mathmatical representation of a few numbers it's gathered and one clk frequency(HTT maybe?), and the non supported dividers messes up the math...but I think the tweaker just extracts hex values strait from the registers and displays in "English", I mean it could be wrong, but seeing how I watch the BIOS on The SLI Plat change the memory timings in the POST screen to values other then SPD when it Auto with agressive timings in disabled, I actually want to side with the A64 tweaker in this case.
Hey anyone know what Tref in A64 relates to in the BIOS. i.e 200 1.95us = what in the BIOS. 1x4028, 1x4000, I'm just making up numbers here but it's different then 200 1.95, last time I searched I didn't find anything. Well I found ALOT but not waht I wanted..

Improving Performance

Hi Experts,
How can we improve the performance of the select with out creating an secondary index?
In my select query am not using primary fields in where condation.
so i want to know that how can we improve the performance .
one more thing is that if we r creating secondary index what are the disadvantages of that?
Thanks & Regards,
Amit.

If you select from a table without using an appropriate index or key, then the database will perform a table scan to get the required data. If you accept that this will be slow but must be used, then the key to improving performance of the program is to minimise the number of times it does the scan of the table.
Often the way to do this is not what would normally be counted as good programming.
For example, if you SELECT inside a loop or SELECT using FOR ALL ENTRIES, the system can end up doing the table scan a lot of times because the SQL is broken up into lots of individual/small selects passed to the database one after the other. So it may be quicker to SELECT from the table into an internal table without specifying any WHERE conditions, and then delete the rows from the internal table that are not wanted. This way you do only a single table scan on the database to get all records. Of course, this uses a lot of memory - which is often the trade off. If you have a partial key and are then selecting based on non idexed fields, you can get all records matching the partial key and then throw away those where the remaining fields dont meet requirements.
Andrew

How to improve performance of the attached query

Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1

duplicate thread..
How to improve performance of attached query

How to improve performance of attached query

Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1

duplicate thread..
How to improve performance of attached query

To improve performance of select

Similar Messages

Maybe you are looking for