Increased Shared Pool size longer hot backup time?

Question

Hello,
I have hot backup that usually took 2 hours to complete. Then we had to increase Shared pool size from 280Mb to 380Mb due to some performance issue.
One week after increase of size the hot backup is taking 4 hours to complete. Since there was no other changes to the system I am suspecting size increase
of Shared Pool from 280Mb to 380Mb might be is reason for such drastic increase of backup time.
I would like to get your comments on my suspicion to the problem.
thank you

Answer 1

Paul.S wrote:
One week after increase of size the hot backup is taking 4 hours to complete. Since there was no other changes to the system I am suspecting size increase of Shared Pool from 280Mb to 380Mb might be is reason for such drastic increase of backup time.Hmm... at first glance it does not seem that this is the problem.. but perhaps it contributes to it.
When a SQL hits the SQL engine, the 1st thing the SQL engine does is determine if there is an existing parsed and ready-to-use copy of that SQL. If there is, that existing SQL is re-used - thus the name SQL Shared Pool. The resulting soft parse of the SQL is a lot faster (or should be) than a hard parse . A hard parse is where there is no re-usable copy, and the SQL needs to be parsed, validated and execution plan determined, etc.
Kind of like re-using an existing compiled program (with different input data) versus compiling that program before using it. (and that is what source SQL is - a program that needs to be compiled).
Okay, now what happens if there 100's of 1000's of SQLs in your shared pool? The scan that the SQL engine does to determine if there is a re-usable cursor, becomes pretty slow. A soft parse quickly becomes very expensive.
The problem is typically clients that create SQLs that are not sharable (where the input data is hardcoded into the program, instead of input variables to the program). In other words, SQLs that do not use bind variables.
Each and every hardcoded SQL that hits the SQL engine, is now a brand new SQL. And requires storage in the SQL Shared Pool. Shared Pool footprint grows and you start getting errors like insufficient shared pool memory.. and increase the shared pool which means even more space to store even more unique non-sharable SQLs and making soft and hard parses even more expensive.
Like moving the wall a few metres further and then running even faster into it. !http://www.pprune.org/forums/images/smilies2/eusa_wall.gif!
Now if the backup fires off a load of SQLs against the SQL engine, the fast soft/hard parses can now be a lot slower than previously, thanks to a larger shared pool that now caters for more junk than before.
Unsure if this is the problem that you are experiencing.. but assuming that your suspicion is correct, it offers an explanation as to why there can be a degradation in performance.