Subject Re: FB2.1 frequently Index corruption in DB
Author mnavahan
Hi helen

a)not always 10 user some time group up to 45 user online this is
avrage per hour

what to do ?


B)how detect "Are you running your Classic server under the Guardian?"
and how disable it if run ?




--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> 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
>
> Aaaargh!!!!!
>
> > 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 exist....as well as lock resources....)
>
> ./heLen
>