I see that you have only 1024 page buffers.
Do you use SuperServer or Classic?
If Superserver then increase it.
Regards,
Karol Bieniaszewski
02.03.2019 10:50, Karol Bieniaszewski liviusliv...@poczta.onet.pl
[firebird-support] wrote:
> You have quite big fill 94%, that there is a chence that new page must be
> allocated – but
> here still you have free slots.
It may be a sign of record fragmentation which is bad from performance
You have 91345 versions but Max versions is 1. Then i do not think that
performance problem is here.
You have quite big fill 94%, that there is a chence that new page must be
allocated – but here still you have free slots.
You have gap between oldest active nad next transaction. It is not big
Hi Karol, here's the gstat information I got once I was able to get the
database to effectively go into a tailspin when I finished updating that table:
The database:
Database header page information:
Flags 0
Checksum12345
Hi Karol, I'm going to run some tests on the database this weekend as I think I
know how to trigger this behavior. Once I get it to do that, I'll get the
results and post them.
Thanks
Myles
Hi Lester, I have definitely asked similar questions to the client. But they
have started to use this historical database for their own reporting, etc. and
that isn't its original purpose. Having said that, there is not an easy way to
identify changes, but I may talk to them further about
Thanks Mark. The nightly load process is triggered by the availability of the
source CSV file that is provided by a 3rd party, and we don't have that much
control over when this is produced. It is one of those things that the second
we get to access it, then the database has to begin the kill
On 22-2-2019 05:33, my...@techsol.org [firebird-support] wrote:
> Thanks Helen. Just a few clarifications, that might help whittle this
> down a bit...
>
> >Given that this table is "temporary" storage, one supposes that you
> are deleting rows from it regularly. Do you happen to be deleting
>
On 22/02/2019 04:33, my...@techsol.org [firebird-support] wrote:
> >Given that this table is "temporary" storage, one supposes that you
> are deleting rows from it regularly. Do you happen to be deleting
> 900,000 rows each day before you load up the latest batch of 900,000?
How much information
16 KB page size is ok and is maximal for FB1.5 to FB3.
During problem time run gfix -h and show us the results and also gstat results
for that tabe and indexes on it.
P.S. to recreate index you do not need to set it inactive. You can activate
already active index. But this operation can be done
Thanks Helen. Just a few clarifications, that might help whittle this down a
bit...
>Given that this table is "temporary" storage, one supposes that you
are deleting rows from it regularly. Do you happen to be deleting
900,000 rows each day before you load up the latest batch of 900,000?
Thank you for your comment. Very helpful. I ran gstat on the database, and on
the table in question. It is the default 16K page size. Are you saying that a
larger page size would be more appropriate? If so, how large would you
suggest? And is it correct that the only way to change the
12 matches
Mail list logo
