Subject | Re: [firebird-support] Re: Firebird CS Database Corruption |
---|---|
Author | Ann W. Harrison |
Post date | 2005-06-08T22:40:27Z |
stevemilner_2000 wrote:
index item. That's not supposed to happen, but the database is pretty
good about dealing with index entries that don't have corresponding
records - slows everything down, of course, but isn't a sign of serious
corruption. The situation can arise if the database server is shutdown
hard - crashed, or unplugged.
index on the Payment table.
that the missing entries correspond to record versions that have been
partially garbage collected...
in process, it can leave back versions. Careful write requires that the
pointer to the back version be cleared before the back version can be
removed. If the server crashes between those two writes, the back
version becomes an orphan.
from the free list (actually, the state of its bit on the page inventory
page must be changed) before it can be assigned to whatever function
it's going to perform.
Ann
>I think that one is a partially created or partially garbage collected
> Examples (from the firebird log) of some of the errors when gfix was
> running:
>
> host.domain.net Sat Jun 4 17:48:33 2005
> Database: /var/db/live/storedata.gdb
> Index 4 is corrupt on page 682726 in table ITEM_HISTORY (164)
index item. That's not supposed to happen, but the database is pretty
good about dealing with index entries that don't have corresponding
records - slows everything down, of course, but isn't a sign of serious
corruption. The situation can arise if the database server is shutdown
hard - crashed, or unplugged.
>Same think different index. The "10" indicates that it's the tenth
> host.domain.net Sat Jun 4 17:50:15 2005
> Database: /var/db/live/storedata.gdb
> Index 10 is corrupt on page 523097 in table PAYMENT (184)
index on the Payment table.
>That is more troubling. I'd rebuild that index, though it is possible
> host.domain.net Sat Jun 4 17:50:16 2005
> Database: /var/db/live/storedata.gdb
> Index 10 is corrupt (missing entries) in table PAYMENT (184)
that the missing entries correspond to record versions that have been
partially garbage collected...
>Not a problem. If the server shuts down hard while garbage collection is
> host.domain.net Sat Jun 4 17:50:19 2005
> Database: /var/db/live/storedata.gdb
> Relation has 61 orphan backversions (0 in use) in table
> PAYMENT (184)
in process, it can leave back versions. Careful write requires that the
pointer to the back version be cleared before the back version can be
removed. If the server crashes between those two writes, the back
version becomes an orphan.
>Also not a problem. When a page is allocated, it must first be removed
> host.domain.net Sat Jun 4 17:52:01 2005
> Database: /var/db/live/storedata.gdb
> Page 670001 is an orphan
from the free list (actually, the state of its bit on the page inventory
page must be changed) before it can be assigned to whatever function
it's going to perform.
>Good, they're very bad.
> I have never seen a wrong page type.
>Search IBPhoenix.com for "orphan". I've drizzled on about this before.
> Could you recommend a good source of reading (ether online or in
> paper) for understanding these better please?
>Regards,
Ann