Subject | Re: [firebird-support] FB 1.5 - Continuing database corruption issues |
---|---|
Author | Ann W. Harrison |
Post date | 2006-11-16T23:24:20Z |
Bob Murdoch wrote:
Page type 7 is a b-tree page. Page type 5 is a data pages. If there's
something slightly wrong with page allocation during a bucket split in
an index, the problem would show up faster in classic than superserver,
and the chances are good that the improperly allocated page would be
reallocated as a data page, since those are the pages that are most
often allocated. If the first number is always 7 and the other number
is usually 5, that's an interesting clue too.
The rest of your explanation sounds as if that's the case, since
rebuilding indexes makes the problem go away. Do you have a copy of
the corrupted database? Can you get a free copy of IBSurgeon and run
it to identify the corrupted index? Then at a minimum, you could
reduce the cost to rebuilding that index instead of all indexes.
I'd really like to understand what's happening better, and knowing
which index is corrupt would help - which index and how is it loaded
and used. Indexes on normally ascending
Is the problem more likely to occur when your appending data or when
you're storing data in a table where you've just done some massive
deletes? If you can identify the index where the problem occurs (if
it is just one index) knowing how deep that index is might also be
interesting. This seems to be a fairly low probability event, so
hints help.
Regards,
Ann
> I am running FB 1.5 classic ...Is the problem consistently "expected 7, found 5"? Never other numbers?
>
> We have been having periodic problems with corruption. In almost all
> recent cases, the corruption is discovered by an error message
> received by a client process. The nature of the message is "wrong
> page type - expected 7, found 5".
Page type 7 is a b-tree page. Page type 5 is a data pages. If there's
something slightly wrong with page allocation during a bucket split in
an index, the problem would show up faster in classic than superserver,
and the chances are good that the improperly allocated page would be
reallocated as a data page, since those are the pages that are most
often allocated. If the first number is always 7 and the other number
is usually 5, that's an interesting clue too.
The rest of your explanation sounds as if that's the case, since
rebuilding indexes makes the problem go away. Do you have a copy of
the corrupted database? Can you get a free copy of IBSurgeon and run
it to identify the corrupted index? Then at a minimum, you could
reduce the cost to rebuilding that index instead of all indexes.
I'd really like to understand what's happening better, and knowing
which index is corrupt would help - which index and how is it loaded
and used. Indexes on normally ascending
Is the problem more likely to occur when your appending data or when
you're storing data in a table where you've just done some massive
deletes? If you can identify the index where the problem occurs (if
it is just one index) knowing how deep that index is might also be
interesting. This seems to be a fairly low probability event, so
hints help.
Regards,
Ann