Lee,
Your query is doing a fair amount of disk IO.
I'm suspicious of the RANGE SCAN on the index ADDRESS_OCCUPANCY_I1.
Perhaps providing the SQL for the query, and the definition for
the indexes will give us a better idea of what's going on.
How many rows are in the table, and how many distinct values
are there for the columns making up the ADDRESS_OCCUPANCY_I1 index?
Could be that a hash join between ADDRESS_OCCUPANCY and
ADDRESS would be helpful.
Jared
On Fri, 2 Feb 2001, lerobe - Lee Robertson wrote:
> All,
>
> Oracle 8.0.5.0.0
> Tru64 4.0f
>
> See trace output below....
>
> call count cpu elapsed disk query current
> rows
> ------- ------ -------- ---------- ---------- ---------- ----------
> ----------
> Parse 0 0.00 0.00 0 0 0
> 0
> Execute 7056 0.59 0.53 0 0 0
> 3
> Fetch 7056 4.61 66.18 16127 84526 0
> 6973
> ------- ------ -------- ---------- ---------- ---------- ----------
> ----------
> total 14112 5.20 66.71 16127 84526 0
> 6976
>
> Misses in library cache during parse: 0
> Optimizer goal: CHOOSE
> Parsing user id: 45 (VM_USER)
>
> Rows Execution Plan
> ------- ---------------------------------------------------
> 0 SELECT STATEMENT GOAL: CHOOSE
> 0 SORT (ORDER BY)
> 0 NESTED LOOPS
> 0 NESTED LOOPS
> 0 TABLE ACCESS (BY INDEX ROWID) OF 'ADDRESS_OCCUPANCY'
> 0 INDEX (RANGE SCAN) OF 'ADDRESS_OCCUPANCY_I1' (NON-UNIQUE)
>
> 0 TABLE ACCESS (BY INDEX ROWID) OF 'ADDRESS'
> 0 INDEX (UNIQUE SCAN) OF 'ADDRESS_PK' (UNIQUE)
> 0 TABLE ACCESS (BY INDEX ROWID) OF 'POSTCODE_MOSAIC'
> 0 INDEX (UNIQUE SCAN) OF 'POSTCODE_PK' (UNIQUE)
>
> Can anyone see what is going wrong here. I haven't a clue yet performance is
> poor.
>
> PS. my tkprof interpretation skills are very much in their infancy.
>
> TIA
>
> Lee Robertson
> Acxiom
> Tel: 0191 525 7344
> Fax: 0191 525 7007
> Email: [EMAIL PROTECTED]
>
>
>
>
> The information contained in this communication is
> confidential, is intended only for the use of the recipient
> named above, and may be legally privileged. If the reader
> of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.
> If you have received this communication in error, please
> re-send this communication to the sender and delete the
> original message or any copy of it from your computer
> system.
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: lerobe - Lee Robertson
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
