RPB for 8K

[casorohi]

Hi all need your expert advice on RPB. We have OE 10.1A DB with 4K block on HPUX and we are planning to do dump and load soon for type-II conversion. In the same time we are also planning to change to DB block to 8K
In this case how we calculate the RPB for 8K, where we have mean value of 4K ?
Thanks

 

[Rob Fitzpatrick]

When you say "we have mean value of 4K", I assume you mean "my mean values were taken from a source database with 4K blocks", as opposed to "my table's mean record size is 4K".

The mean value from a tabanalys or dbanalys report is the average record size for the table. It is independent of the database block size. You can use those values to plan the RPBs you will use for the storage areas in your target 8K database.

I take the mean record size in bytes, add 20, divide that sum into the database block size (8192 in this case), and then select the next higher integral power of two as the area RPB.

For example, if your DB block size is 8192 and your table's mean record size is 100, then:
8192 / (100 + 20) = 68.3; next highest power of 2 is 128. One caveat: even if the record size is very small, I don't use an RPB of 256.

 

[casorohi]

Thanks Rob
So waht I under stand for eg: at 4K block size DB with mean value = 185

Now the calculation for 8K block will be:
8192 / (100 + 185) = 28.7 ; next power of 2 is aprox 56 and; for this RBP = 64

is this correct ??

Thanks

 

[Rob Fitzpatrick]

No. In the example I gave, the 100 was the table's mean record size and the 20 is a constant, a value added for "padding" (record overhead).

So if your table's mean record size is 185, do the following: add 20 to get 205; in an 8K database, 8192 / 205 = 40.0, rounded up to the nearest power of 2 to get the table's ideal RPB of 64.

 

[RealHeavyDude]

You can set the block size on the database level and the records per block setting per storage area. The mean record length is independent of both - it's a value how many bytes on average are needed to store the records no matter what the block size and records per block setting is.

Setting the block size of the database to 8K is a good thing - only you should make sure that the block size of the file system on which the database files reside match this setting. That is very important. If the block size of the database is smaller than the block size of the file system you will seriously hurt performance. If the block size of the database is larger than the block size of the file system you won't hurt performance but you might introduce corruption when the database writes one block where the file system has to write more than one block and something bad just happens in between. In never OpenEdge 10 version the database will detect it but there's nothing that it can do against it ...

The optimal record per block setting is dependent on the mean record length and the block size as Rob already mentioned. You divide the block size of the database ( in your case 8K ) by the mean record length plus a factor ( in the example 100 + 20 bytes ) and then take the next power of 2 that fits best.

As a side note: Today the maximum block size for the database is 8K, but you can set the block size of the before and after image larger - to 16K. Which is what I recommend. You can do that with the proutil truncate bi and rfutil aimage truncate respectively.

Heavy Regards, RealHeavyDude.

 

[casorohi]

Thanks a lot for help...
another dount how to check the OS block size ??
Thanks
caso

 

[TomBascom]

I really wouldn't worry so much about the OS block size.

Most modern filesystems are journalled and do not have a "block size" per se. The more significant factor is that IO is performed by the virtual memory system via the paging mechanism. Thus the page-size of the memory manager is what really counts. Mostly that is 4k.

Yes, there is a slight chance that under some unlikely circumstances you might get a "torn page" as a result of using 8k db blocks on a system that does writes in 4k units. As RHD says, that is something the db will detect (but cannot prevent). The performance benefits of larger blocks are, IMHO, well worth the tiny risk.

In any event -- if you care about performance use a 4k or an 8k db block. Nothing smaller.