Subject | Re: Performance when deleting a lot of records, again |
---|---|
Author | cosamektoo |
Post date | 2005-04-27T07:43:28Z |
Hi and thanks
It seems to me that there is a bug in SQLAPI library.
When I dont connect the client through this library,
the numbers of next transaction and last snapshot stay close together.
The only workarround that I found is to disconnect and reconnect the
SQLAPI db connection every X minutes.I think that even though I
commit every read operation through that connection, it causes
the database to keep transactions open.
What do you think about this conclusion ?
Thanks
-gili
--- In firebird-support@yahoogroups.com, "mikcaau" <macomp@s...>
wrote:
It seems to me that there is a bug in SQLAPI library.
When I dont connect the client through this library,
the numbers of next transaction and last snapshot stay close together.
The only workarround that I found is to disconnect and reconnect the
SQLAPI db connection every X minutes.I think that even though I
commit every read operation through that connection, it causes
the database to keep transactions open.
What do you think about this conclusion ?
Thanks
-gili
--- In firebird-support@yahoogroups.com, "mikcaau" <macomp@s...>
wrote:
>active.
> Hi Gili,
> It seems that your program is still not committing transactions.
> Given that you have only one client - a reader then I would expect
> only one transaction open but you have 698 transactions still
> Each of these transactions (after the first) causes firebird tomake a
> copy of every record that has been open by the first transaction and
> that is referenced by the second transaction.
> Then the next transaction causes copies of every record ...
> Well I can see how your database grows and I can understand how it
> gets so much smaller after a restore.
>
> Mick
>
> --- In firebird-support@yahoogroups.com, "Gili Buzaglo"
> <gbuzaglo@c...> wrote:
> > Hi, remember me
> > Well after a lot of investigations, I managed to keep the next
> transaction number close to
> > the old snapshot number (at the gstat -h output).
> > I had a client running on solaris, written in c++ and using SQLAPI
> to connect to the database.
> > The output of gstat -h in this state was:
> >
> > Database header page information:
> > Flags 0
> > Checksum 12345
> > Generation 3035282
> > Page size 4096
> > ODS version 10.1
> > Oldest transaction 3034574
> > Oldest active 3034575
> > Oldest snapshot 3034288
> > Next transaction 3035273
> > Bumped transaction 1
> > Sequence number 0
> > Next attachment ID 0
> > Implementation ID 3
> > Shadow count 0
> > Page buffers 0
> > Next header page 0
> > Database dialect 3
> > Creation date Apr 20, 2005 19:19:56
> > Attributes force write
> >
> > Variable header data:
> > Sweep interval: 0
> > *END*
> >