Subject | Frequent database corruption |
---|---|
Author | Aeschbacher, Fabrice |
Post date | 2007-07-23T09:48:02Z |
Hi,
OS : Linux kernel 2.4.21
Version: LI-V6.3.1.4481 Firebird 1.5 / superserver
We are using firebird on an embedded device for a while (i386,
RAM=128MB), and are experiencing very frequent database corruption. The
database file is in this case even no more being able to be backuped
with gbak. In firebird.log, I can see many errors:
eds2-2STD-VID (Server) Wed Jul 4 11:05:00 2007
Database: /data/db/sistore_cx.fdb
internal gds software consistency check (wrong record length
(183))
...
eds2-2STD-VID (Server) Wed Jul 18 16:59:54 2007
Database: /data/db/sistore_cx.fdb
internal gds software consistency check (wrong record length
(183))
In this case, some SQL queries will allways fail:
SELECT * FROM EventsUnfinished( '____00__', '____0_0_', '2007-07-20
17:10:34.000' )
=> internal gds software consistency check (can\'t continue after
bugcheck)
In this case, the only thing we can do is to delete the database and
re-create a new one. Allmost all databases get corrupted, soon or later,
leading to a complete loss of all datas.
In the application, there is only one unique thread executing all
queries (so no consequent access at all).
Has someone any idea that could help us to solve this problem?
Best regards
Fabrice Aeschbacher
OS : Linux kernel 2.4.21
Version: LI-V6.3.1.4481 Firebird 1.5 / superserver
We are using firebird on an embedded device for a while (i386,
RAM=128MB), and are experiencing very frequent database corruption. The
database file is in this case even no more being able to be backuped
with gbak. In firebird.log, I can see many errors:
eds2-2STD-VID (Server) Wed Jul 4 11:05:00 2007
Database: /data/db/sistore_cx.fdb
internal gds software consistency check (wrong record length
(183))
...
eds2-2STD-VID (Server) Wed Jul 18 16:59:54 2007
Database: /data/db/sistore_cx.fdb
internal gds software consistency check (wrong record length
(183))
In this case, some SQL queries will allways fail:
SELECT * FROM EventsUnfinished( '____00__', '____0_0_', '2007-07-20
17:10:34.000' )
=> internal gds software consistency check (can\'t continue after
bugcheck)
In this case, the only thing we can do is to delete the database and
re-create a new one. Allmost all databases get corrupted, soon or later,
leading to a complete loss of all datas.
In the application, there is only one unique thread executing all
queries (so no consequent access at all).
Has someone any idea that could help us to solve this problem?
Best regards
Fabrice Aeschbacher