At 21:52 4/09/2008, you wrote:

>Good morning,
>
>We have problems with a firebird2.0 database after we recently
>upgraded from
>fb1.5 to fb2.0.
>Our customers work the whole day with the database. Normally the database
>grows about 2 MB per day, now it is 20MB.

You have just restored this database. A freshly restored database has no recycled space waiting to be filled up so, for a time, you will see "growth" as the engine acquires enough space to accommodate that high level of garbage that you are building up.

>A normal backup/restore does not work.

Explain what "does not work" means.

>Here you see the header information. As you can see there is a big gap
>between the oldest transaction and the next transaction.

You need to figure out whether that gap is big, considering what you are doing. Is this the first time you have ever monitored the gap?

>How can that occur,

A gap occurs all the time, really. As long as a transaction remains "interesting" the old record versions that it has generated will not be garbage collected...

>do we need to fix it,

If the garbage buildup is causing problems, you fix it by fixing your application code so that idle transactions get committed. If you have not changed the application code then this is not a new problem - it has always been there.

If you are using Superserver and you also used SS previously, then it is possible that the effect of the garbage buildup is being heightened due to the different way that the Fb 2 engine manages garbage. By default it uses both background GC and cooperative GC. You can revert the GC policy (GCPolicy in firebird.conf) to background alone - I leave it to you to read the release notes regarding this. It won't fix any intrinsic faults in your transaction management but it will get you back to a similar level to Fb 1.5, which does only background GC.

If you changed from SS to Classic then you have only cooperative GC.

>can we fix it while the database is connected?

You can run a sweep while the database is connected. You can edit a config setting while the database is connected, too, but it won't take effect until the *SERVER* is shut down and restarted.

>Database header page information:
> Flags 0
> Checksum 12345
> Generation 71450
> Page size 8192
> ODS version 11.0
> Oldest transaction 45907
> Oldest active 67376
> Oldest snapshot 63944
> Next transaction 71442
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 1000
> Next header page 0
> Database dialect 1
> Creation date Sep 2, 2008 21:09:43
> Attributes force write
>
> Variable header data:
> Sweep interval: 20000
> *END*

According to these stats you have started about 71.5K transactions in less than two days. Transaction number 45907 is still interesting but it is not active. That means you have an unknown number of younger transactions whose garbage is "stuck". Your oldest active transaction is quite recent, compared to your throughput, i.e. the gaps between the oldest active and oldest snapshot, and OS and the next transaction, respectively, are relatively small. Your database is holding garbage, though. But these numbers are not excessive...keep monitoring to see if there is movement.

>The next problem (no idea if this has anything to do with the above):

It doesn't. ;-)

>If I try to startup my application with the Remote desktop connection this
>fails, and in the firebird logfile I
>see the following message:
> XNET error (xnet:2043) connection lost: another side is dead
>Does this message mean anything to you?

Well, you can't use the XNET protocol from a remote desktop connection, even if the RDT client is running on the same physical machine as the server. Your RDT client will need to use TCP/IP protocol (servername:alias or servername:disk:\path\to\database_file)

./heLen