|Subject||Re: [firebird-support] db corruption|
On Mon, Apr 4, 2016 at 2:41 AM, 'Andrew Zenz' andrew@... [firebird-support] <email@example.com> wrote:...
I am using WI-V22.214.171.124780 Firebird 2.5 ODS 11.2
For both databases while running gbak:
gbak -user sysdba -password masterkey -b -ig -l corrupt.fdb corruptbak.fbk –v
I get the error:
gbak: ERROR:internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp l
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors
gbak: ERROR:internal Firebird consistency check (can't continue after bugcheck)
When I run gfix on both:
gfix -user sysdba -password masterkey -validate -full -no_update corrupt.fdb
I get the error:
internal Firebird consistency check (cannot find tip page (165), file: tra.cpp line: 2375)The first error - decompression overran buffer - is a bad sign, but it may affect only one record,or with luck only one back version. But, that last error - cannot find tip page - is bad. TIP pagescontain transaction state. Losing a TIP means that some transactions may be lost after reportinga successful commit. When you see that error, make a read-only copy of the database beforeyou do anything else or Firebird may start garbage collecting good data.Gfix handles a limited number of common problems. IBSurgeon has a free tool, FirstAid, that analyzescorrupted databases and reports back all the types of corruption. In another mode, which is not free,it will fix some problems. More complicated corruptions require some degree of manual intervention.IBPhoenix, for one, has people and tools that can fix many corruptions. In your case, since you'velost a TIP, I'd recommend professional help if you want the as much of the data back as possible.
I can pump some (most) of the data from them but hit errors on some tables (unfortunately large important
ones) . One DB is 1.3Gb, the other is over 11Gb.On a read-only copy of the database, you can probe with isql or another data browsing tool to identifybad records with indexed retrievals. This works best on a primary key. Look for records with primarykey less than some value. If that works look for records with a key between that value and some othervalue. When you hit an error, narrow the range. That process should eventually identify all the badrecords, and, with luck, you can pump the rest using key ranges.Good luck,Ann