How to load data definitions and data into a void multivolume database?

[alexban]

Hi,
I'm a junior progress admin. Please excuse me if this a dumb question...
I'm using progress 8.3c. When I try to use data administaration tool or data dictionary to conect to a newly created database it pops an error message saying that tha database is "void multi-volume database". The reason that I want this is beacause the newly created database has a block size of 8 k and the production database has 4k (the one for witch I have the dumps). I'm trying to improve performance and I've read this might help.
The OS on the progress database is running is Windows Server 2003.
Thank you and excuse my english
Alexban

 

[Casper]

procopy $DLC/empty8 newly_created_void_database_name.

And then load the data.

BTW: Blocksize of 4K is good for a windows server, so you dont have to change that to 8k.....

Casper.

 

[alexban]

thanks. I'll stick to 4k then and i'll make a new post to find the bottleneck in my database.

 

[BruceD Lindberg]

I recently did that on a Unix system and used the 8k blocksize.
It had a big impact on performance.

The void database can't connect to the progress session because the virtual system tables are not loaded. That's what is loaded when the empty8 is copied over, then you can connect and use the Editor/DBA Session to load your specific *.df and *.d's .

I ran into an issue where the area definitions of the emtpy8 db has to be the same as your emtpy_db, or that doesn't work either.

 

[alexban]

maybe I'll try it to, just out of curiosity to see how it impact's performance. I'll post the result's here.
Thanks for the reply,
Alexban

 

[Casper]

OS Blocksize of windows machine is 4K, OS blocksize on Unix machine is 8K. That's why 8K database blocksize on a Unix machine is better then using 4K.

But you're right in never hurts to test for yourself. But I don't sduspect too much a difference.
With 8K blocks on windows the OS has to fill 2 blocks to get the database block in memory...

Do you post your results?

Regards,

Casper.

 

[TomBascom]

8k database blocks are a big benefit in version 8 because it is the only way to change rows per block. In version 8 8k blocks use 64 rows per block, all other database block sizes use 32. Thus each read of an 8k block gets you twice as many records.

The down side is that the database will probably grow -- it might double in size. But the performance benefit is usually very significant and disk space is cheap.

Version 9 and above allow you to specify rows per block for each area. In those cases it is best to match the database block size to the os block size (4k for windows and linux) and to set rows per block as appropriate. 128 or 64 is a generally good blind guess, 256 used to be my default but PSC has done a lot of work on the create and toss limits so that that is no longer a good idea in most cases.

 

[Casper]

Thanks Tom,

I never read the version 8 part of the question.... Oops!

Regards,

Casper