Hi,

As some of our tables are growing fast (such as tfgld410, tdsst, etc.) we think that the table-size is becoming larger than 2Gb.

We work with Bisam on AIX 5L and have no plans for changing the database-software. (Not if it is not really necessary). We have made a ejfs-filesystem which supports filesizes of 1000Gb.

Can bisam cope with table-sizes (and thus file-sizes) which are larger than 2Gb? And if yes, what is the technical limit for bisam-table-sizes?

Thanks for your thinking,
Jelle

I have seen baan Vc on HP-UX with bisam using files larger than 2Gb (about 5 years ago). It depends on what kind of variable they use in the source (long on 32 bit architecture limits to 2Gb). However I guess if they solved it on HP-UX it probably will work on AIX as well.

On the other hand you can write a small 4GL program that shows you if it will work.

Regards,
Han

Hi Han,

I'm rather new at the 4GL-programmes. Can you send me an example of a 4GL-program so that I can test it as well?

Thanks,
Marco van der Heide

To be honest, I think you are working on the wrong angle.

If you insist to work with tbase, then you should not try to have it working with larger files, you should try instead to reduce the files, for example by archiving data.

At some stage your bisam file will get corrupted due to a crashed server or some other reason and bisam will repair the file, but unfortunately this will take something like 10 hours. In that case you will split you brain, that you did neither archive nor changed to a database, which deserves the name.

Regards

Markus

Marco,

you probably can achieve the same by just updating a table with bdbpost.

E.g. dump a table so you know how the ascii file looks. Add data in the ascii file and import it into the table so that the size will be larger than 2Gb.

Regards,
Han

Update:
Markus, I agree that a real RDBMS probably is better. However if you have a stable system (preferable HP? ;-) ) and you are willing to run the risk of corrupted indexes you can choose to use bisam. You know as well that the performance actually is much better compared to e.g. Oracle.
Furthermore it's not only the risk of corrupted indexes, it's also a matter of inconsistent data which can cause nasty problems.

Naturally bisam is much faster than oracle. No doubt about it.

On the other hand, bisam is seriously only good up to a relative small number of users, otherwise you end up with all sorts of locking issues on top.

But this is all just theory anyway. Jelle has to live with whatever he has at the moment. So one more idea might be good for him:

If I remember correctly, then tbase just marks records as deleted, but does not really delete them. So actually dumping the table in question, recreating it and loading it again, might result in a much smaller file. Could be worth a try, I guess.

Regards

Markus