Subject | Re: [firebird-support] Very long transaction start after deleting a big number of records. |
---|---|
Author | Thomas Steinmaurer |
Post date | 2014-07-25T13:10:49Z |
> On 25/07/2014 06:46, brucedickinson@... [firebird-support] wrote:SELECT COUNT(*) might be better because all pages are read and only a
>>
>> Hi,
>>
>> 1. I've deleted 500000 records from TABLE A. I've commited transaction.
>> 2. I made SELECT * FROM TABLE A. Transaction was starting for a very
>> long time.
>>
>> I just wanted to make sure that there is no way to prevent this
>> behaviour? I mean, I can not delay somehow clearing of this garbage?
>>
>> As far as I understand this article:
>> http://www.firebirdsql.org/manual/gfix-housekeeping.html
>>
>>
>> there is no such possibility becasue:
>>
>>
>> "Whenever a subsequent transaction reaches garbage from a /committed/
>> transaction, that garbage is automatically cleared out."
>>
> So it appears. Essentially part of the cost of doing the deletion is
> palmed off onto some later user, who is faced with unpredictable delays
> in consequence. For example an overnight housekeeping job can result in
> the first end user transaction of the day taking orders of magnitude
> longer than usual (and timing out and crashing, if its timeouts are set
> to something reasonable).
>
> You can avoid this cost being passed onto the poor user who through no
> fault of his own is the first to follow the housekeeping by including
> the "SELECT * FROM TABLEA" as part of the cleanup job, thus putting the
> cost back with its owner. In other words you can't delay the garbage
> collection, but you can make it happen earlier so that it's predictable.
single value is transferred to the client. And the whole only works as
advertised when old record versions are no longer "interesting" to other
concurrent transactions.
--
With regards,
Thomas Steinmaurer
http://www.upscene.com/
Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.