Re: ASSM bug: slow INSERT after uncomitted DELETE
Date: Sun, 9 Aug 2009 11:09:59 -0700 (PDT)
Message-ID: <3f2a40f2-95d9-4746-8a07-571742da2d1c_at_33g2000vbe.googlegroups.com>
On Aug 8, 1:55 pm, Charles Hooper <hooperc2..._at_yahoo.com> wrote:
snip
> > Charles I got a little lost trying to follow your reply ... sorry.
>
> > Wonder if I either screwed something up ( I don't think so ... was
> > careful to check tablespace was ASSM and that inserts were in
> > different sessions ) or if there is something fixed in 11.1.0.7 in
> > linux 64 bit that still has problems on other platforms and/or if the
> > fact that my setup is using ASM is also throwing a wrinkle into
> > things?
>
> > Noons seemed to report that he did not see the same problem either but
> > I think that was before the complete test case was posted.
>
> I was not implying that you made a mistake in your test run, I just
> saw a couple potential problems with the original test case
> description which might cause someone (including myself) to conduct
> the test a little different than the OP. That might include:
> * Batching the inserts in the second session, rather than using 1,000
> individual SQL statements for the insert.
> * Creating the tablespace with the wrong specifications (that happened
> to me when I initially tried to set up the tablespace with the 1MB non-
> ASSM tablespace - I actually created an ASSM tablespace with 1MB
> uniform extents which resulted in roughly the same slow timing as the
> ASSM autoallocate tablespace).
> * A 10046 trace at level 8 was not set up in the original test case,
> which would make it hard to determine where the time was spent.
Well as it turns out I had messed up the testing and after doing it a little/lot more carefully my run showed the same problem as noted by the OP.
It was a pretty well written test case I just missed the part for step 4 where you had to run the select first to generate the insert statements. Received on Sun Aug 09 2009 - 13:09:59 CDT