By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,002 Members | 2,194 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,002 IT Pros & Developers. It's quick & easy.

Making stored procedures resident in memory

P: n/a
I am trying to determine the behaviour of stored procedures in DB2 V8.2.x in
Windows/Unix/Linux and how I can control that behaviour. Some documentation
in the manuals is confusing the issue somewhat.

First, am I right in understanding that the normal behaviour of a stored
procedure, fenced or unfenced, is to only go into memory when it is invoked
and to be swapped out of memory when it is not needed any more?

Second, am I right in understanding that setting KEEPFENCED = YES in the DBM
config parameters is the way to override the default behaviour and force the
stored procedure to stay resident even when it is not used?

Now, a word about the confusion in the manuals. I was researching this
question in the manuals and found a topic entitled "Specifying general
properties". It says that there is an option for 'Stay resident at exit' in
the Create Procedure notebook in the Development Center. The problem is that
I can't find any such option anywhere. I suspect that the manual is not in
sync with the code in the Development Center. I am experiencing this on a
V8.2.2 copy of DB2 at a client site.

Am I just particularly dense today or am I right that there is no such
setting for stored procedures? If I am being dense and I can set this value,
could someone tell me EXACTLY how to get to the panel that has this option?

If the manual is wrong, what's the best way to notify the technical writers
so that they can fix this?

Rhino

Nov 12 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message
news:47********************@magma.ca...
I am trying to determine the behaviour of stored procedures in DB2 V8.2.x in Windows/Unix/Linux and how I can control that behaviour. Some documentation in the manuals is confusing the issue somewhat.

First, am I right in understanding that the normal behaviour of a stored
procedure, fenced or unfenced, is to only go into memory when it is invoked and to be swapped out of memory when it is not needed any more?
Correct.
Second, am I right in understanding that setting KEEPFENCED = YES in the DBM config parameters is the way to override the default behaviour and force the stored procedure to stay resident even when it is not used?
Yes, but only for fenced stored procedures. When a fenced stored procedure
is executed, the DB2 agent intiating the CALL statement fires up a new
process (called db2fmp on UNIX/Linux or db2dari on Windows) that is used to
run the stored procedure. (By running the SP in this new process, the
engine is spared from undesireable effects should the SP do something
wacky.)

Unfenced stored procedures are always executed within the calling agent's
process space, and does not "stay resident" after it has finished executing.
(See more below.)
Now, a word about the confusion in the manuals. I was researching this
question in the manuals and found a topic entitled "Specifying general
properties". It says that there is an option for 'Stay resident at exit' in the Create Procedure notebook in the Development Center. The problem is that I can't find any such option anywhere. I suspect that the manual is not in
sync with the code in the Development Center. I am experiencing this on a
V8.2.2 copy of DB2 at a client site.
From the online documents I read, this option is only valid for DB2 on
zSeries.
From the DB2 UDB Information Center:

Administering
- Mainframe and midrange servers
-- Administering DB2 UDB for z/OS and OS/390 subsystems [ first hint! ]
--- Administering DB2 objects
---- Applications Objects
----- Procedures
------- Specifying general properties
Am I just particularly dense today or am I right that there is no such
setting for stored procedures? If I am being dense and I can set this value, could someone tell me EXACTLY how to get to the panel that has this option?

I believe there is no setting in the Development Center to do this.
However, there is a way to do it using C code in a C-language stored
procedure. This procedure was doucmented in v7 but I can't find it in the
v8 docs, so it's likely unsupported.

Within a C-language stored procedure, the return code of your procedure can
indicate to DB2 whether the procedure should stay resident or whether it
should be unloaded.

// start of SP
SQL_API_RC stored_procedure(...)
{
sqlint32 rc;

// SP logic

if (sqlca.sqlcode >= 0) {
rc = SQLZ_HOLD_PROC;
} else {
rc = SQLZ_DISCONNECT_PROC;
}

return rc;
}
// end of SP
If the manual is wrong, what's the best way to notify the technical writers so that they can fix this?


Open a PMR. But not in this case.

--
Matt Emmerton
Nov 12 '05 #2

P: n/a
Rhino wrote:
I am trying to determine the behaviour of stored procedures in DB2 V8.2.x in
Windows/Unix/Linux and how I can control that behaviour. I assume SQL Procedures (Matt answered for external routines). SQL
Procedures in DB2 V8.2 do not use DLL anymore. SQL Procedures use p-code
which is run by the PVM (virtual machine)
First, am I right in understanding that the normal behaviour of a stored
procedure, fenced or unfenced, is to only go into memory when it is invoked
and to be swapped out of memory when it is not needed any more? An SQL Procedures (and teh packages of external routines) compete with
other packages and dynamic SQL for the PACKAGE HEAP. It is pinned only
while executing. When dealing with lots/big stored procedures the
package heap should be sized generously. It can make up to a magnitude
difference in performance.
Second, am I right in understanding that setting KEEPFENCED = YES in the DBM
config parameters is the way to override the default behaviour and force the
stored procedure to stay resident even when it is not used?

The executible of an external and fenced routine, unless the OS decides
to swap it out. It competes with any other library.

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #3

P: n/a
For fenced stored procedures (KEEPFENCED=YES) we have a library
management model that keeps all recently used libraries loaded in
memory, but dynamically determines when to unload infrequently used
libraries.

We have an LRU of the 5 most recently used libraries...these libraries
will stay loaded even if no stored procedure has been run in the db2fmp
for days.

To prevent the amount of os space consumed from growing uncontrollably,
we may unload any other library that has not been accessed for a
particular interval of time.

The 'stay loaded' feature you reference below about was actually only
ever an 'immediate load/unload' feature, implemented as the return code
from the stored procedure. It was only ever looked at for the now
defunct db2dari style stored procedures...even with this return code
handling, in v7 we only had the LRU functionality for library
management...because of this, even if you told db2 to keep your library
loaded, it would only stay loaded until it was no longer one of the 5
most recently invoked libraries.

Trusted stored procedures are always unloaded on the application or UOW
boundary, depending on whether you're running concentrator enabled or not.

Rhino wrote:
I am trying to determine the behaviour of stored procedures in DB2 V8.2.x in
Windows/Unix/Linux and how I can control that behaviour. Some documentation
in the manuals is confusing the issue somewhat.

First, am I right in understanding that the normal behaviour of a stored
procedure, fenced or unfenced, is to only go into memory when it is invoked
and to be swapped out of memory when it is not needed any more?

Second, am I right in understanding that setting KEEPFENCED = YES in the DBM
config parameters is the way to override the default behaviour and force the
stored procedure to stay resident even when it is not used?

Now, a word about the confusion in the manuals. I was researching this
question in the manuals and found a topic entitled "Specifying general
properties". It says that there is an option for 'Stay resident at exit' in
the Create Procedure notebook in the Development Center. The problem is that
I can't find any such option anywhere. I suspect that the manual is not in
sync with the code in the Development Center. I am experiencing this on a
V8.2.2 copy of DB2 at a client site.

Am I just particularly dense today or am I right that there is no such
setting for stored procedures? If I am being dense and I can set this value,
could someone tell me EXACTLY how to get to the panel that has this option?

If the manual is wrong, what's the best way to notify the technical writers
so that they can fix this?

Rhino

Nov 12 '05 #4

P: n/a
"Sean McKeough" <mc******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.net...
For fenced stored procedures (KEEPFENCED=YES) we have a library management
model that keeps all recently used libraries loaded in memory, but
dynamically determines when to unload infrequently used libraries.

We have an LRU of the 5 most recently used libraries...these libraries
will stay loaded even if no stored procedure has been run in the db2fmp
for days.

To prevent the amount of os space consumed from growing uncontrollably, we
may unload any other library that has not been accessed for a particular
interval of time.

The 'stay loaded' feature you reference below about was actually only ever
an 'immediate load/unload' feature, implemented as the return code from
the stored procedure. It was only ever looked at for the now defunct
db2dari style stored procedures...even with this return code handling, in
v7 we only had the LRU functionality for library management...because of
this, even if you told db2 to keep your library loaded, it would only stay
loaded until it was no longer one of the 5 most recently invoked
libraries.

Trusted stored procedures are always unloaded on the application or UOW
boundary, depending on whether you're running concentrator enabled or not.

Are you saying that SQL Stored Procedures are not in the package cache?
Nov 12 '05 #5

P: n/a

"Mark A" <no****@nowhere.com> wrote in message
news:cf********************@comcast.com...
"Sean McKeough" <mc******@nospam.ibm.com> wrote in message
news:42********@news3.prserv.net...
For fenced stored procedures (KEEPFENCED=YES) we have a library management model that keeps all recently used libraries loaded in memory, but
dynamically determines when to unload infrequently used libraries.

We have an LRU of the 5 most recently used libraries...these libraries
will stay loaded even if no stored procedure has been run in the db2fmp
for days.

To prevent the amount of os space consumed from growing uncontrollably, we may unload any other library that has not been accessed for a particular
interval of time.

The 'stay loaded' feature you reference below about was actually only ever an 'immediate load/unload' feature, implemented as the return code from
the stored procedure. It was only ever looked at for the now defunct
db2dari style stored procedures...even with this return code handling, in v7 we only had the LRU functionality for library management...because of
this, even if you told db2 to keep your library loaded, it would only stay loaded until it was no longer one of the 5 most recently invoked
libraries.

Trusted stored procedures are always unloaded on the application or UOW
boundary, depending on whether you're running concentrator enabled or not.

Are you saying that SQL Stored Procedures are not in the package cache?


SQL stored procs are in the package cache. What Sean is talking about are
non-SQL stored procs, which have a backing shared object which needs to be
loaded/unloaded by the OS, and DB2 only keeps the 5 most recently used
object loaded at one time.

--
Matt Emmerton
Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.