SEO

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

aj 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?

The package cache holds the compiled plans and its size is controlled
by the pckcachesz database config parameter. Not sure what you mean
by "local" vs. "global" statement cache (is this in relation to DPF?)

When another query is prepared, DB2 looks to see if the plan already
exists in the cache -- by using a byte-for-byte comparison of the SQL
statements. (i.e. "select * from t1" <> "select * FROM t1"). If
the statements match *exactly*, DB2 will use the existing plan.

Note, many things will invalidate some/all entries in the cache, like
table changes, index changes, runstats, and "FLUSH PACKAGE CACHE
DYNAMIC"

Every statement that is executed goes into the cache. I don't know
the specific algorithm for how the cache is maintained, but it's
almost certainly LRU-based (least-recently-used).

> 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?

Yes, and yes.

"aj" <ronald@mcdonalds.com> wrote in message
news:NeqdnYcK99d1j4vVnZ2dnUVZ_oesnZ2d@supernews.co m...
> 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

Package cache is global (for the database) and packages are not flushed out
when a connection that created the package is closed. They can be used by
any application connection. If DB2 finds an (absolutely) identical SQL
statements already in cache, it will use that access plan and will not have
to calculate a new one. The text of the SQL must be identical, including
spaces, etc.

It is best to use prepared statements with parameter makers ("?") if the
predicates change from one execution to the next, so that DB2 can reuse the
package in cache. If you use literals in the predicate, each statement will
be different, and little reuse will be possible.

The size is controlled by the PCKCACHESZ parm in the database configuration
(get db config for db-name). You can monitor package cache overflow in the
application snapshot.

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