Subject | Strange problem - database becomes unresponsive |
---|---|
Author | Terry Johnson |
Post date | 2004-04-26T20:45:39Z |
I've been running a fairly simple database with FB 1.5 on Linux for some
time. During this time, no major changes to the DB, and it's been
consistently running well. Until last week. Now the DB runs for a bit,
and seems ok during this time, but within a short period it just hangs.
The firebird process can't be stopped in a normal manner, and connection
attempts with ISQL just hang too. We've been running Super Server and
tried changing to Classic, but it still behaves the same way. This DB is
under almost zero load, btw.
The DB consists of about 15 tables, with each table keyed on a couple of
integers. There are a couple of triggers that only fire on deletes. A
few foreign key constraints. And the whole DB is only 70MB (mostly
graphic blobs). It is quite simple and undemanding. Probably the only
odd thing is the use of Varchar fields with CHARSET NONE for the storage
of some utf-8 encoded strings (but even there, there are none being used
as keys). The database seems to not be corrupt.
Is there any way to find out what is going on?
Terry
time. During this time, no major changes to the DB, and it's been
consistently running well. Until last week. Now the DB runs for a bit,
and seems ok during this time, but within a short period it just hangs.
The firebird process can't be stopped in a normal manner, and connection
attempts with ISQL just hang too. We've been running Super Server and
tried changing to Classic, but it still behaves the same way. This DB is
under almost zero load, btw.
The DB consists of about 15 tables, with each table keyed on a couple of
integers. There are a couple of triggers that only fire on deletes. A
few foreign key constraints. And the whole DB is only 70MB (mostly
graphic blobs). It is quite simple and undemanding. Probably the only
odd thing is the use of Varchar fields with CHARSET NONE for the storage
of some utf-8 encoded strings (but even there, there are none being used
as keys). The database seems to not be corrupt.
Is there any way to find out what is going on?
Terry