Slalom wrote:

> Sean,
>
> This is the header from my 1.5.3 database which I am accessing from a 1.5.3 server. I had to rollback to this version because 2.0 was jacked. Currently, this database is in production mode and running perfectly and is responding to requests lickety split. Attached header from right now:
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 358867
> Page size 4096
> ODS version 10.1
> Oldest transaction 452
> Oldest active 453
> Oldest snapshot 453
> Next transaction 358860
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 1
> Creation date Dec 11, 2006 12:29:47
> Attributes no reserve
>
> Variable header data:
> Sweep interval: 0
>
>
>

Hi !

Oldest active 453
Oldest snapshot 453
Next transaction 358860


You have a big gap in transactions, meaning that you have an open
transaction for a long time.

Your sweep interval is set to 0 wich means that the garbage collection
thread will not start automatically on FB 1.5, you should run gfix to
sweep the database manually.

In FB 2.0 the default garbage collection policy is a combination between
a back ground thread and a cooperative garbage collecion:
In FB SS 1.X there is only the background thread.
in FB 1.X CS only the cooperative GC is available.

The cooperative GC means that each "user" that reads the data pages
perform the GC as it found it, the cooperative GC tend to maintain the
garbage in a low level, buut ata cost that one query could be slower as
it has to clean the garbage it founds.

Maybe if you change your firebird.conf for FB 2.0 to use background GC
you will have the same speed as FB 1.5.

But as said by Sean, your problem relies on having a transaction open
for a long time.

see you !

The combined approach tend to lead to a better system performance

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br