index strategy on SQL tuning
DBAsupport.com Forums - Powered by vBulletin
Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: index strategy on SQL tuning

  1. #1
    Join Date
    Mar 2001
    Posts
    286

    index strategy on SQL tuning

    Hi,

    For the following query, the cost of table join between t0, t1 and t3 is very expensive. For all t1's columns used in the where clauses, I created one composite index on t1 to improve the table join. The execution plan shows the index is being used. However, the cost only reduces 10%. The actual execution time does not change too much, either. Any suggestion? Thank you.

    What's your general indexing strategy? Assuming I am not concerned about the cost of maintaining the index, is it the best strategy to create indexes on ALL the columns used in the where clauses?


    SELECT t1.proj_id
    FROM client t0, proj t1, ref t2, proj_case t3, background_report t4
    WHERE t0.comp_id IN (:sys_b_00)
    AND t0.case_id = t1.assigned_to_case_id
    AND t1."STATUS" = :sys_b_01
    AND t1.ref_id = t2.ref_id
    AND t2.ref_status IN (:sys_b_02, :sys_b_03, :sys_b_04)
    AND t1.primary_case_id = t3.proj_case_id
    AND t3.background_report_id = t4.background_report_id(+)

  2. #2
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    If your SQL outputs more than 15 % of rows from a table, then you don't need to create an index.

    How ever, for efficient joining between 2 tables, you need to have indexes on both tables.

    Tamil

  3. #3
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    Originally posted by tamilselvan
    If your SQL outputs more than 15 % of rows from a table, then you don't need to create an index.
    * sharp-intake-of-breath *

    Do we need to have a talk about clustering factor again?
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  4. #4
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    Originally posted by tamilselvan
    How ever, for efficient joining between 2 tables, you need to have indexes on both tables.
    * another-sharp-intake-of-breath *

    I would say that it sometimes helps to have an index on one table -- depends on the type of join and the data volumes involved.
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  5. #5
    Join Date
    Dec 2002
    Location
    Bangalore ( India )
    Posts
    2,434
    Originally posted by slimdave
    * sharp-intake-of-breath *

    Do we need to have a talk about clustering factor again?

    Tamil :

    I would be sure that Dave is pointing to % of Blocks than Rows..

    Aint it Dave.. to my mem we (myself & u) have had enough on this topic in some post..
    funky...

    "I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."

    "Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"

  6. #6
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  7. #7
    Join Date
    Dec 2002
    Posts
    36
    Hi,

    1. Query execution timing difference with or without indexes may
    not be much if the tables you are joining are small (few
    hundred thousand rows).

    2. For joining large tables (million's of rows) you don't
    need an index on any column in the where clause.

    3. Multi table query will join the tables first and then
    filter the rows according to the where clause. You should
    not be having an index lookup for the filter.

    4. Comparing the trace is the way to go.
    Check the trace for query with and without indexes.
    fossil

  8. #8
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    Originally posted by fossil
    2. For joining large tables (million's of rows) you don't
    need an index on any column in the where clause.

    3. Multi table query will join the tables first and then
    filter the rows according to the where clause. You should
    not be having an index lookup for the filter.
    These statements are obviously wrong.
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  9. #9
    Join Date
    Dec 2002
    Posts
    36
    SlimmDave, Try them with/without indexes and check it out yourself.
    fossil

  10. #10
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by fossil
    SlimmDave, Try them with/without indexes and check it out yourself.
    Why wasting time in trying your suggestions? Anyone that has ever seriously worked with Oracle database knows that each of your four suggestions are total nonsence.
    (Well, the last one can not be disputed, however in most cases you don't realy need to trace the session to come to conclusions - there are other much more lightweight methods to get the same information).
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width