Re: inefficient sql

From: <Laimutis.Nedzinskas_at_seb.lt>
Date: Fri, 1 Jun 2012 10:27:00 +0300
Message-ID: <OFFEEA1BC4.09C85BAF-ONC2257A10.0027ADA6-C2257A10.0028ED2D_at_seb.lt>



If you read/attended Tapio Lahdenmaki book/courses then he talked about regular reports. However, he stated explicitely:
  • developers have to put module/action (that's in Oracle terms) in their code. If not then the application is a nightmare to monitor. Very true.

You see that is not so about inneficient SQL but about a way to measure meaningfull work units. Then you can produce a top report (for tuning) or comparision report (for detecting regressions)

In a real life scenarious this is much more important than inneficient SQL which's only importance is eating of server resources. That by the way is easily detected by TopSQL reporting.

As for a sugested LIO ratio per row report then this metric is very usefull when attacking a particular problem: you have many SQL's in the top but they take equal resources, no one can be named as a suitable candidate for tuning. For example, that is typical for sql's with many executions: each of them completes in <0,01 second. Which one do you want to tune then? The app guys state that they do need billions of executions of each of them...

In addition to LIO I used this method with success: time taken by SQL must not exceed <cached buffer reads> * <30 micro secs for example>+ <physical disk reads> * <3 millisecs for example> I used this formula to catch some specific Oracle isssues. Blogged about that here
http://laimisnd.wordpress.com/2011/04/14/slow-sql-with-bind-variables-involving-object-types/


Please consider the environment before printing this e-mail

                                                                                                                                                 
  From:       "Stephens, Chris" <Chris.Stephens_at_adm.com>                                                                                         
                                                                                                                                                 
  To:         "'oracle-l_at_freelists.org'" <oracle-l_at_freelists.org>                                                                                
                                                                                                                                                 
  Date:       2012.05.29 23:15                                                                                                                   
                                                                                                                                                 
  Subject:    inefficient sql                                                                                                                    
                                                                                                                                                 





I'm interested in creating a daily report to run in our development environments to spot inefficient SQL early in the process. I've already got one that lists top ten highest elapsed time and top ten most frequently executed. They have helped tremendously in focusing on the right SQL. However, there is often SQL here that makes its way into integration and production that could be improved upon. (Yes I know where SQL falls in the optimization hierarchy and am well aware that business tasks are what are important but these reports have proved their value over and over.)

I'm pretty confident that a ratio of LIO's to rows returned by each row operation in an SQL execution plan is a good indicator of SQL efficiency. I think I've heard this in a few different presentations. I don't, however, recall what that ratio should be or if I'm misremembering completely.

What do you all consider good indicators of inefficient SQL and how to you identify those statements?

Thanks!
Chris

CONFIDENTIALITY NOTICE:
This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to 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 notify us immediately by email reply.

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Fri Jun 01 2012 - 02:27:00 CDT

Original text of this message