<<My question is the result of the investigation of the database that froze during backup (as reported in https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/131840). 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 database: 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 regularly. 2. Errors in the firebird log = probable corruptions to the database... Please read this. http://www.ibphoenix.com/resources/documents/search/doc_5 Paul
