Query and index modeling in 10g

From: VIVEK_SHARMA <VIVEK_SHARMA_at_infosys.com>
Date: Mon, 11 Sep 2006 16:58:10 +0530
Message-ID: <BBD944BCAC3AB4499DFBAFB1D8AF302001BF1441@BLRKECMSG11.ad.infosys.com>

Thanks Stephane, Dennis, List for responding.

We are doing this exercise for an identified "set" of MOST COMMONLY used "Logical" Transactions of our Application Product.

AIMs of the Exercise

Classify the respective SQL Queries from the above Logical Transactions
Possibly improve the response time of the corresponding SQL Queries by:-
Either RE-Writing them more optimally
OR by using a different type of index (Index organized table, B+ tree cluster, Hash cluster) as against the existing Normal Index which is currently in-use.

Seek your advice on the above.

Some additional Questions are in CAPITALS below.

Thanks indeed

Vivek

-----Original Message-----
From: Stephane Faroult [mailto:sfaroult_at_roughsea.com] Sent: Wednesday, September 06, 2006 1:34 AM To: VIVEK_SHARMA
Subject: Re: Query and index modeling in 10g

Vivek,

Your approach is interesting but there is such an array of possibilities

that it seems to me almost intractable. When I was with Oracle France

almost 20 years ago, a company (a spin-off from the main French Computer

Science State Research lab, INRIA) was trying to model the then much

simpler Oracle 6, with a view to providing a predictive tool. They were

doing it in partnership with Oracle. As far as I know, they went nowhere.

In my view, your approach can work in two particular cases:

The TPC case, where a set of functionally identical processes is used

to compare a combination of hardware and software,

Or if you define precisely some simple operations applied to YOUR

tables. Something as simple as a range scan is open to much

interpretation. How much of the total range do you scan? What is the

clustering factor of indexes?

IF COULD POINT US TO THIS SET OF VARIABLES PLEASE? WE SHALL EITHER TRY TO HANDLE THEM OR STATE THAT OUR RESULTS ARE SUBJECT TO SUCH LIMITATIONS. Those are questions the answer to which

may take your results out of even a loose range of plus/minus 20%, and

make your results unusable.

Actually, I would be almost more tempted by ranking queries on a

combination of syntax (number of SELECTs in the query, number of joins,

number of aggregates, etc.),

COULD YOU POSSIBLY POINT US TO SOME SAMPLE LINK/DOC OR BOOK ON THE ABOVE PLEASE? size of the three biggest tables involved

and selectivity of the criteria that are provided. And even so, it would

probably measure as much programmer proficiency as expected response

times. Especially as some of the worst programs I have seen were

repeatedly executing simple queries in loops of death.

Best regards,

Stéphane

CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** -- http://www.freelists.org/webpage/oracle-l

Received on Mon Sep 11 2006 - 06:28:10 CDT