Different NUMBLOCKPAGES across Partitions (DPF)?

[jcgeorge]

I have a Windows DPF (v8.2.2) environment.
2 Nodes
5 Partitions
Server1 - Cat (0) Data (1) Data (2)
Server2 - Data (3) Data (4)

I want to use block-based IO, but I do not want the same size block
area of the bufferpool in each partition, I want a smaller value in the
catalog partition - because the bufferpool size is much smaller.

My (uniform) page size is 16k, my data partitions have a size of 10,000
pages, numblockpages=5,000 and blocksize=4

Every time I connect/activate I get the error that my numblockpages
exceeds the maximum size.

I am trying to execute this:
alter bufferpool pm_16k_bp dbpartitionnum 0 numblockpages 1000
or
alter bufferpool pm_16k_bp dbpartitionnum 0 size 2000 numblockpages
1000 blocksize 4
or
?

It returns:
SQL0104N An unexpected token "numblockpages" was found following "_bp
dbpartitionnum 0".
I cannot figure out the syntax for this.

Please forward an example if you can.

Thanks in advance.
John

[Knut Stolze]

jc******@yahoo.com wrote:

I have a Windows DPF (v8.2.2) environment.
2 Nodes
5 Partitions
Server1 - Cat (0) Data (1) Data (2)
Server2 - Data (3) Data (4)

I want to use block-based IO, but I do not want the same size block
area of the bufferpool in each partition, I want a smaller value in the
catalog partition - because the bufferpool size is much smaller.

My (uniform) page size is 16k, my data partitions have a size of 10,000
pages, numblockpages=5,000 and blocksize=4

Every time I connect/activate I get the error that my numblockpages
exceeds the maximum size.

I am trying to execute this:
alter bufferpool pm_16k_bp dbpartitionnum 0 numblockpages 1000
or
alter bufferpool pm_16k_bp dbpartitionnum 0 size 2000 numblockpages
1000 blocksize 4
or
?

It returns:
SQL0104N An unexpected token "numblockpages" was found following "_bp
dbpartitionnum 0".

You can either specify "DBPARTITIONNUM ... SIZE ..." or "NUMBLOCKPAGES ..."
but not both together. Have a look at the syntax diagram:
http://publib.boulder.ibm.com/infoce...n/r0000885.htm
(the description how to read them is here:
http://publib.boulder.ibm.com/infoce...n/r0006726.htm)

You can define a buffer pool that only resides on certain partitions.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

[jcgeorge]

Knut,

Thanks for the reply. I was trying to get away with only using one
bufferpool - while dedicating as much memory to my data partitions - I
did not want the catalog partition to get the memory that it will never
consume.

I thought of just creating a single partition bufferpool in Partion 0,
but that causes a problem for tempspace. Temprory tablespaces belong
to IBMTEMPGROUP which exists across all partitions. So, I still need a
bufferpool (for tempspace) that will span all partitions.

It appears that my best option would be to keep the single BP, minimize
the size on Partition 0, and minimize the size of the NUMBLOCKPAGES
area in all Partitions.

Thanks..John

[Ian]

jc******@yahoo.com wrote:

Knut,

Thanks for the reply. I was trying to get away with only using one
bufferpool - while dedicating as much memory to my data partitions - I
did not want the catalog partition to get the memory that it will never
consume.

I thought of just creating a single partition bufferpool in Partion 0,
but that causes a problem for tempspace. Temprory tablespaces belong
to IBMTEMPGROUP which exists across all partitions. So, I still need a
bufferpool (for tempspace) that will span all partitions.

It appears that my best option would be to keep the single BP, minimize
the size on Partition 0, and minimize the size of the NUMBLOCKPAGES
area in all Partitions.

Thanks..John

John,

It is a lot easier to manage if you create separate bufferpools --
assuming you have a nodegroup that encompasses your 4 data partitions,
create the bufferpool for the nodegroup that needs it.

The ability to change bufferpool sizes per partition is convenient
in situations where it's necessary (i.e. different servers have
differing amounts of real memory), but it makes managing things
more complicated in the future.