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 firebird-support@yahoogroups.com, "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 1.5.3.4870 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

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.
>
> I have been having the same problem, with a very similar

configuration

> (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..
>