I have had a significant upgrade in RAM on our server and may have up
to a GIG of memory that I can reallocate to my DB2 bufferpools.

My problem is, with such a significant increase I am nervous that a
calculation could be off and my increase is too much.

If I overallocate my bufferpools, DB2 will not start - correct?

So if I overallocate, db2 won't start, how can I get in to reallocate
so all goes bac to normal?

It's almost as if I mess up, there is no way to back out.

Am I missing something here? What would you do?

M. Krafick wrote:

If you try to allocate too much memory to your bufferpools, then
DB2 will print the error and start with one very small bufferpool.
This will allow you to fix your other bufferpools.

Good luck,






-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

If you overallocate buff pools, DB2 will start with tiny buffer pools
like 1000 pages. You can then readjust the buffer pools to new sizes
you want. A message about starting with tiny bufferpools in the
diaglog is the clue you look for.

Powell.


jinx025 (AT) yahoo (DOT) com (M. Krafick) wrote in message news:<382ff89d.0308271318.39745f79 (AT) posting (DOT) google.com>...

Thank you for the help guys! I really do appreciate it.

Having just overallocated memory by accident, I can tell you that it
is recoverable to an extent. While restoring a database from a
production box to a much more inferior development box, I had
forgotten to alter the bufferpool before starting up the database. DB2
tried really hard to come up and grabbed a ton of virtual memory
(sending the machine into overload as well), and finally gave up and
died. Since the memory is allocated on an ACTIVATE statement or the
first connect to the database, I was able to update the default
bufferpool size on the database configuration parameter (UPDATE DB CFG
FOR mydb USING BUFFPAGE nnnn) before starting it up the next time. DB2
went through crash recovery and performed normally after that.

If you're using more than one bufferpool and their size is not the
default, then you may be out of luck, as the ALTER BUFFERPOOL requires
a connection. You could always start with one bufferpool and assign it
a size of -1 so it will use the default size (BUFFPAGE), then
systematically increase the size of the BUFFPAGE parameter until you
find the right setting. This way you can alter the size before you
make the first connection.

Hope this helps,
Evan


jinx025 (AT) yahoo (DOT) com (M. Krafick) wrote in message news:<382ff89d.0308271318.39745f79 (AT) posting (DOT) google.com>...

jinx025 (AT) yahoo (DOT) com (M. Krafick) wrote in message news:<382ff89d.0308271318.39745f79 (AT) posting (DOT) google.com>...
We had a situation once where we were given a fair chunk of memory, so
we increased the size of many bufferpools to start using it. We got
in over our head and the database could not be brought up.

We contacted IBM support for assistance. We were advised to bring up
the database by setting:

db2set DB2_OVERRIDE_BPF=1000

Stop and start the instance, bring up the database. Make the buffer
pool changes needed (to decrease the size in our case). Reset the
parameter:

db2set DB2_OVERRIDE_BPF=

Stop and start the instance again. Things should be better.

The other posts that mention it does this automatically may be correct
with more current versions, but this is what we were forced to do in
early Vs. 7.1.

Kristi Close
American Electric Power