This goes with other answers.
At prep time, DB2 does a "lookup" in the cache to see if statement is
there. If yes execution willhappen. If not, it is compiled and then
DB2 "inserts" it in the cache, if there is room. If not, then an LRU
algorithm is used to inser it. It will stay there, even after a
connect reset, until DB2 needs the room.
If there's no room because all statements are servicing connections
then the cache will self extend. This will happen until the request
claims all available memory as defined in DATABASE_MEMORY parameter.
A snapshot, like db2mtrk command output, would show you the value
defined/value currently used/value high water mark.
I also believe but not quite sure as I haven't verified lately, that
DB2 will "park" the compiled statement in the application agent
private memory if all conditions stated above cannot make room for the
insertion. The idea being you should not get a no room available to
store your statement once compiled.
Reegards, Pierre.



On Apr 28, 2:09*pm, aj <ron...@mcdonalds.com> wrote:
> DB2 LUW 8.1 fixpak 14
> Red Hat EL AS 4.4
>
> I'm trying to diagnose some nocturnal CPU pressure, and am trying to
> understand the dynamic statement cache as it applies to LUW. *The only
> doc/redbooks I am finding are for Z/OS, which I am completely ignorant
> of.
>
> I am using only Java and JDBC in my applications. * No static SQL.
>
> How does dynamic statement cache work in LUW 8.1? * Is there a local
> statement cache? *I think there is a global statement cache (based
> upon the "get snapshot for dynamic sql on <db>" command), but how do I
> control it? *Is it always turned on? *Can I change its size?
>
> If I prepare a statement in a java app, will the compiled version
> of the statement remain in the cache after I have closed the
> PreparedStatement? *Will it remain after the java program completely
> exits?
>
> Any help appreciated.
>
> aj