Comments Inline.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
____Denmark__May 21-23rd
____Sweden___June
____Finland__September
____Norway___September
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK_(Manchester)_May x 2
____Estonia___June 4th - 6th
____Australia_June 18th - 20th (Perth)
____Australia_June 23rd - 25th (t.b.a)
____USA_(CA, TX)_August
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"Richard Foote" <richard.foote_at_bigpond.com> wrote in message
news:yrKwa.34788$1s1.505960_at_newsfeeds.bigpond.com...
>
> I agree that hot bitmap blocks could be an issue but consider when
they get
> accessed. During a FTS, they of course all need to be accessed. If
however
> the frequency of the FTS and the associated number of cached bitmap
blocks
> is an issue, then such a table would make a good candidate for the
recycle
> pool to reduce "cache damage" (my term !!).
>
Personally I don't really see them as being an issue
on FTS. I'd expect to take the view that if the table
is small, then the total cost is small. if the table is
large then the BMB is not the significant part of the
work.
> The other times bitmap blocks are accessed are during insertions.
But
> generally speaking, it's only a limited number of the bitmap blocks
that are
> ever "hot" at a point in time (as the root bitmap block ignores
"full"
> bitmap blocks). So again, the damage is naturally reduced.
>
This is the spot where I would be worried for a busy system -
I still have to do some realistic stress tests.
>
> I agree. I think tkprof purchased the same "timing device" as I did
once in
> Hong Kong many years ago ;)
I bought one of those once - I think they only work
in Hong Kong. They're unbreakable, but only for
the first ten minutes.
>
>
They "waste"
> space, they cause additional LIOs, they require additional
processing and
> consume additional memory. All negatives I would say. But *if* these
> negatives are proportionally "small enough" to balance out the
potential
> benefits of reduced block contention, more effective usage of
storage
> (*especially* for widely variable row lengths and random delete
patterns)
> then keep me on the mailing list.
My feeling is that they are a good idea in principle, and
another of the features that Oracle is putting in to the
product that 'waste a little resource' to reduce the need
for intelligent administration. But I think there is still
'fine-tuning' that has to be done.
>
> Thanks Jonathan, all good suggestions. I've decided that my current
system
> of keeping track of experiments and test results is not coping too
well !! I
> might need a database to store them all in all. Say, there's an idea
!!
>
I just have a directory full of test scripts, and a carefully
maintained
index of what I'm testing in each script. Then there's the couple of
hundred scripts that aren't in the index, and the things I know I've
done but put in the wrong place.
>
> I might sound very much as if I'm some sort of crusader for the
rights of
> ASSM segments. I'm not, I just trying to determine what shape(s) the
damn
> things really are and try and fit them in the right holes.
>
Amen.
Here's another square hole to think about.
If the data falls into a naturally sequential pattern, and you switch
to
ASSM to avoid contention on inserts; then any index that echoed the
sequential pattern has suddenly acquired a much higher clustering
factor - which means the optimiser is less likely to use it on range-
based queries.
Received on Thu May 15 2003 - 06:37:54 CDT
