Hi Ann,

the index problem that you're describing here is this specific to FB
2.0.1 or is it also present in FB1.5.

The reason I'm asking is because I've been experiencing some very
strange behaviour on our FB 2.0.1 servers. Occaisonally when starting
up the DB I've needed to do a "SELECT COUNT(*) FROM" on each table in
the DB, I will take a LONG time (15 minutes for 150K records) to
process one or two tables and thereafter everything seems fine. It
does not seem to be a garbage collection problem since the first
thing I try each time it happens is to do a gfix sweep.

Last night I did a backup and restore and today when the database
started up everything was crawling. Validation returned no errors,
backup and restore ran fine without any improvement. I then read this
message and decided to go back and do a select from RDB$INDEXES to
see which indices were active (incl FK & PK). It turned out that most
of them were inactive re-activating them seems to have solved the
problem.

So I am assuming that there were problems with the indices which were
not reported in the restore were not restored properly.

Thanks
Thomas

--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> mark_gebauer wrote:
>
> >
> > Okay, the DB was corrupt today once again (same index as always).

I

> > have removed the index now and I am waiting if it crashes again.

The

> > table is used to send messages (~20 per second) between

applications,

> > and after receiving they will be deleted - doesn't seem to be a

good

> > idea.
>
> Not a bad idea in general, but a bad idea in this particular case
> because of a bug in the index page release code algorithm that can
> leave a dangling pointer.
>
> > It's interesting that it's always the same index that get's
> > corrupt. So the solution could be to mark received messages

instead

> > and delete them from time to time?
> >
> That's probably as safer algorithm under the circumstances.
>
>
> Regards,
>
>
> Ann
>