| Subject | RE: [firebird-support] Corruption in Firebird Classic 1.5.3.4870 |
|---|---|
| Author | Bob Murdoch |
| Post date | 2006-12-01T14:38:39Z |
Will,
(FB classic on dual Xeon W2k3 server).
How are you detecting the problem? I usually see an error in one of
the applications when trying to access the table with the problem (in
my case, it is invariably the "Wrong page type - expected 7 found 5)"
error. Ann Harrison has provided some interesting info on this
particular error in the past, you can probably find them by searching
the archives for my name.
I used to do the gfix/backup/restore when I found this problem. This
process takes 10+ hours for my 35GB database, and was not conducive to
a long-term contract relationship with my client <g>.
I have found that rebuilding the offending index has served to get the
applications back on line, and is obviously a much faster alternative
to the one you are using. As a safety precaution, I do a backup and
restore that night, replacing the production db with the newly
restored one (once I confirm the restore worked correctly!).
To rebuild the index:
alter index <name> inactive;
commit;
alter index <name> active;
commit;
However, this will not work if the index is supporting a PK or an FK.
In that case, you either unravel the dependencies to rebuild the
indices, or resort to a backup/restore.
Hopefully someone else will chime in with information on the cause and
how to prevent it. I can't offer anything more than ointment for the
wound.
Bob M..
> -----Original Message-----these
> From: will.honor [mailto:will.honor@...]
> Sent: Friday, December 01, 2006 8:00 AM
>
> I am running four Firebird Classic 1.5.3.4870 Servers. All of
> servers run on Dual Xeon 2.8Ghz Machines one Has 2Gb Ram and runsI have been having the same problem, with a very similar configuration
> Windows 2000 server the rest have 4Gb ram and Windows server 2003.
> These servers have been running mostly without problems for about 18
> months.
> Over the past couple of months the busiest server has shown three
> occasions where Index level corruption has occured. This leads to a
> lengthy backup and restore cycle and a lot of complaints about
> downtime.
(FB classic on dual Xeon W2k3 server).
How are you detecting the problem? I usually see an error in one of
the applications when trying to access the table with the problem (in
my case, it is invariably the "Wrong page type - expected 7 found 5)"
error. Ann Harrison has provided some interesting info on this
particular error in the past, you can probably find them by searching
the archives for my name.
I used to do the gfix/backup/restore when I found this problem. This
process takes 10+ hours for my 35GB database, and was not conducive to
a long-term contract relationship with my client <g>.
I have found that rebuilding the offending index has served to get the
applications back on line, and is obviously a much faster alternative
to the one you are using. As a safety precaution, I do a backup and
restore that night, replacing the production db with the newly
restored one (once I confirm the restore worked correctly!).
To rebuild the index:
alter index <name> inactive;
commit;
alter index <name> active;
commit;
However, this will not work if the index is supporting a PK or an FK.
In that case, you either unravel the dependencies to rebuild the
indices, or resort to a backup/restore.
Hopefully someone else will chime in with information on the cause and
how to prevent it. I can't offer anything more than ointment for the
wound.
Bob M..