<<My question is the result of the investigation of the database that froze 
during backup (as reported in 
 Backup froze during backup of two tables and both of those tables had large 
gstat "max version" table parameter - it was 1400 for one table and 550 for the 
other table. All the remaining tables had 0 values.

Are such values for max version dangerous? What can I do and what should I do 
not to avoid such large max version values?

I have observed that there are errors in Firebird.log during backup of this 
Warning: Pointer page bits are not consistent with data page 
Error: Chain for record is broken in table
Error: Record is marked as damaged in table

But errors diasppear after backup/restore - till the next time (after several 
week) when the backup is being made and when the freezing occurs again on the 
same tables during backup.

So - because errors disappear, I should conclude that database in good state 
but something bad occurs during time between two backups. Maybe some special 
sequence of SQL commands creates such errors?

No clear idea what to do?>>

Two issues... 
1. Max versions = older versions of a record that will be tidied up by garbage 
collection at an
appropriate time, either by sweep (gfix -s), coperative garbage collection or 
by gbak when a
backup takes place.
Consider using the -g switch during backup to inhibit garbage collection and 
instead run sweeps 

2. Errors in the firebird log = probable corruptions to the database...
Please read this.


  • [firebird-suppor... jonatan.laurit...@yahoo.dk [firebird-support]
    • RE: [firebi... 'Paul Beach' pbe...@mail.ibphoenix.com [firebird-support]
    • Re: [firebi... Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]

Reply via email to