| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Next extent with Locally managed tablespace on 9i
Evening Norman,
The assumption with all this of course is the 500ish extent limit. There is still some debate regarding what an appropriate limit really is with regard to LMT. All the Oracle doco discusses having many 1,000s of extents with no performance impact. Previous discussions with Jonathan Lewis has raised the possibility of some issues with huge extent numbers (tablespace quotas being one) but the logical extension of all this is that extent numbers won't matter (if not now then in the future).
I think the 500ish figure goes back to DMT and the extent map issue being a logical limit. Extents maps are still there but how much of a measurable performance hit is having numerous extent maps.
Assuming number of extents don't matter then it suggests that the uniform size could be set to a low figure (say 64K) and be done with it. No need to separate objects based on extents sizes. I think Temp tablespaces are different and deserving of their own uniform size but they live in their own tablespace anyway.
I guess we need a huge production database with heavy load to test this all out. Any volunteers :)
Richard
Norman Dunbar wrote:
Morning Nuno,Well, I did say 'it depends' :o) (That's my CYA !)
More comments embedded .....
Cheers,
Norman.-------------------------------------
Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:Norman.Dunbar@LFS.co.uk
Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
------------------------------------------Original Message-----
From: Nuno Souto [mailto:nsouto@optushome.com.au.nospam]
Posted At: Friday, August 02, 2002 4:41 PM
Posted To: server
Conversation: Next extent with Locally managed tablespace on 9i
Subject: Re: Next extent with Locally managed tablespace on 9i>> Hmmm, what about other considerations?
>> Like:
>> Should we make these somewhat dependent on things like
sort_area_size?
>> What about DFMBR? Should we make these uniform chunks match that
size or
>> multiples of it?More than likeley we should - I haven't been able to experiment yet -
too busy with new servers.>> > 1 MB : Objects up to 500MB.
>> Nope, don't like it. Too "nice". I go straight for 10Mb as the next>> one.
Tru, why not - I said it depends. We have a number of tables that are
too small for a 10 MB tablespace but too big for 64KB - assuming the 500
extent limit. The users fear that too much space is wasted, but then
again, I could leave it in the 64KB tablespace and just have more than
my threshold number of extents. (I am talking theory here - our main app
HAS to have its tables in one of 5 tablespaces and the names are
hardcoded into the scripts - unfortunately.)>> Yikes! Nope, no way. Too large. If you have objects THAT large,
think
>> partitioning. It's the best way to handle these monsters (with
current
>> technology!): divide to conquer.True, but some things might not partition very easily.
As you say, it is an interseting subject and will no doubt throw up some
conflicting advice :o)Norm.
 |
 |