Re: ASSM bug: slow INSERT after uncomitted DELETE
Date: Mon, 10 Aug 2009 20:43:43 -0700 (PDT)
Message-ID: <9d634b29-1401-411f-b1ac-e091eb257ae3_at_b25g2000prb.googlegroups.com>
On Aug 10, 4:07 pm, "Jonathan Lewis" <jonat..._at_jlcomp.demon.co.uk> wrote:
>
> This is the problem with bitmap blocks - when do you change
> their state.
>
> That's why they're not a good idea for DSS and DW activity,
> and why you should only use them with real OLTP activity -
> they work best for commits after small changes of data.
>
Actually, I think the problem is more related to the poor practice of using delete to clear an entire table. A truncate should be used, rather than a delete. And definitely a commit should be in there somewhere, rather than leaving entire table deletes uncomitted. We have all been there and seen what large uncomitted deletes do, particularly if the table is indexed. assm or no assm. As well, if you delete only a portion of the table rather than the lot, the problem doesn't show up as easily: the second session's insert proceeds at normal speed.
As such, I think it is a bit premature to blanket-classify assm as not suitable to DW/DSS because of a special case when it is perfectly suitable if normaly accepted coding practices are followed? Received on Mon Aug 10 2009 - 22:43:43 CDT