Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gbak: ERROR:BLOB not found [CORE3492] #3851

Open
firebird-automations opened this issue May 24, 2011 · 1 comment
Open

gbak: ERROR:BLOB not found [CORE3492] #3851

firebird-automations opened this issue May 24, 2011 · 1 comment

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: František Jahoda (frantisek.jahoda)

Regular backups with "gbak -b" failed at these error

gbak: ERROR:BLOB not found
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors

content of /var/log/firebird.log (all times are in UTC):
our_database (Server) Tue May 17 03:34:51 2011
Database: /srv/firebird/our_database.fdb
deadlock
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)

our_database (Server) Tue May 17 03:36:39 2011
Database: /srv/firebird/our_database.fdb
deadlock

our_database (Server) Tue May 17 03:36:44 2011
Database: /srv/firebird/our_database.fdb
deadlock

our_database (Server) Wed May 18 06:15:25 2011
Fatal lock manager error: invalid lock id (21688), errno: 22

Last successful backup started at 2011-05-17T22:00Z and ended at 2011-05-18T04:53Z

after that error we have been unable to backup database, gfix binary copy of it trough --mend or --validate --full
we were able to backup database with gbak -b --ignore but unable to restore (gbak restored the file but ended on bad page type error and quit)
but the gfix was able to find a lot of following types of errors:

Database: /mnt/tmp/our_database.fdb
Index 1 is corrupt on page 8136665 level 1. File: ../src/jrd/validation.cpp, line: 1649
in table DEVICE_PIM_DATA (133)

our_database (Server) Fri May 20 16:24:02 2011
Database: /mnt/tmp/our_database.fdb
Page 22655159 is an orphan

We were able to finally backup the database after manually scanning all blobs and removing records with missing blobs (cca 8 records).
Our database have 89GB file size (cca 70% of content are blobs). After gbak failed we upgraded to 2.1.4 and solved the problem with this version. We provide free service for users all around the world so we do not want any downtime. (but the database itegrity is still a priority).

Should we do anything about reported errors?

@firebird-automations
Copy link
Collaborator Author

Modified by: František Jahoda (frantisek.jahoda)

description: Regular backups with "gbak -b" failed at these error

gbak: ERROR:BLOB not found
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors

content of /var/log/firebird.log (all times are in UTC):
our_database (Server) Tue May 17 03:34:51 2011
Database: /srv/firebird/our_database.fdb
deadlock
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)

our_database (Server) Tue May 17 03:36:39 2011
Database: /srv/firebird/our_database.fdb
deadlock

our_database (Server) Tue May 17 03:36:44 2011
Database: /srv/firebird/our_database.fdb
deadlock

our_database (Server) Wed May 18 06:15:25 2011
Fatal lock manager error: invalid lock id (21688), errno: 22

Last successful backup started at 2011-05-17T22:00Z and ended at 2011-05-18T04:53Z

after that error we have been unable to backup database, gfix binary copy of it trough --mend or --validate --full
we were able to backup database with gbak -b --ignore but unable to restore (gbak restored the file but ended on bad page type error and quit)
but the gfix was able to find a lot of following types of errors:

Database: /mnt/tmp/our_database.fdb
Index 1 is corrupt on page 8136665 level 1. File: ../src/jrd/validation.cpp, line: 1649
in table DEVICE_PIM_DATA (133)

our_database (Server) Fri May 20 16:24:02 2011
Database: /mnt/tmp/our_database.fdb
Page 22655159 is an orphan

We were able to finally backup the database after manually scanning all blobs and removing records with missing blobs (cca 8 records).
Our database have 89GB file size (cca 70% of content are blobs). After gbak failed we upgraded to 2.1.4 and solved the problem with this version. We provide free service for users all around the world so we do not want any downtime. (but the database itegrity is still a priority). Should we do anything about reported errors?

=>

Regular backups with "gbak -b" failed at these error

gbak: ERROR:BLOB not found
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors

content of /var/log/firebird.log (all times are in UTC):
our_database (Server) Tue May 17 03:34:51 2011
Database: /srv/firebird/our_database.fdb
deadlock
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)

our_database (Server) Tue May 17 03:36:39 2011
Database: /srv/firebird/our_database.fdb
deadlock

our_database (Server) Tue May 17 03:36:44 2011
Database: /srv/firebird/our_database.fdb
deadlock

our_database (Server) Wed May 18 06:15:25 2011
Fatal lock manager error: invalid lock id (21688), errno: 22

Last successful backup started at 2011-05-17T22:00Z and ended at 2011-05-18T04:53Z

after that error we have been unable to backup database, gfix binary copy of it trough --mend or --validate --full
we were able to backup database with gbak -b --ignore but unable to restore (gbak restored the file but ended on bad page type error and quit)
but the gfix was able to find a lot of following types of errors:

Database: /mnt/tmp/our_database.fdb
Index 1 is corrupt on page 8136665 level 1. File: ../src/jrd/validation.cpp, line: 1649
in table DEVICE_PIM_DATA (133)

our_database (Server) Fri May 20 16:24:02 2011
Database: /mnt/tmp/our_database.fdb
Page 22655159 is an orphan

We were able to finally backup the database after manually scanning all blobs and removing records with missing blobs (cca 8 records).
Our database have 89GB file size (cca 70% of content are blobs). After gbak failed we upgraded to 2.1.4 and solved the problem with this version. We provide free service for users all around the world so we do not want any downtime. (but the database itegrity is still a priority).

Should we do anything about reported errors?

environment: PC, Debian Squeeze => amd64, Debian Squeeze

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant