Question:
The restore command works fine, but while attempting the rolforward of the sql logs, it complains about database falling short on bufferpool,and then terminates the rollforward process. One close look at the db2diag.log file, I noticed that db2 tried to start the database with the hidden bufferpool. But, apparently, that hidden bufferpool was pretty small to rollforward the logs and bring it online.

I cannot reduce the bufferpool size as the database cannot be connected to.I cannot connect to the database as it is in rollforward pending state. I cannot rollforward the database, as it's not happy with the size of the *hidden* bufferpool and terminates.

Answer:

db2set DB2_OVERRIDE_BPF=50000

This will bring up all configured bufferpools using 50000 pages each. You
can choose a smaller/larger value that is suitable for your number of
bufferpools and available system memory. You can also configure each
bufferpool individually if you want

値: 正數(shù)のページ數(shù)
???? OR
?<entry>[;<entry>...] (<entry>=<バッファー?プール ID>,<ページ數(shù)> )

There is sitiuation that above solution does not work.

				When you try to create a bufferpool or alter a bufferpool to a
very large size and there is not enough memory in the system
, DB2 may occupies all pagespace and overrall performance of
the system become slow and may get hang at last because no
pagespace is available. Then after you connect the database
next time, DB2 will do crash recovery and still try to
allocate memory for this big bufferpool and occupy all
pagespace again. when you specify DB2_OVERRIDE_BPF parameter
to override bufferpool size, it doesn't take effect in this
situation. This is becasue DB2_OVERRIDE_BPF only applies for
bufferpools that already exist at startup, and not to
bufferpools that are created during crash recovery or roll
forward. We will fix this problem and check DB2_OVERRIDE_BPF
registry when creating bufferpools during crash recovery or
roll forward. This problem only occurs in a 64 bit instance.

		

Local fix

				You can use db2iupdt -w 32 <INSTNAME> to update the instance to
a 32 bit instance, then you can connect to the database
succefully. After that, use db2iupdt -w 64 <INSTNAME> to update
the instance to 64 bit again. Please take a backup at this
point, so we don't have to roll forward through bufferpool
creation that fails if we need restore and roll forward
database.

		

Problem summary

				Users Affected:
All users using 64 bit instance
Problem Description:
When you try to create a bufferpool or alter a bufferpool to a
very large size and there is not enough memory in the system
, DB2 may occupies all pagespace and overrall performance
of the system become slow and may get hang at last
because no pagespace is available. Then after you connect the
database at next time, DB2 will do crash recovery and still try
to allocate
memory for this big bufferpool and occupy all pagespace again.
In this situation, when you specify DB2_OVERRIDE_BPF parameter
to override bufferpool size, it doesn't take effect in this
situation. This
is becasue DB2_OVERRIDE_BPF only applies for bufferpools that
already exist at startup, and not to bufferpools that are
created during crash recovery or roll forward. We will fix
this problem and check
DB2_OVERRIDE_BPF registry when creating bufferpools during crash
recovery or roll forward. This problem only occurs in 64 bit
instance.
Problem Summary:
This problem is caused by a misoperation, when you create or alt
er a bufferpool, the size is too large to allocated from OS and
cause overrall performance of the system is very slow and seems
hang. Another problem is that DB2_OVERRIDE_BPF registry only app
lies to bufferpools that already exists, and not bufferpools wil
l be created in crash recovery or roll forward. So DB2 will try
to create this big bufferpool again when doing crash recovery or
 roll forward. We will fix this problem and check DB2_OVERRIDE_B
PF registry in our crash recovery and roll forward code.

		

Problem conclusion

Temporary fix

				You can use db2iupdt -w 32 <INSTNAME> to update the instance to
a 32 bit instance, then you can connect to the database
succefully. After that, use db2iupdt -w 64 <INSTNAME> to update
the instance to 64 bit again. Please take a backup at this
point, so we don't have to roll forward through bufferpool
creation that fails if we need restore and roll
forward database.Please also notice that be careful when creati
ng bufferpool, don't specify a too large value.