| Subject | Re: [firebird-support] Re: Rename database command |
|---|---|
| Author | Alexandre Benson Smith |
| Post date | 2013-06-06T15:19:53Z |
Em 5/6/2013 20:01, sir_wally_lewis escreveu:
Maybe you (or the person responsible for the application code) needs to
understand the Firebird principles (MGA) this way you could understand
why the system become slow and fix the reason. I don't think this is
"understand Firebird at atomic level", but to understand why some coding
mistakes could lead to a system slow down and how to fix it. Look at the
cause not at the symptom...
If you manage your transactions properly I doubt you will need a
back-up/restore cycle every week to keep the system responsive.
You said that sweep did not "fix" the problem, but in what circustances
was the sweep run ? If your application keeps a transaction open for a
long time (what I think is the case) running sweep could not help that
much, but if you run sweep when no one is connected I think the result
will be the same (as I said previously the restore process will do more
than a sweep, but I think it's not necessary) as running a
back-up/restore cycle.
The transaction counter is a 32bit integer and when will get close to
this limit you will need to perform a restore to reset it (as the
restore creates a new database, the transaction counter will start from
0 again).
To remove garbage and move forward the OIT the sweep is all you need, as
long when you run sweep there is no transaction open for hours.
see you !
> Hi Sean,Robert,
>
> While I don't pretend to understand Firebird at the atomic level. I am just trying to cope with database slowdowns. We find the only bullet proof methodology to solve database slowdowns is a backup restore. So we are searching for a method to be able to resolve database slowdowns, while keeping the database online.
>
> I am not concerned with whether theoretically firebird should or should not require a backup/restore. It seems that in practice under large database conditions to be a requirement.
>
> Our networks guy is going to spend some time seeing if he can give evidence of this requirement. Of course we will try any method to attempt to resolve this.
>
> In the past we have not found sweeping the database to help, but we will continue to do everything we can to resolve this for our customers sake.
>
> Kind Regards,
>
> Robert
>
Maybe you (or the person responsible for the application code) needs to
understand the Firebird principles (MGA) this way you could understand
why the system become slow and fix the reason. I don't think this is
"understand Firebird at atomic level", but to understand why some coding
mistakes could lead to a system slow down and how to fix it. Look at the
cause not at the symptom...
If you manage your transactions properly I doubt you will need a
back-up/restore cycle every week to keep the system responsive.
You said that sweep did not "fix" the problem, but in what circustances
was the sweep run ? If your application keeps a transaction open for a
long time (what I think is the case) running sweep could not help that
much, but if you run sweep when no one is connected I think the result
will be the same (as I said previously the restore process will do more
than a sweep, but I think it's not necessary) as running a
back-up/restore cycle.
The transaction counter is a 32bit integer and when will get close to
this limit you will need to perform a restore to reset it (as the
restore creates a new database, the transaction counter will start from
0 again).
To remove garbage and move forward the OIT the sweep is all you need, as
long when you run sweep there is no transaction open for hours.
see you !