On April 1, 2003 04:10 pm, Hugh J Borst wrote:

> All;
>
>
>
> Thank you for your efforts. He are a few more details to answer your
> questions, below.
>
>
>
> We have over 200 customers, each with their own server hardware, network
> and IB installation. Each customer has between 10 and 60 concurrent
> users (obviously, this varies widely among customers depending on the
> size of their business).
>
>
>
> The application is written in Delphi with the BDE and does use some of
> the VCL Transaction and IB Transaction components included in Delphi,
> however, I have not as yet familiarized myself with the transaction
> boundary standards that are in use (I've been here for about a month).
>
>
>
> This problem occurs with some regularity, although without any obvious,
> repeatable characteristics (at least, none that have been discovered as
> yet) in terms of some particular transaction or operation. However, in
> all cases, the database and server PC become almost completely
> unresponsive. Backups are not possible. The system will not recover
> until it is rebooted, which, unfortunately, is happening by brute force
> (i.e., RESET BUTTON) at the hands of the customer. When the system
> comes back up, assuming that IB can open the database, oftentimes
> performance is just okay (not great). Once a backup and restore has
> been done on the DB, the system then performs as normal for a while.
> Please note that this is happening for a smallish subset of our
> installed base. We have not as yet been able to identify any universal
> connection among the involved customer installations (other than the IB
> version 6.0.1.0, which is in most all installations).
>

I think the problem is that the age old problem of stalled OAT/OIT, the
backup/restore resets it, and everything is fine, for a while. First of all,
if there is a time period when the system has low usage, then schedule a
sweep and a garbage collect to occur during that period, this will have a
similar effect to the restore. You should also schedule a backup to occur
during that same time period. Small volume customers might be able to go a
week without the sweep/gc, but if they only use the system 8 hours a day,
then who cares if it spends it's night doing maintenance? This is a
temporary fix, until the application can be reviewed to see if it contains
any long running update transactions, if it does, replace those with short
running update transactions, that will go a long way towards fixing the
problem. I would also, if possible schedule a shutdown/restart once a week,
for the server machine.

Second, customers need to be trained, to never, ever, ever use the reset
button, instead the proper shutdown/restart mechanism for that particular
machine, needs to be used. Using reset can lead to all kinds of problems,
such as data corruption.

>
>
> I will look into the transaction boundaries for the client application.
>