2011/5/17 PenWin <penwin@...>:

>> What I meant is, that basically a commit is better for transaction
>> statistics, so what the engine tries with a rollback is to undo stuff
>> and then calls commit. The engine isn't able to do that e.g. when
>> working on a larger number of records, e.g. by deleteing records and
>> then calling rollback.
>
> That might be exactly what happened, actually: There is a part of my
> program which involves deletes AND at the same time can cause the server
> to fail due to insufficient memory (on a 32bit system).
>

OK, based on what you've been saying, my guess is that you need to
backup the database (without restoring) more regularly or run sweep
at times of low demand. A full gstat -a -r will probably show that you've
got lots of old record versions left by the failed deletes and your active
transactions are spending their time cleaning up. Either a backup
or a sweep will do the clean up.

Firebird indexes do not go out of balance - if there's slowness, the likely
culprit is old record versions. They bloat indexes, they bloat pages, and
client transactions have to spend time removing them. The backup/restore
cycle gets rid of old versions - that's why it worked when disabling and
re-enabling the indexes didn't.

Good luck,

Ann