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 [email protected], 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
>


Reply via email to