FirebirdSQL
Decompression overran buffer (179) while backing up a database. Firebird 5.0.3.1642
internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 494)
gds_$receive failed
unknown ISC error 336330835
version of the Firebird:
gbak:gbak version WI-V5.0.3.1642 Firebird 5.0 9dc399f
gbak: Version(s) for database ""
Firebird/Windows/AMD/Intel/x64 (access method), version "WI-V5.0.3.1642 Firebird 5.0 9dc399f"
on disk structure version 13.1
gbak:readied database for backup
gbak:creating file
gbak:starting transaction
gbak:use up to 8 parallel workers
gbak:database has a page size of 8192 bytes.
Allegedly, two fields were added to the table while it was being accessed by other connections. The server has a classic architecture.
@hvlad
It’s better to return the infamous "object is in use" error than to keep the current state. We had a stressful day and night and put in enormous effort to restore the data in the production database.
Just a suggestion: if the error is caused by a mismatch between the record’s structure version number and the compressed data, and we know that multiple structure versions exist in the database, could we try each version to decompress the data?
Why do you think that addition of fields is related with record corruption ?
It’s better to return the infamous "object is in use" error than to keep the current state. We had a stressful day and night and put in enormous effort to restore the data in the production database.
I'm sorry you under a stress, but I can't quite understand what you mean.
Just a suggestion: if the error is caused by a mismatch between the record’s structure version number and the compressed data, and we know that multiple structure versions exist in the database, could we try each version to decompress the data?
Record header contains format number thus such attempts not necessary and I doubt it can help. Or you want to say that you successfully decompressed corrupted record using another format ? Do you have copy of corrupted DB for analyze ?
PS there is an opinion that such bugcheck's should be replaced by regular error's, to not break others operations. But it is not as easy and could add some perf. penalty due to additional checks.
Why do you think that addition of fields is related with record corruption ?
We upgraded the server in April, and it had been working without any database corruption since then. The incident occurred on July 28 and led to the corruption of records in one particular table. On that day, two fields were added to the table while it was in use.
It’s better to return the infamous "object is in use" error than to keep the current state. We had a stressful day and night and put in enormous effort to restore the data in the production database.
I'm sorry you under a stress, but I can't quite understand what you mean.
In the days of Yaffill/FB 0.9, most metadata-changing operations were prohibited while someone else was connected to the database. It was very inconvenient, but at least the database didn’t get corrupted.
Just a suggestion: if the error is caused by a mismatch between the record’s structure version number and the compressed data, and we know that multiple structure versions exist in the database, could we try each version to decompress the data?
Record header contains format number thus such attempts not necessary and I doubt it can help. Or you want to say that you successfully decompressed corrupted record using another format ? Do you have copy of corrupted DB for analyze ?
I'll check and write privately.
PS there is an opinion that such bugcheck's should be replaced by regular error's, to not break others operations. But it is not as easy and could add some perf. penalty due to additional checks.
If it helps: The corrupted table (GD_DOCUMENT) was being intensively used at the moment the two fields were added. This table is part of the Document Entity and is always referenced by another table. Only records in the GD_DOCUMENT table were corrupted. The linked table remained intact and was used as a source during the restoration process.