Subject Re: Firebird 2.0.1: Database corrupt under high load CPU load
Author mark_gebauer
--- In, "Ann W. Harrison"
<aharrison@...> wrote:
> 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?

On backup:
gbak:153 records written
gbak: writing index ITPROJECTS_GUID
gbak: writing index ITPROJECTS_NAME
gbak: writing data for table TPROJECTS
gbak:3 records written
gbak: writing index ITPREPLOG_1
gbak: writing data for table TPREPLOG
gbak:14830 records written
database file appears corrupt ()
wrong page type
page 935 is of wrong type (expected 7, found 5)
gds_$receive failed

The backup stops at that point => no backup file.

My index definition for the corrupted index was:


and the field definition:


Is there any known problem of this combination (VARCHAR and
UNIQUE) under high load? Now my first attempt to solve this
problem is to remove the "UNIQUE" (the GUID is unique anyway).