How to combine Containers with different BlkSize

Hello, sorry for two questions in one post.

We have all additional containers created as an emergency fixes or as an automatic expansion.

Container  BlkSize      Size 
ASSO1        4,096       400.00
ASSO2        2,048       100.39
ASSO3        4,096       131.47
ASSO4        2,048           0.40
ASSO5        4,096           3.91

DATA1        8,192     2,050.00
DATA2        8,192     2,000.00
DATA3      32,768     1,031.25

Is there an easier way to combine containers with different blksize then recreating each effected file
from FDT individually?

Annoyance is that many FDT does not include latest FDT changes.
The only other way coming to mind is (Mass delete)/(Deallocate space)/Remove Containers)/(Mass add)(Allocate more space), but it doesn’t looks better.

What are general performance consideration regarding number and BlkSize of ASSO and DATA containers residing on the same hard drive?
Majority of descriptors are less than 10 bytes and FIND usually is a FIND(1).

Thank you,

  1. Export the files except the system files with ADAORD EXPORT.
  2. Recreate the database with the containers you want to have. However, you must consider the following: The DATA block sizes must not be reduced. This means, because currently your DATA3 container has a block size of 32 KB, your new DATA container must also have the block size 32 KB. For ASSO, Adabas distinguishes between small ASSO blocks (< 16 KB) and large ASSO blocks (>= 16 KB). If the index uses small index blocks, they are imported again in small ASSO blocks, and large index blocks are imported again in large index blocks. In your case, the database only uses small ASSO blocks. => You must define your new DB also with small ASSO blocks. I don’t think that the performance differs very much between the different block sizes. Most of your index blocks currently have a block size of 4 KB; so I recommend to use again 4 KB as block size.

If you still have explicit hard drives and not a storage system with RAID, where this no longer matters, you should take care that

  • the database containers ASSO,DATA and WORK are on one or more hard drive and
  • the backups and PLOGs are on one or more different hard drives.
    Otherwise it max happen that you can no longer regenerate your database after a disk failure.

Apart from that you should only try to share the containers on the disks that the number of I/Os on the disks are similar. However, this should not have very much impact on the performance, because most logical I/Os do not result in a physical I/O because of the buffer pool. More important is that the buffer pool is large enough.

Wolfgang, thank you very much for detail response.

Could you please help with two last questions I was not able to find answers in the documentation:

  1. Is it possible using some utility identify average and max. size of records in the particular file?
  2. How in the utilities outputs identify RABN to calculate specific start RABN for AC, DS, NI, UI for ADAFDU?

Thank you,

Hi Boris,

  1. Unfortunately we have no utility that tells you the maximum and average size of the records.
  2. You can perform ADAREP LAYOUT to see which RABNs are still free.


Wolfgang, Thank you!

I see that parameters RABN and blocksize have a similar effect on files placement when containers have a different Blcksize. Average size of the records I calculated as a ratio between occupied space and number of records.
Length of the records with an extreme length still a mystery. As usual extreme cases are records with PE and MU fields, especially processed by applications without reasonable constrains. But this topic clearly out of scope for ADABAS forum. Any way ADABAS impressively well handling this problematic data and even has now referential integrity which I’m going to try.

Thanks again,

Hi Boris,

In particular when your files have MU/PE with an unknown number of values, I recommend to use the maximum DATA blocksize = 32 KB. If you then get a record overflow, it is not possible to store the record in Adabas on Open Systems. Then you have to reorganize your data. For example, you can consider storing the data in LOB values (field option LB) instead of MU/PE. For LOB values, there is no restriction in size.