mark_gebauer wrote:

>
> 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
> ...

Did you use the -g switch on gbak? Although gbak
doesn't use indexes to find data, it will touch
indexes when doing garbage collection.

>
> My index definition for the corrupted index was:
>
> #CREATE UNIQUE INDEX "IMSGGUID" ON "TMSG"("FGUID");
>

Dropping and recreating that index should also make the
database usable.

>
> 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).

No... The problem is that a page has been lost from the index
which should not be affected by uniqueness - just by the frequency
of use. In particular, delete and update activity.

Good luck,


Ann