| Subject | Re: [firebird-support] Firebird 2.5 - Old ODS version databases get progressively slow until a backup/restore is performed into a NEW database. |
|---|---|
| Author | Ann Harrison |
| Post date | 2011-05-25T18:54:56Z |
On Wed, May 25, 2011 at 11:42 AM, Toby Moxham <toby.moxham@...> wrote:
though I wouldn't recommend it. Upgrading the software does not automatically
update the stored database format.
unless you're using something other than gbak for your backup/restore. Gbak
always creates a new file, wiping out the old one if you happen to use the same
name - not a good idea at all.
currently running server. Again, I don't know what you mean by restoring
into an existing database.
time is a large number of old versions. gstat -a -r will report on the number
of old versions. If sweeping isn't working, you should also look for old
transactions. A V1.5 database may be old enough that it still has the
indexes that get to be very slow when removing old versions with lots
of duplicates.
The development group creates new ODS versions to support new features
and performance improvements, and to fix bugs. New ODS versions may
seem frivolous to you, but upgrading really is in your best interest.
Good luck,
Ann
>Current versions of Firebird can use ODS versions dating back to InterBase V5,
> ... the databases will get progressively slower to the point
> where they eventually become unusable.
>
> We think these issues come about from where our systems were initially
> on Firebird 1.5 and have been progressively upgraded to 2.5 (although
> still running on the same initial database) I have been looking into
> the ODS versions of the databases as I assume this could be caused by
> the databases being in older ODS formats whilst running on a newer
> version of firebird.
though I wouldn't recommend it. Upgrading the software does not automatically
update the stored database format.
> This can pretty much always be resolved by performing a backup/restoreErr, I don't know what you mean by backup/restore into the existing database,
> into a NEW database (doing the same backup/restore into the existing
> database will not resolve it)
unless you're using something other than gbak for your backup/restore. Gbak
always creates a new file, wiping out the old one if you happen to use the same
name - not a good idea at all.
>If you're using gbak, a restore will create a database of the ODS of the
> A few questions :
>
> 1. When doing a backup/restore I assume it always converts it into the
> ODS of the firebird server being used? What differences are there
> between restoring into the existing database or into a new one (I ask
> this because we seem to only be able to resolve our issues by restoring
> into a new database)
currently running server. Again, I don't know what you mean by restoring
into an existing database.
>The problem people normally have with databases that get slower over
> 2. Is there any way to stop us having to do this, it seems very
> unnecessary to have to do this - surely firebird should handle working
> with old ODS formats? - I have been investigating gfix -sweep but its
> not very successful.
time is a large number of old versions. gstat -a -r will report on the number
of old versions. If sweeping isn't working, you should also look for old
transactions. A V1.5 database may be old enough that it still has the
indexes that get to be very slow when removing old versions with lots
of duplicates.
The development group creates new ODS versions to support new features
and performance improvements, and to fix bugs. New ODS versions may
seem frivolous to you, but upgrading really is in your best interest.
Good luck,
Ann
>
> NB - this has only become an issue since upgrading all our sites to
> Firebird 2.5, before then we had not really had problems like this.
>