On Mon, Apr 4, 2016 at 2:41 AM, 'Andrew Zenz' andrew@... [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