Subject | Re: severe db error |
---|---|
Author | vincent_kwinsey |
Post date | 2008-05-19T17:30:08Z |
Well - mayebe you should do the recovery more carefully - the usual
process is that gfix with mend option marke the invalid records and
then - the backup/restore (it is better to do this with 'deactivate
indices' option on) then simply doesn't restpre the invalid records -
naturally - this can lead to foreign key violations and so on - but -
if invalid records are not many - this is the best situation.
From my experience - I had situation, when the described process does
nothing and so - the only situation was - that I simply try to move
records from corrupted database to clean, empty database one by one.
One can write simple program that do it - reads records from invalid
database and inserts into the new database and catches exception (if
read of invalid records are done) whenecver it raises, simplyu
recnnects to DB in this case and proceed with next record (the
invalid record can be logged). The usual case is - that records are
gorouped into data pages and corruption usually touches some paged
and other records can be read normally.
So - this is again the oppotunity to mount support for implementation
of recovery journal into FB, from which the recovery can be done
automatically. There is the relevant issue in bugtrack.
process is that gfix with mend option marke the invalid records and
then - the backup/restore (it is better to do this with 'deactivate
indices' option on) then simply doesn't restpre the invalid records -
naturally - this can lead to foreign key violations and so on - but -
if invalid records are not many - this is the best situation.
From my experience - I had situation, when the described process does
nothing and so - the only situation was - that I simply try to move
records from corrupted database to clean, empty database one by one.
One can write simple program that do it - reads records from invalid
database and inserts into the new database and catches exception (if
read of invalid records are done) whenecver it raises, simplyu
recnnects to DB in this case and proceed with next record (the
invalid record can be logged). The usual case is - that records are
gorouped into data pages and corruption usually touches some paged
and other records can be read normally.
So - this is again the oppotunity to mount support for implementation
of recovery journal into FB, from which the recovery can be done
automatically. There is the relevant issue in bugtrack.
--- In firebird-support@yahoogroups.com, "Eric" <Eric@...> wrote:
>
> My database is crashing. After a GFIX with -v -f and -m(end) the
logfile
> is reporting these errors. I already tried to back up and restore
the
> database, but the errors remain. (mostly with error: internal gds
> software consistency check (decompression overran buffer (179),
file:
> sqz.cpp line: 231)
>
>
>
> At the moment running FB 2.1 with WIN2000
>
>
>
> Is there a way to isolate these records and eventually delete them
to
> recover this error? Or get to know which record it is. Or any other
way
> to handle this error?
>
>
>
> Thanks for your appreciated help!!
>
>
>
> Eric Schokker
>
>
>
>
>
> NTUSBS (Server) Mon May 19 13:15:42 2008
>
> Database: POSitie
>
> Record 118812 is wrong length in table KMU (150)
>
>
>
>
>
> NTUSBS (Server) Mon May 19 13:15:42 2008
>
> Database: POSitie
>
> Record 118813 is wrong length in table KMU (150)
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>