Subject | Re: [firebird-support] Database file disk fragmentation |
---|---|
Author | Svein Erling Tysvær |
Post date | 2007-05-15T08:41:44Z |
Hi Alex!
How did you reach the conclusion that fragmentation is the cause of your performance issues? Normally, performance issues are due to things like long running transactions (check the oldest transaction and next transaction) or queries using a non-optimal plan (these queries may or may not be possible to improve). I'm not saying that fragmentation cannot be the cause of your problems, I've just never heard of such a problem with Firebird before and wondered how you discovered what you describe.
Set
Alexander Tabakov wrote:
How did you reach the conclusion that fragmentation is the cause of your performance issues? Normally, performance issues are due to things like long running transactions (check the oldest transaction and next transaction) or queries using a non-optimal plan (these queries may or may not be possible to improve). I'm not saying that fragmentation cannot be the cause of your problems, I've just never heard of such a problem with Firebird before and wondered how you discovered what you describe.
Set
Alexander Tabakov wrote:
> Hi all,[Non-text portions of this message have been removed]
>
> We've been using Firebird as a DB server for quite a while and one of
> our database files is now well over 5GB. So, the point is that the file gets
> fragmented very heavily which in turn leads to performance issues.
>
> One way of resolving this issue is to create a database with a single
> table which will be heavily populated until it reaches the size you
> need for example 20GB and drop the table afterwards. I read about this
> technique somewhere.
>
> May someone comment on it. For example should I use BLOB fields in the
> table or what? How can I predict the number of inserts I will need to
> pupulate the table to a certain limit? Can I achieve the same result
> in another way?
>
> Thanks in advance.
>
> P.S. I understand that this question is more appropriate for the
> [firebirs-enterprise] list, but since there is almost no activity
> there I prefer to put it here :).
>
> Alex