Subject Re: Performance when deleting a lot of records, again
Author cosamektoo
I probalbly have a transaction that remained open.
I'm having trubble finding it though.
Do you have any ideas how to approach this problem ?
I found all the places at the code that calls setAutoCommit and it
looks fine. I also worked with a db after backup/restoring and it is
not reproduced(next transaction= 1+snapshot transaction).
So its a specific transaction that I need to trace.
Any suggestions ?
--- In, Daniel Rail <daniel@a...>
> Hi,
> At April 7, 2005, 05:14, cosamektoo wrote:
> > Hi
> > I've assumed your answer is for my question because of the
> > so thanks.
> > I've added the file gstat.txt to FILES.I see that t tables have
> > max_versions value :
> > One 'DEVICE_FREE_SPACE' - 1455 and STATUS_KEEPER : 103420.(This
> > contains only one record all the time with un integer value).
> > I've checked the transactions on those tables and they all commit
> > immediately.
> > Any Ideas how to proceed ?
> Are you using a hard commit or commit retaining?
> Because according to your stats, there's 908,214 transactions that
> have a big chance of not being garbage collected. Although you have
> sweep interval set to 2,000 transactions, it doesn't guarantee that
> the sweep will be performed, because the garbage collection thread
> a lower priority than the other threads. So if the data manipulation
> is fairly constant, the garbage collection might not have a chance
> advance.
> Also, is it possible that you have a transaction that might remain
> open? I.e.: A simple read-only select, using a read-write
> on DEVICE_FREE_SPACE and/or STATUS_KEEPER, either in that
> or another application.
> --
> Best regards,
> Daniel Rail
> Senior Software Developer
> ACCRA Consultants Inc. (
> ACCRA Med Software Inc. (