Optimize View

Question

Hi,
i want to optimize my view, because there are a lot of data and the select of the view is very slow.
I tried to use autotrace to analyze my view, but i never find a describtion of the output from autotrace.
SQL> select internenummer,anlagennummer,kundennummer,masternummer,anlagentyp,wasser,erdgas,fernwaerm
e,anlagenstatus,anlagenvondatum,anlagenbisdatum,abrechnungsgruppe,anlagentitel,anlagenzuname,anlagen
vorname,anlagenstrasse,anlagenhausnummer,anlagenhausnummernergaenzung,anlagenplz,anlagenort,anlagens
trassenschluessel,kundentitel,kundenzuname,kundenvorname,kundenstrasse,kundenhhausnummer,kundenhausn
ummernergaenzung,kundenplz,kundenort,aktuelleteilzahlung,letztehabenbuchung,datumletztehabenbuchung,
tagessaldo,datumletzterechnung,stromverbrauch,datum from EULVIS.EULVIS_STROM_STAMM;
211896 Zeilen ausgewählt.
Ausführungsplan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=764 Card=137345 Byte
s=27194310)
1 0 TABLE ACCESS (FULL) OF 'GIS_STAMM' (Cost=764 Card=137345 B
ytes=27194310)
Statistiken
0 recursive calls
0 db block gets
21616 consistent gets
7475 physical reads
0 redo size
52406292 bytes sent via SQL*Net to client
1851009 bytes received via SQL*Net from client
14128 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
211896 rows processed
SQL>
SQL> select internenummer,anlagennummer,kundennummer,masternummer,anlagentyp,wasser,erdgas,fernwaerm
e,anlagenstatus,anlagenvondatum,anlagenbisdatum,abrechnungsgruppe,anlagentitel,anlagenzuname,anlagen
vorname,anlagenstrasse,anlagenhausnummer,anlagenhausnummernergaenzung,anlagenplz,anlagenort,anlagens
trassenschluessel,kundentitel,kundenzuname,kundenvorname,kundenstrasse,kundenhhausnummer,kundenhausn
ummernergaenzung,kundenplz,kundenort,aktuelleteilzahlung,letztehabenbuchung,datumletztehabenbuchung,
tagessaldo,datumletzterechnung,stromverbrauch,datum from EULVIS.EULVIS_STROM_STAMM_WIN;
211896 Zeilen ausgewählt.
Ausführungsplan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=17059 Card=137345 By
tes=121687670)
1 0 VIEW OF 'EULVIS_STROM_STAMM_WIN' (Cost=17059 Card=137345 B
ytes=121687670)
2 1 SORT (ORDER BY) (Cost=17059 Card=137345 Bytes=27194310)
3 2 TABLE ACCESS (FULL) OF 'GIS_STAMM' (Cost=764 Card=1373
45 Bytes=27194310)
Statistiken
263 recursive calls
35 db block gets
7973 consistent gets
17822 physical reads
0 redo size
52238910 bytes sent via SQL*Net to client
1851009 bytes received via SQL*Net from client
14128 SQL*Net roundtrips to/from client
11 sorts (memory)
1 sorts (disk)
211896 rows processed
The second view is the same one but with an order by clause.
Please can anybody show me how i can intepret the output from autotrace?
With best regards
Nicole

Answer 1

Not sure what to say except that sorts are expensive.. and the bigger the dats set to sort, the more expensive the sorting is.
Also, I'm missing the logic behind selecting all the rows in a table for what seems to be a query that is expected to perform fast.
If this is an end-user query, then the result is totally meaningless. There is no way an end-user can make sense of that many rows, without processing these further (using Excel, Access, or whatever). In which case it begs the question as to why that additional processing is not done in Oracle.
If this is a batch-type query, then the reasoning and logic behind wanting to hit all the rows in a table with a serial process need to be analysed. This type of thing should be done in batch using parallel processing - that is the only way the batch processing will ever scale.