Subject | Re: Gbak never end... |
---|---|
Author | Adam |
Post date | 2009-02-12T22:47:30Z |
--- In firebird-support@yahoogroups.com, Dimitry Sibiryakov <sd@...>
wrote:
of information provided.
I have no doubt that this problem is primarily that gbak is cleaning
up garbage records, but this does not take into account some
possibilities. Certainly the -g flag will help if this is the case.
Some possibilities are:
1. Someone may have opened a transaction in a monitoring tool to
observe the database and left it open for a period of time.
2. Someone may have purged a lot of data. The OP doesn't tell us which
Firebird version, but garbage collection on purged tables with a
foreign key field with many duplicated values is extremely expensive
before FB 2.0.
3. GBak may still be running from before. This will hold a transaction
open, compounding the phenomenon.
or
4. Many Delphi component sets tend to push towards a model where
transaction management is not considered. An extra challenge as a
Delphi programmer has to be to ensure that your code doesn't leave
transactions active longer than necessary. This means regular commits
or rollbacks.
If you have Firebird 2.1, you can look at the field
mon$attachments.mon$timestamp to identify the culprits.
Adam
wrote:
>That may be true, but a pretty big call to make with the vague amount
> > So, is it mean that the database is corrupt?
>
> No, it means that your application is a crap and doesn't commit
> transaction in time.
of information provided.
I have no doubt that this problem is primarily that gbak is cleaning
up garbage records, but this does not take into account some
possibilities. Certainly the -g flag will help if this is the case.
Some possibilities are:
1. Someone may have opened a transaction in a monitoring tool to
observe the database and left it open for a period of time.
2. Someone may have purged a lot of data. The OP doesn't tell us which
Firebird version, but garbage collection on purged tables with a
foreign key field with many duplicated values is extremely expensive
before FB 2.0.
3. GBak may still be running from before. This will hold a transaction
open, compounding the phenomenon.
or
4. Many Delphi component sets tend to push towards a model where
transaction management is not considered. An extra challenge as a
Delphi programmer has to be to ensure that your code doesn't leave
transactions active longer than necessary. This means regular commits
or rollbacks.
If you have Firebird 2.1, you can look at the field
mon$attachments.mon$timestamp to identify the culprits.
Adam