RE: ALLOCATION_TYPE USER or SYSTEM for a Locally Managed Tablespace ?

From: VIVEK_SHARMA <VIVEK_SHARMA_at_infosys.com>
Date: Mon, 23 Sep 2002 15:13:28 -0800
Message-ID: <F001.004D7487.20020923151328@fatcity.com>

Missed your Point Can u explain ?

NO MIN_EXTENTS Set at Tablespace OR Object Level when migrating from Dict to LMT

Does Excessive Fragmentaion of Objects in Locally Managed Tablesspaces have a Performance Overhead OR does it have only a Space overhead ?

Thanks

-----Original Message-----
Sent: Tuesday, September 24, 2002 1:33 AM To: Multiple recipients of list ORACLE-L Tablespace ?

Even though you "control" the extents with USER, the underlying concept is still usage of bits (typically 5 x blocksize, unless you already had MINIMUM EXTENT set on the tspace before migration from dict=>lmt).

Thus, probably (assuming you don't want to use uniform), an auto-allocate policy is best to limit the possible "damage" from fragmenation (ie lost space)

hth
connor

VIVEK_SHARMA <VIVEK_SHARMA_at_infosys.com> wrote: >
> Qs In sys.dba_tablespaces , Which is Better ,
> ALLOCATION_TYPE USER OR SYSTEM with
> EXTENT_MANAGEMENT being LOCAL for Both Cases ?
>
> For Objects Existing in Locally managed Tablespaces
> having ALLOCATION_TYPE SYSTEM , NEXT_EXTENT has NO
> Value But EXTENTS has Values .
>
> Qs Can Large Numbers of Extents in a Locally
> Managed Tablespace Cause a Performance Overhead ?
>
> We Convert the ALLOCATION_TYPE from SYTEM to USER to
> Allow us to Control the NEXT_EXTENT Size Manually
>
> This is Done by Running the Following 2 Commands on
> the respective Locally managed Tablespace
> execute
>
dbms_space_admin.tablespace_migrate_from_local('TBLSPC1');
> execute
>
dbms_space_admin.tablespace_migrate_to_local('TBLSPC1');
>
> Thanks
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: VIVEK_SHARMA
> INET: VIVEK_SHARMA_at_infosys.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).

Connor McDonald
http://www.oracledba.co.uk
http://www.oaktable.net

"Remember amateurs built the ark - Professionals built the Titanic"

Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: =?iso-8859-1?q?Connor=20McDonald?=
  INET: hamcdc_at_yahoo.co.uk

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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: VIVEK_SHARMA
  INET: VIVEK_SHARMA_at_infosys.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).

Received on Mon Sep 23 2002 - 18:13:28 CDT