On Mon, Apr 4, 2016 at 2:41 AM, 'Andrew Zenz' and...@aimsoftware.com.au [firebird-support] <firebird-support@yahoogroups.com> wrote: ...
> > > I am using WI-V2.5.3.26780 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 > > ine: 239) > > 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 pages contain transaction state. Losing a TIP means that some transactions may be lost after reporting a successful commit. When you see that error, make a read-only copy of the database before you 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 analyzes corrupted 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've lost 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 identify bad records with indexed retrievals. This works best on a primary key. Look for records with primary key less than some value. If that works look for records with a key between that value and some other value. When you hit an error, narrow the range. That process should eventually identify all the bad records, and, with luck, you can pump the rest using key ranges. Good luck, Ann
