Re: Spotting the real cause of a Production slowdown (10g)

Charles,

I have seen similar problems in earlier versions of Oracle - many literal
statements and a large shared pool. Think about it -- when a new SQL
statement is received, Oracle must check to see if it has ever received that
statement before. The larger the shared pool, the more area it must scan. Of
course, it doesn't find a match, so it must parse the new statement. Then it
must find a spot in the shared pool to place the newly parsed statement.
Which means it must age something out. And if the application is hammering
Oracle with these statements inside a loop, it gets challenging for Oracle
to keep up. If this is the situation, the answer is not to increase the size
of the shared pool, because that just aggravates the problem.
    Rather than looking for the single statement that is getting issued the
most, you may want to look a lot of statements that are issued once but look
very similar, like
           select col1 from employee where empno = 1;
           select col2 from employee where empno = 2;
In our case, the solution was to get the developers to recode the worst
offenders to bind variables.
     Also, you didn't mention which Oracle processes were consuming so much
CPU.

Dennis Williams

Other related posts: