Subject | Intermittent Database Corruption |
---|---|
Author | hugh_borst |
Post date | 2004-05-04T22:43:46Z |
Hello all;
My company develops and supports an application that is in use by more
than 300 clients around the US. All clients use InterBase 6.0.2 or
FireBird 1.0.3 as the DB server. As we improve and maintain our
system, we deploy various changes to both the applications and the
database metadata with each release. A small number of our clients
who happen to be all on the same (recent) version of our software and
database metadata, but some of whom are running IB 6.0.2 and others of
whom are running FB 1.0.3, are now having difficulty running gbak
successfully. The backup for these sites tends to hang while backing
up data for a particular table (EMAIL_ACCOUNTS). Gfix will sometimes
report record and/or page errors, but mending, backing up and
restoring do not fix the problem for long, if at all. Most often, no
validation errors at all are reported by gfix.
We have also been able to get the backup to complete successfully by
deleting certain constraints temporarily. This change to metadata
seems to allow the backup to complete within a reasonable, nearly
normal time. Again, such repairs are short lived, as the database
performance will again degrade and backups will hang, even when the
database is restored into a new DB file.
When the backup operation has "hung" (gbak is running, but no
progress is apparent) we often see that the backup file is not being
written to, but that the GDB file is being updated. This seems
peculiar and is something we have not previously been aware of; the
backup file is always more recently updated than the database after a
backup. This may go on for hours. Normal backups typically take
minutes. The affected clients' databases range in DB file sizes
from about 280 MB up through 2.9 GB.
Does anyone have any suggestions or experience with a similar problem?
Is there any information about the sort of metadata updates that
may cause DB corruption (other than those done with an in-use DB)?
Can we somehow run the FB engine in a debug mode so we get more
information in the server log about what the server is doing?
Thanks much in advance for your attention and assistance.
Regards,
Hugh J Borst
Hughborst@...
My company develops and supports an application that is in use by more
than 300 clients around the US. All clients use InterBase 6.0.2 or
FireBird 1.0.3 as the DB server. As we improve and maintain our
system, we deploy various changes to both the applications and the
database metadata with each release. A small number of our clients
who happen to be all on the same (recent) version of our software and
database metadata, but some of whom are running IB 6.0.2 and others of
whom are running FB 1.0.3, are now having difficulty running gbak
successfully. The backup for these sites tends to hang while backing
up data for a particular table (EMAIL_ACCOUNTS). Gfix will sometimes
report record and/or page errors, but mending, backing up and
restoring do not fix the problem for long, if at all. Most often, no
validation errors at all are reported by gfix.
We have also been able to get the backup to complete successfully by
deleting certain constraints temporarily. This change to metadata
seems to allow the backup to complete within a reasonable, nearly
normal time. Again, such repairs are short lived, as the database
performance will again degrade and backups will hang, even when the
database is restored into a new DB file.
When the backup operation has "hung" (gbak is running, but no
progress is apparent) we often see that the backup file is not being
written to, but that the GDB file is being updated. This seems
peculiar and is something we have not previously been aware of; the
backup file is always more recently updated than the database after a
backup. This may go on for hours. Normal backups typically take
minutes. The affected clients' databases range in DB file sizes
from about 280 MB up through 2.9 GB.
Does anyone have any suggestions or experience with a similar problem?
Is there any information about the sort of metadata updates that
may cause DB corruption (other than those done with an in-use DB)?
Can we somehow run the FB engine in a debug mode so we get more
information in the server log about what the server is doing?
Thanks much in advance for your attention and assistance.
Regards,
Hugh J Borst
Hughborst@...