Richard Foote wrote:
> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:41b75a73$0$12876$afc38c87_at_news.optusnet.com.au...
>
>>Richard Foote wrote:
>>
>>>"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message
>>>news:1102498989.134881.223450_at_f14g2000cwb.googlegroups.com...
>>>
>>>
>>>>Howard J. Rogers wrote:
>>>>
>>>>
>>>>
>>>>>Because if you choose your uniform size poorly (ie, too small), then
>>>>
>>>>the
>>>>
>>>>
>>>>>number of extents a segment acquires will shoot up. And the ASSM
>>>>
>>>>bitmaps
>>>>
>>>>
>>>>> get more burdensome the more extents they have to manage/deal with.
>>>>
>>>>Yes, but that would be the case as well with LMT without ASSM,
>>>>wouldn't it? I mean, it uses a bitmap as well to allocate
>>>>space in uniform extents. Too small an extent, too large a bitmap,
>>>>*potential* problem. Does it get compounded with ASSM?
>>>>
>>>
>>>
>>>Hi Nuno,
>>>
>>>It's been a while since I've looked at all this in any detail and I don't
>>>have time to research my research (I've a new Pink Floyd DVD to
>>>investigate :) but to briefly answer your questions.
>>>
>>>The ASSM bitmaps reference *blocks* not extents and as such bitmaps can
>>>be stored in one block and yet reference/span a number of smaller extents
>>>or can be stored in several blocks in order to reference the blocks in
>>>one larger extent. However, the ratio of bitmap blocks to referenced
>>>blocks can be higher for smaller extents sizes although there are quite a
>>>number of ifs and buts with it all (for example results varied between
>>>uniform and autoallocate).
>>>
>>>With regard to LMT without ASSM and the *extent* management bitmaps of
>>>LMT, note that Oracle allocates a number of blocks (64Kish) in the first
>>>datafile of the tablespace regardless so providing these blocks are
>>>sufficient to map all extents in the tablespace, then extent size doesn't
>>>really matter. If however you have a massive tablespace with a smaller
>>>extent size, then Oracle may need to allocate additional bitmap blocks in
>>>the tablespace, where it's again dubious whether such an overhead is
>>>significant to really matter as well.
>>
>>"dubious"... it's not a very scientific word, is it?! "28% of my buffer
>>cache consumed by ASSM BMBs"... that's a bit more like it (I think it was
>>Jonathan that posted that once... I hope he will clarify), and would
>>qualify as significant in anyone's book, surely.
>>
>
>
> Hi Howard,
>
> Oh, I don't know, I think scientists can get away with the word "dubious":
>
> "It's worked, it's worked, my monster with the unattractive bolt through the
> neck is alive although it's dubious whether he'll find a long term, happy
> relationship" !!
LOL!
> As for your point, I think it a little dubious to question my wording on
> something (lots of extents in a non ASSM tablespace) and then refer to a
> totally different example (ASSM).
>
> Dubious indeed !!
Ah. I've just re-read that paragraph, and I apologise without question.
It's those blessed bitmap blocks... there's too many types! I saw you
saying 'more bitmaps...not significant', and thought you were referring
to more ASSM BMBs. In fact, you were talking about more LMT bitmaps. My
mis-reading, my mistake.
> As for ASSM, zzzzzzzzzzzzzzzzzzzz, been there discussed that, re-read
> through the archives on why it may not *always* be evil.
>
> BTW, is evil a scientific word ?
Guilty as charged, your honour.
'Course it's not always evil. Even my "evil" document says it isn't
always so!!
Regards
HJR
Received on Wed Dec 08 2004 - 14:34:01 CST
