Subject | Re: [firebird-support] Table limits |
---|---|
Author | Robert martin |
Post date | 2006-08-29T20:58:55Z |
Hi
Tested on 1.5.1 and 1.5.3.4870 superserver. Both machines exhibit the
issue. Dropping the tables rectifies the situation. (Although it takes
about 2hrs to do it !)
I'm not to worried as we now have code in place to prevent this
occurring again. Its not a user / transaction issue as I can replicate
it with one user and backing & restoring the database does not improve it.
BTW I was wrong with 5s. I retested and it took .87s (still slow).
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Svein Erling Tysvaer wrote:
Tested on 1.5.1 and 1.5.3.4870 superserver. Both machines exhibit the
issue. Dropping the tables rectifies the situation. (Although it takes
about 2hrs to do it !)
I'm not to worried as we now have code in place to prevent this
occurring again. Its not a user / transaction issue as I can replicate
it with one user and backing & restoring the database does not improve it.
BTW I was wrong with 5s. I retested and it took .87s (still slow).
Rob Martin
Software Engineer
phone +64 03 377 0495
fax +64 03 377 0496
web www.chreos.com
Wild Software Ltd
Svein Erling Tysvaer wrote:
> Which version of Firebird and exactly what takes 5+ seconds? I don't
> quite remember how or when, but once upon a time someone said that
> adding an index to system tables made things go faster (hence which
> version of Firebird, others will know whether such an index exists in
> the version you report back). And IBO gets lots of system table
> information upon connecting to a database or preparing the first query
> and other connectivity tools may or may not do the same (I simply don't
> know). If you use the latest version of Firebird and a select count(*)
> from table_with_one_record takes five seconds when using isql, then
> something is seriously wrong.
>
> Poor transaction handling may of course also give problems like the one
> you report, but I guess you've already checked the statistics and there
> is no huge gaps between the oldest interesting/active transactions and
> the next transaction, and that no huge insert/update/deletes that have
> taken place in those gaps.
>
> By the way, how many concurrent connections are there to this database,
> and is the customer using classic or superserver?
>
> Set
>
> Robert martin wrote:
>
>> Hi
>>
>> We have some data where we have had a bit of a 'blow out' and a large
>> number of tables have been created. Normal our database has about 200
>> tables however this one has around 7000. Out of interest what is the
>> limit on the number of tables for a FB DB?
>>
>> We only noticed this because the user reported a large decrease in
>> performance of the system. We also notice this, simple things like
>> selecting data from a 1 record table takes 5+ seconds. We have backed
>> up the database and restored but the performance is still bad. Do you
>> think it might just be we are pushing the limits on the number of tables.
>>
>> The database if just under 500 Mb. Our standard tables contain all the
>> data and the extra 7800 tables have between 0 and a few dozen records at
>> most.
>>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>