Re: LMT- Migrated tablespaces

IIRC, a 160m table would be in an LMT with 4m extents.

The 3 extent sizes recommended in the paper are 128k, 4m and 128m.

> 1) Create LMT Tablespaces with an extent size of 160k ? ( This is
> ignored by the import, tables will be one extent big)

Not so. If you create an LMT of the correct name for imp to import a table into, it will be created with the uniform size extents you specified at tablespace creation.

By 'correct name', I mean either a tablespace of the same name as the one the table was exported from, or the owners default tablespace is an LMT, and there is not a tablespace to match the name of that in the import file.

> 2) Reset the "next_extent" on my apps tables to 160k ?
> 3) Set pctincrease to 0 ? ( I think this is a given )

Both of these are invalid on an LMT.

HTH, Jared

On Friday 27 December 2002 10:13, 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: Jared Still
  INET: jkstill_at_cybcon.com

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).