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:[EMAIL PROTECTED]
> ------------------------------------------------------------------------
> ---------------------------------------------------
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to