Subject Re: [firebird-support] Re: FB2.1 frequently Index corruption in DB
Author Helen Borrie
At 11:35 AM 19/07/2008, you wrote:
>Note always i have problem with one table (table 129 !)
>Database header page information:
> Flags 0
> Checksum 12345
> Generation 16019
> Page size 4096
> ODS version 11.1
> Oldest transaction 3858
> Oldest active 15172
> Oldest snapshot 15172
> Next transaction 15173
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 839
> Implementation ID 16
> Shadow count 0


> Page buffers 8192

This is waaaaaaay too high for Classic. It is very likely that your corruptions are happening, at least sometimes, due to out-of-memory conditions, which v.2.1 Classic does not handle elegantly.

Reduce this cache size to something around 256 pages, given you have 6GB of RAM and only 10 users. But exercise restraint and also check the cache size in the other database. Currently, *each connection to this database* is taking 32 Mb as its starting cache size. 1 MB each is more than ample. 500KB would also be ample (a 128-page cache).

Since this enormous cache looks as though it is a neglected aspect of a change from Superserver to Classic, one wonders whether other dangers are being neglected in your environment. Two that come to mind:

1) Have you isolated your database file from SystemRestore and any other external file-locking utilities such as system backups and anti-virus?

2) Are you running your Classic server under the Guardian? DON'T!! It is likely to be leaving ghost connections around that will continue to consume resources (32 MB each in their dead cache buffers plus the 1.5 MB or so that each has to well as lock resources....)