Re: LMT- Migrated tablespaces

The paper by Juan Loaiza ("How to stop ... and start...") is not really relevant or useful for LMT's. The 160 thing should really have been 128, but was rounded due to the allocation algorithm. With LMTs that algorithm is not a problem anymore, so more "sensible" extent sizes should be used.

Also, the whole thing with many extents, etc. was an issue when dropping DMTs, but nothing else. And it's completely gone with LMTs. One of my guys - Johannes Djernes - ran a test where he first created a 60.000 extents table and dropped it (took about 2 seconds), then a 180.000 extents table and dropped it (took about 6-7 seconds).

It's of course all a matter of opinion, but I like the LMTs with a uniform extent size. And then I don't much care what extent size it is, but it would typically be a factor of 64. The auto allocate stuff doesn't appeal to me, I must confess. I like the same extent size all over.

Mogens

Browett, Darren wrote:

>I have crossposted this question on the Oracle-Apps list, I would like
>to
>get the opinion of this list as it is more of database issue as opposed
>to apps.
>
>The question is about LMT and extent management with regards to Oracle
>11i.
>
>When upgrading to 11i, it creates "migrated" LMTS as opposed to
>"uniform/system" ones, and therefore do not conform to the rules
>of "correct" LMTS.
>
>My understanding is, even though my tablespaces are LMT, the tables
>still act like they are dictionary managed with regards to extent
>growth.
>
>According to "How to stop defrag, and start living ....." for tables
>under 160M I should have an extent size of 160k.
>
>With that in mind, should I
>
>1) Create LMT Tablespaces with an extent size of 160k ? ( This is
>ignored
> by the import, tables will be one extent big)
>2) Reset the "next_extent" on my apps tables to 160k ?
>3) Set pctincrease to 0 ? ( I think this is a given )
>
>Thanks
>
>Darren
>
>
>------------------------------------------------------------------------
>--------------------------------------------------
>Darren Browett P.Eng This
>message was transmitted
>Data Administrator using
>100% recycled electrons
>Information and Communication Technology
>City of Coquitlam
>P:(604)927 - 3614
>E:dbrowett_at_city.coquitlam.bc.ca
>------------------------------------------------------------------------
>---------------------------------------------------
>
>
>
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
  INET: mln_at_miracleas.dk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).