Performance doubt: Manual tuning or Oracle tuning features?

Question

Hi all,
I'm reading some docs regarding performance, and most of then mention and recommend the use of the Oracle tuning features, as SQL Access Advisor, SQL Performance Analyzer, SQL Tuning Sets and so on. What i want to know from the most experienced dbas here is if you use these performance features from Oracle, or if you prefer to perform tuning tasks "by hand"?. By hand i mean checking the explain plan, checking statistics, index seletivity, histograms and so on.
Thanks in advance.

Answer 1

Fabricio_Jorge wrote:
Another simple doubt/question: What would be your tuning strategy? For example, what a commonly do is:
1) Check the object statistics.Yes, make sure statistics are current. The tricky part is that I have heard enough stories (not seen this myself) about new stats messing up performance that I prefer to save off the old stats before generating new ones - just in case
2) Check if the columns used in the predicates are indexed, and if not, i check the seletivity of then to see if an index creation would be efficient.This is probably my most effective tuning technique. I check the selectivity but create the index anyway to see what happens with it in place. Sometimes even though a new index is created the optimizer won't use it, and in other cases the index does not help performance even when the optimizer uses it. Any changes must be carefully checked.
3) If it is possible, create a materialized view with the query rewrite feature.I use MVs, but as a later resort. I prefer instead to recode SQL if possible to get better results to avoid having yet another database object to keep track of. With luck the optimizer can use the automated query rewrite capability to avoid changing the original SQL.
>
4) If it is a RAC env, i try to increase the CACHE value of the sequencesI have not worked on many RAC environments and when I have did not have much to do with sequences. I did learn that select list inline views often perform poorly compared to equivalent queries using table joins (not specifically a RAC issue)
>
5) Check the Memory and Segment Advisors and hit ratios, taking the necessary procedures, if the advisors indicate so.I am not usually given privileges to use these tools. I have gotten good results from the SQL tuning advisor when I can use it but have seen it miss things so I prefer to manually analyze SQL.
>
6) After all of this, i would try to tune the query by rewriting it. I leave this as a last option because generally you must know the data/env of the company that you are allocated. If you don't know the env very well, you can make bad recommendations about a specific
query.Doing the rewrite is something I do earlier in the process due to the fact that I rarely get DBA privilege on my projects and don't get access to some of the tools you mentioned. I can (hopefully) control SQL so I focus on it. Sometimes I cannot control SQL and have to rely on materailzed views, indexes, and other environmental factors to help SQL run faster.
>
OBS: All of this is done in parallel with the Statspack/AWR report "on hand"AWR is a great tool to use for tuning. OEM (which I rarely get access to) is another.