Subject RE: [firebird-support] slow database ref/eDN8022297953
Author dennis
Hello Helen



First of all guys thank you for your replies.

Helen I have developed dataset components that inherit from ibx components that manages the transactions in order to commit or rollback each one transaction for each dataset. Of course I have increased that page size.



The problem still persist by wrong general aspect that I am working on to fix it: a transaction could be leaved opened for days on! This is happening because the application waits a selection from an opened dataset. Ok, this is wrong and I will fix it. Can be this responsible for this “gap”? because the dataset components (1,5 month now) are create instantly transactions that are always get committed or rolled back.



Here is a gstat from another database that has no problem at all (or we don’t face problem). This server is shut down every night, so possible open transaction are closed (almost closed).

Database header page information:

Flags 0

Checksum 12345

Generation 15564390

Page size 16384

ODS version 11.0

Oldest transaction 15384481

Oldest active 15384482

Oldest snapshot 15384482

Next transaction 15564384

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 3

Creation date May 22, 2008 22:44:05

Attributes force write

Variable header data:

Sweep interval: 20000

*END*

In this gstat, the difference between next and oldest active is 179902. The problem now it is not if the application doesn’t commit, but the application leaves the transaction for very long time opened. Can this “bad” handle produce this gap of the 179902 units?



My question with other words: We have a transaction opened for 24 hours, this transaction was opened just for read data (not write) what problem can produce? If the transaction will be closed after the 24 hours, can this long period produce “gap”?

I am just asking to figure out where from the problem could come.



Best regards

Dennis



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