Subject | RE: [firebird-support] slow database ref/eDN8022297953 |
---|---|
Author | dennis |
Post date | 2008-06-17T14:03:13Z |
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]
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]