Subject Re: Update take hours to delete records :(
Author nathanelrick
Thanks svein,

this is the database statistics

Flags 0
Checksum 12345
Generation 24702533
Page size 8192
ODS version 11.2
Oldest transaction 24694658
Oldest active 24694659
Oldest snapshot 24694659
Next transaction 24694665
Bumped transaction 1
Sequence number 0
Next attachment ID 7867
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Feb 17, 2012 6:37:00
Attributes force write

Variable header data:
*END*


it's look's like ok :(
average is 30 simultaneous connections working ...
database size is 12 go

the database contain only 2 tables :

CREATE TABLE SESSION
(
ID CHAR(16) CHARACTER SET OCTETS NOT NULL,
Expiry_date TIMESTAMP NOT NULL,
data VARCHAR(1024),
PRIMARY KEY (ID)
);

CREATE TABLE TMPD
(
ID CHAR(20) CHARACTER SET OCTETS NOT NULL,
Expiry_date TIMESTAMP NOT NULL,
data BLOB SUB_TYPE 0 SEGMENT SIZE 4096,
PRIMARY KEY (ID)
);




--- In firebird-support@yahoogroups.com, Svein Erling Tysvær <svein.erling.tysvaer@...> wrote:
>
> >> How many records approx.?
>
> >ok, the select count(*) return ... 4 300 000 record (for last 3 days)
>
> What are the statistics of that database? I just counted 3.6 million records in 1 min 18 seconds (albeit that table contains 50 years of history, not 3 days, so the system isn't anywhere as busy as yours), so more than an hour to count 4.3 million records sounds like a bit longer than I would expect. One reason can be if there is a big gap between oldest active transaction (or it could be oldest interesting transaction, I always mix these up) and next transaction, if so, you have might have a transaction problem (Firebird can contain several versions of the same record, each version potentially visible to different transactions and discovering which version (if any) is visible to your transaction can be time consuming). With a system like yours that inserts 1000 records per minute (presumably only a few records per transaction) and also do some updating, it is important to ascertain that no transaction lasts too long.
>
> Svein Erling
>