will.honor wrote:

> This morning I have encountered the same problem on a test database
> on the lowest spec server. This server is very lightly used with no
> inserts and only a few hundred reads.
>
> KSSHEPRFX Mon Oct 23 10:23:02 2006
> Database: F:\CALLSYS\SHEFFIELD\LIVE\DB\CALLSYSSHEFLIVE.FDB
> Index 19 is corrupt on page 953471 in table ACTIONS (162)

Yes this is probably a bug, and it will be hard to find since it's
rare and hard to reproduce. If I had a copy of the database with
the broken index, I might be able to figure out something...

However, you don't need to do a full backup to fix this problem.
The error tells you that the bad index is on the table ACTIONS, and
it's index 19. If you look in RDB$INDICES for the indexes on the
ACTIONS table, you'll find both index names and index ids. Deactivate
and reactivate index 19 and the problem will be fixed.

>
> KSSHEPRFX Mon Oct 23 10:23:09 2006
> Database: F:\CALLSYS\SHEFFIELD\LIVE\DB\CALLSYSSHEFLIVE.FDB
> Relation has 1691 orphan backversions (1 in use) in table ACTIONS (162)

That's an error, but not a serious error. If the server is shutdown
hard (e.g. crashes) there may be some incomplete garbage collection.
When garbage collecting, Firebird first removes the pointer to the
unneeded version from the next version, then removes the old version
itself. Pointers to nothing are much worse that a few bytes of lost
space.

>
> KSSHEPRFX Mon Oct 23 10:27:26 2006
> Database: F:\CALLSYS\SHEFFIELD\LIVE\DB\CALLSYSSHEFLIVE.FDB
> Page 881515 is an orphan
>

Similarly, when the database shuts down hard, it may leave orphaned
pages. An orphan page is one that is neither in the list of free pages
nor in use. If the crash occurs after the page number was removed from
the free page list but before it was actually assigned to a table or
index, it will be reported as an orphan.


Regards,


Ann