| |
Recently encountered such an interesting question: Is there a SQL statement, most of the time its execution time is several tens of milliseconds; but occasionally a particular execution time longer than 2 seconds. Because it is very sensitive to the application of the execution time of this statement, we must diagnose it because of what causes the occasional execution time is longer than 2 seconds.
Why is this issue challenging it? Because it is difficult to collect slow when 10046 trace: First, we do not know when this problem occurs, do not know what will happen in the session. If all-day open session 10046 trace, it will have a lot larger trace and affect overall database performance.
Fortunately, this database is 11g and 11g in the event ++ feature allows us only to a particular SQL collect 10046 trace. That in turn run 10046 trace when this SQL in SQL runs out after this Close 10046 trace. Such It can significantly reduce the size of the generated trace. But because we can not determine which session will be a problem, so long as the run-off of the session will have a SQL trace file.
Step is to open (put the following piece of SQL awsh60c8mpfu1 replace the SQL_ID):
alter system set events 'sql_trace [sql: awsh60c8mpfu1] level 12';
And the step is closed (put the following piece of SQL awsh60c8mpfu1 replace the SQL_ID):
alter system set events 'sql_trace [sql: awsh60c8mpfu1] off';
After collecting a lot of 10046 trace, and use tkprof format (specify AGGREGATE = NO, so that each execution would tkprof generate summary report), we finally locate the problem occurs when the SQL statement to read physical block has spent more much time. |
|
|
|