Bob Murdoch wrote:

>
> Yes. I tried running the Diagnose option of IBSurgeon last night.
> After 3.5 hours, I had to cancel the operation so as not to interfere
> with the backup/restore scripts that run at midnight.

OK. That's too bad. It would be nice to know which index was bad.

> I think gfix is faster..

Yes, but it sometimes gives errors that I can't explain... It often
reports page and record level errors on working databases. IBSurgeon
uses a different algorithm and tends to report only serious problems.

>
> It seems that yesterdays problem related to a single table, which has
> three indexes. As I said, I don't know which index caused the
> problem, as I rebuilt all three. This particular table is the one
> that I mentioned in yesterdays email, which had six massive deletes
> followed by appending, each in six different transactions.
>
> The strange thing about this is that after we finish loading, we run a
> procedure which stores a summary of the information in another table
> (as part of the same transaction). Each row of the newly inserted
> data is visited during this summary process, so I would assume that
> the data was originally stored without problem (the error did not
> surface until the over night backup job).

My thought at the moment is that one of your indexes split at an
upper level and something went wrong. Any index page split requires
that Firebird allocate a new page by changing a Page Information Page
and add it to the index. I'm thinking about upper level splits
because this isn't happening constantly.

Somehow, the fact that the page was allocated got lost, and another
process reallocated the same pages as a data page.

There's a precedence relationship between the PIP and the allocated
page and between the allocated page and the pages that point to it
(i.e. its sibling to the right, sibling to the left, and the next
level up) so that the fact that the page is allocated will go into
the database on disk first, followed by the page itself, followed
by the pages that point to it.

Somehow, the fact that the page was allocated got lost, and another
process reallocated the same page as a data page. At least that's
how it feels from here.

>
>
> One issue - I do not seem to be able to get the index statistics of
> any database on this server. I ran "gstat -index [dbname] >
> gstat.txt", and all I get is the header and the irritating
> "unavailable database". When I ran this, there were no connections to
> the db, and even the FB service was shut down. Any clue what the
> problem may be?

Gstat should run fine with other processes active and to get the
index stats, it has to go through the server...

Regards,


Ann