Subject Re: [firebird-support] Communication with FB server became 5 times slower
Author Mr. John
Thanks a lot Dunbar for your suggestions

Database header page information:
Flags 0
Checksum 12345
Generation 9215
Page size 4096
ODS version 11.1
Oldest transaction 9205
Oldest active 9206
Oldest snapshot 9206
Next transaction 9207
Bumped transaction 1
Sequence number 0
Next attachment ID 221
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Feb 12, 2010 18:04:13

Variable header data:
Sweep interval: 20000

Database file sequence:
File D:\data_serv\_config_.fdb is the only file

Primary pointer page: 173, Index root page: 174
Data pages: 2, data page slots: 2, average fill: 61%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 1

for gfix execution gives no message
in IBExpert :
IBE: Validation completed, no errors found

Should I try to use FB classic ? I never used it this way I also have no ideea how to do it,there are some 10 users that connects to actual superserver,how to configure it to replace superserver ?

Win 2003 admin told me that he found on a forum the same problem described on a machine with MS SQL Server just after some pathes were applied to this server,and he know that the vendor of the other application that uses MS Sql applied some pathes jut 2 weeks ago.He told me that we should try another server based only on Linux,I have no ideea how to work with linux no also with Firebird on linux,where do I have to start ?My app is written on .NET,and will run on client sided based on Windows,do I have to make some specific opertions to acces FB-linux server?

Thanks !

From: "Dunbar, Norman" <norman.dunbar@...>
Sent: Wed, February 17, 2010 5:40:39 PM
Subject: RE: [firebird-support] Communication with FB server became 5 times slower

Mr John,

>> I also copy all data and application to my personal computer
>> and it works fine,so i think it is not a database problem.

>> Firebird version is 2.1.3 (Firebird-2. 1.3.18185) .My
>> application freeze for 5-7 seconds when run a simple
>> "SELECT * FROM mydb_users " there are 20 records in that table.

What does a "gstat database_name -r -t MYDB_USERS" command result in?

I'm wondering is it's possible that you have a lot of record back
versions lying around in your table?

Have you run a sweep recently? gfix -sweep database_name and then tried

Just a couple of thoughts that may help.


[Non-text portions of this message have been removed]