SQL Area Usage, Performance Problem

Question

Hi,
I'm a software engineer, not a DBA, with a lot of doubts about our production environment, but I think that I have found a problem at our production Database.
At our development database when I execute the same SQL statement over than onces, I can see this behaviour (for example):
* First execution 580 milisenconds.
* Second execution 21 milisencons.
As where I know, I understand that the compiled SQL statement is stored at the SQL Area, and by that reason the second execution is faster then the first one. Is that assumption correct?
If it is correct, I have a problem on our production Database because it does not work as expected. I have done a lot of trials, and SQL statement executions do not reduce her time execution when I do consecutive SQL execution.
Could you help me? I think that the parameter shared_pool_size value is too lower for our production server.
Thanks in advance.
Best Regards,
Joan

Answer 1

Just a comment about performance tuning and troubleshooting in general Joan.
It is very dangerous to base your conclusions on observation only. Consider the following example:
SQL> set timing on
SQL> select count(*) from all_objects;
COUNT(*)
10296
Elapsed: 00:00:18.38
SQL>
SQL> -- now using the magically warp speed hint
SQL> select /*+ WARP_SPEED */ count(*) from all_objects;
COUNT(*)
10296
Elapsed: 00:00:00.32
SQL>
From 18 seconds to less than half a second. It does look, based on pure observation of the results, that there is a WARP_SPEED hint in Oracle and it does increase performance dramatically. And we can also infer that this is an undocumented feature added by one of the Oracle kernel developers that is also a Star Trek fan. ;-)
But if we turn on SQL tracing (as suggested), we will see that the first SELECT did a lot of physical I/O. The 2nd SELECT did the same work, but without having to do the very expensive physical I/O - as the data blocks it need to hit (again) was now in memory (inside Oracle's buffer cache).
It had nothing to do with an invalid and non-existing CBO hint called WARP_SPEED.
The critical bit is KNOWING exactly what you are measuring when using this type of approach. If you do not know that, you are in no position to determine a sound and valid conclusion.
Side note on shared pool size - one of the worse mistakes can be to increase it. It can cause incredible damage to performance on an instance that deals with bindless/non-sharable SQL as the pool that Oracle needs to use to determine if a soft parse is possible gets to be huge.. without the benefit of being able to soft parse and forced to hard parse anyway. And that hard parse also now added to the size of the pool.