Block Size And DB size

[Kishor Chari]

Dear All,

I got a feed back from MFG/PRO Support team about my clients request to change block size to 8k (currently on 1K) . The reply was the improvement in performance would be negligible and DB size will also increase drastically slowing down online probkup.

PROGRESS 91E/RH 3

Pl let me know if the above is true?

TIA.

 

[RealHeavyDude]

To be honest - I can't believe it! Somebody that's selling Progress based applications to a customer is giving their customer such bull****?

Having a database blocksize with 1K is possibly the worst thing you can have. It's subject to debate whether 4K or 8K is the better choice for the database blocksize - but personally I would choose 8K.

From my point of view there is no argument to not change the database blocksize to 8K other than:

• You don't understand what the datablocksize is and are afraid your customers are doing something you are afraid of.
• You don't want the customer to improve the performance because you want to sell him something else.
• You have a malicious intent.

RealHeavyDude.

 

[rstanciu]

in my opinon the database block size have to be the same as your file-system.
Check stat -f /
on linux RH ext3 you will find the 4k (4096).

And create the database as:
$DLC/bin/prostrct create [database] [database].st -blocksize 4096
$DLC/bin/procopy $DLC/empty4 [database] -blocksize 4096
$DLC/bin/proutil [database] -C enablelargefiles
and BI to 8k
$DLC/bin/proutil [database] -C truncate BI -bi 8192 -biblocksize 8

 

[TomBascom]

The "support" person who answered your question doesn't know what they are talking about.

While you are at it you should dump the suggested mfg/pro storage area configuration. It's utter crap too. (It is a "functional" arrangement -- i.e. "orders" & "history" and so forth. For performance you should arrange tables and indexes based on their technical attributes like average row size, frequency of access and table size and such.)

In theory matching db block size to fileystem block size is ideal. Having the db block smaller is definitely bad. If, for instance, the db block is 1k and the fs is 4k and you want to write 4k of consecutive data you have to make 4 write() calls. If both blocks are 4k you only make 1.

In theory if the db block is larger than the fs block you could, potentially, have a 'torn page' if the OS crashes when the first part of the operation has completed but the 2nd has not. In practice this is extremely rare (I've never seen it) and OE10.1C and higher have checksums built in to detect it.

Larger block sizes are generally better for IO performance. It takes fewer IO ops to get the same amount of work done. So 8k is generally better than 4k.

 

[Kishor Chari]

Many Thanks.

Post your advice to get professional help on Block Size alteration this is what I got from Tech Support.

I will feed the clients with your comments.

I am learning so much 15 yrs of MFG/PRO (PROGRESS) always installed by QAD install guide..frog in the well. Appreciated.

 

[RealHeavyDude]

You're welcome - and pls excuse the strong words I've used but I couldn't help it.

The other day I met this guy on a plane. Turns out that he leads the customer support team of a bigger Progress partner. As we share our experiences he asks me: Hey Dude, it appears to me that you have some experience with the Progress database. Last week I got a call from one of our customers who asked me whether it is possible to backup the Progress database. Turns out this is the first time he looked into the issue and stumbled over "something strange" like the after image - some black box that magically should be the answer for the customer of his. Next thing he asked me whether I think this thing really works now that they use OpenEdge because he heard from one of his staff members that whole crap was not working in Progress V9. As I explained to him that I use the after image as an essential part of the disaster recovery strategy from Progress V6 on (beginning of the 1990s) his jaw began to drop and drop and drop ...

Too keep a long story short - you may imagine how perplexed I was. I couldn't believe that they give their customers nothing but bad advice when it comes to database administration. No wonder their customer base showed reluctance in following their advice.

Regards, RealHeavyDude.

 

[howe02]

Hi Kishor,

I am a Support Manager for QAD and I would love to follow up on what happened and take corrective action. Woul;d you be willing to reach out to me with the call number and the name of the rep please. My email is klw@qad.com

Sorry for any confusion.

Regards,
Ken

 

[howe02]

Thanks Kishor for getting back to me. I am glad the erroneous information came from an ex-Service Partner and not from QAD or an authorized partner. If you ever receieve information that you question, feel free to reach out to me directly. Regards, Ken Weeks klw@qad.com