Subject Re: Corruption in Firebird Classic
Author jason
I find large databases always corrupt, I think you need to devise
some kind of archive process.

Perhaps copy the .gdb away to archive.gdb and then run some sql
commands to wipe out old data ?

--- In, "Bob Murdoch"
<mailgroups@...> wrote:
> Will,
> > -----Original Message-----
> > From: will.honor [mailto:will.honor@...]
> > Sent: Friday, December 01, 2006 8:00 AM
> >
> > I am running four Firebird Classic Servers. All of
> these
> > servers run on Dual Xeon 2.8Ghz Machines one Has 2Gb Ram and runs
> > Windows 2000 server the rest have 4Gb ram and Windows server 2003.
> > These servers have been running mostly without problems for about
> > months.
> > Over the past couple of months the busiest server has shown
> > occasions where Index level corruption has occured. This leads to
> > lengthy backup and restore cycle and a lot of complaints about
> > downtime.
> I have been having the same problem, with a very similar
> (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
> my case, it is invariably the "Wrong page type - expected 7 found
> error. Ann Harrison has provided some interesting info on this
> particular error in the past, you can probably find them by
> the archives for my name.
> I used to do the gfix/backup/restore when I found this problem.
> process takes 10+ hours for my 35GB database, and was not conducive
> a long-term contract relationship with my client <g>.
> I have found that rebuilding the offending index has served to get
> applications back on line, and is obviously a much faster
> 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
> 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
> how to prevent it. I can't offer anything more than ointment for
> wound.
> Bob M..