mark_gebauer wrote:

>
> Regularly the stressed DB is corrupt and I am getting a lot of the
> following or similar log messages:
>
> "database file appears corrupt ()
> wrong page type
> page 4970 is of wrong type (expected 7, found 5)"
>
> "database file appears corrupt ()
> wrong page type
> page 4970 is of wrong type (expected 7, found 3)"

That is an indication of a doubly allocated page or a page that
had been part of an index, was compressed out of the index, but
not successfully removed from its parent page.

As it happens, page type 7 is an index, page type 5 is a
data page, and page type 3 is a transaction page. The index
is corrupt, but not the data or transaction inventory. That's
the good news.

>
> "Page 6458 is use but marked free"

This could also be the problem of a parent (upper level) page
pointing to a lower level page that has been compressed out of
the index. Or it could be another bug. It sounds like the
parent because the removal would mark the page as free, but
verification code would report it also in use because it's
referenced from the parent page.

>
> "Index 2 is corrupt on page 782 level 1. File:
> \fb2\dev\fb2R2_0_1\firebird2\src\jrd\validation.cpp, line: 1656
> in table TMSG (131)"
>
> "Index 2 has orphan child page at page 782 in table TMSG (131)"

Internally, Firebird tracks indexes, tables, and fields by an
number. You can translate to the index name by looking in the
rdb$index_name and rdb$index_id fields where the rdb$relation_name
is "TMSG". Both of these errors could be caused by an pointer
from the parent to a released page. Reading across the index
level would not show the page, but reading down from the parent
would indicate that the page should be part of the index.

>
> Usually it is not possible to repair or backup/restore the DB.

Repair I can understand. This is not an anticipated bug, so the
repair code doesn't handle it. All of the errors you reported
are corruptions in indexes. Gbak doesn't read user indexes, so
it should be able to back up the database and a restore should
succeed. What errors did you get on backup/restore?

What I would do is take the database off-line, make a copy of
it, set the original to be read-only (gfix -mode read_only) the
do a backup with the -g switch. That should restore correctly.

I don't have a generic answer that will let you avoid this error.
A bug like the one I described is fixed in 2.1 (I think).


Regards,


Ann