RE: inefficient sql
Date: Wed, 30 May 2012 09:22:44 -0500
Message-ID: <C970F08BBE1E164AA8063E01502A71CF01E2A068_at_WIN02.hotsos.com>
>> This ratio is, however, practically meaningless for SQLs that do
aggregates, such as COUNT, SUM, AVG, etc. Separating aggregate from regular SQLs would be the biggest challenge for an automated report.
Yes, you apply the ratio to the step just before the aggregation or grouping is done. You can get this from stat lines or a 10046 trace or data from various v$ views where you can see the rows returned per RSO. Then just apply the ratio to that line before the aggregation takes place, this gives you a better idea of how that SQL is doing from a LIO perspective. Doing this in an automated report would be tricky to say the least.
In the end you can have a report that will tell you about SQL with a high LIO/ROWs ratio, but you will have to be smart enough to figure out if that SQL really needs to be worked on or not. If it really were that simple to have a report that does this, I'm pretty sure Oracle would already have it.
Ric Van Dyke
Education Director
Hotsos Ltd
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Iotzov, Iordan
Sent: Wednesday, May 30, 2012 10:05 AM
To: 'Chris.Stephens_at_adm.com'; 'oracle-l_at_freelists.org'
Subject: RE: inefficient sql
LIO to rows is indeed a good ratio to monitor. This ratio is, however, practically meaningless for SQLs that do aggregates, such as COUNT, SUM, AVG, etc. Separating aggregate from regular SQLs would be the biggest challenge for an automated report.
Iordan Iotzov
http://iiotzov.wordpress.com/
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Stephens, Chris
Sent: Tuesday, May 29, 2012 4:15 PM
To: 'oracle-l_at_freelists.org'
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 This message and its attachments may contain legally privileged or confidential information. It is intended solely for the named addressee. If you are not the addressee indicated in this message (or responsible for delivery of the message to the addressee), you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments that does not relate to the official business of News America Incorporated or its subsidiaries must be taken not to have been sent or endorsed by any of them. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect. -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Wed May 30 2012 - 09:22:44 CDT