On May 2, 10:12 pm, Syed Mustafa <syeds.must...@gmail.com> wrote: > On Sun, May 1, 2011 at 4:10 PM, faizal mangattil` > <faizmangat...@gmail.com>wrote: > > SQL TUINING.doc > 126KViewDownload > > > > > It is very helpful to me , if anybody can forward articles or PDF about > > query tuning with example. > > > regards > > faizal > > > -- > > You received this message because you are subscribed to the Google > > Groups "Oracle PL/SQL" group. > > To post to this group, send email to Oracle-PLSQL@googlegroups.com > > To unsubscribe from this group, send email to > > oracle-plsql-unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/Oracle-PLSQL?hl=en- Hide quoted text - > > - Show quoted text -
A few comments on the SQL TUNING document posted: The entry for 'DATA TYPE MISMATCH' is a problem usually with poorly written applications; most users should be aware of which columns are numbers and which are varchar2. It is worth mentioning but it's not widely found in industry. The 'Avoid functions on index columns' does not address the situation properly; the example query is not the only way that can be written where the function can be used and still use the index; additionally no mention is made of function-based indexes which are available to address this situation. It appears this 'advice' is based upon older releases of Oracle and is hardly relevant. The 'Using Where instead of Having' advice uses an example that is clearly showing how NOT to use Having; Having is for aggregate values, not string literals therefore any knowledgeable person would not write such a query. Prove that joins outperform nested queries and lcan always return the proper results; I have found on numerous occasions that advice is not true. The 'advice' to use truncate in place of delete is ludicrous unless the entire set of table data is being replaced. I know very few production systems that regularly 'gut' a table. I don't understand the 'advice' to use WHERE in place of ORDER BY; result set order is NOT guaranteed without an ORDER BY clauae and WHERE cannot substitute for it. Using IN instead of OR does nothing as Oracle rewrites the IN into an OR construct. The advice presented is old and in some cases outdated and no longer valid due to recent advancements in current releases of Oracle. Offering this as a tuning guide may have been acceptable with Oracle 7.2.x and 8.1.x but misses the mark considerably with versions 10.2.x and 11.x. My two cents. David Fitzjarrell -- You received this message because you are subscribed to the Google Groups "Oracle PL/SQL" group. To post to this group, send email to Oracle-PLSQL@googlegroups.com To unsubscribe from this group, send email to oracle-plsql-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Oracle-PLSQL?hl=en
