Downsides to Locally Managed Tablespaces?

I am creating a database from scratch and am looking at locally managed tablespaces.
Are there any downsides to locally managed tablespaces?
I understand that if the SYSTEM tablespace is locally managed, then all other tablespaces need to be locally managed. Are there any cons to this?

<quote source="AskTom.oracle.com">
Locally managed tablespaces are much faster at allocating and de-allocating
extents - many order of magnitudes faster.
locally managed tablespaces decrease contention on the data dictionary.
There is nothing bad about them, only good things.
</quote>
http://asktom.oracle.com/pls/ask/f?p=4950:8:720407411417074486::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:409670433426

Similar Messages

Create table with storage parameters in a locally managed tablespace

Hi,
Can we create object with storage parameters in a locally managed tablespace.
CREATE TABLE my_hash_table_6 (
name VARCHAR2(30),
value VARCHAR2(4000) )
STORAGE (
INITIAL 1M
NEXT 512K
PCTINCREASE 0
MINEXTENTS 2
MAXEXTENTS UNLIMITED )
users default tablespace is locallly managed.
Then this table's extent management will be managed as per the tablespace or as the storage parameters which
were specified at the time of table creation.

Why don't you try it yourself ?
TEST@db102 > select * from dba_tablespaces
2 where TABLESPACE_NAME='USERS';
TABLESPACE_NAME                BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS
MAX_EXTENTS PCT_INCREASE MIN_EXTLEN STATUS    CONTENTS LOGGING   FOR EXTENT_MAN
ALLOCATIO PLU SEGMEN DEF_TAB_ RETENTION   BIG
USERS                                8192          65536                       1
2147483645                   65536 ONLINE    PERMANENT LOGGING   NO LOCAL
SYSTEM    NO AUTO   DISABLED NOT APPLY   NO
TEST@db102 > CREATE TABLE my_hash_table_6 (
2 name VARCHAR2(30),
3 value VARCHAR2(4000) )
4 STORAGE (
5 INITIAL 1M
6 NEXT 512K
7 PCTINCREASE 0
8 MINEXTENTS 2
9* MAXEXTENTS UNLIMITED )
TEST@db102 > /
Table created.
TEST@db102 > select * from user_segments
2 where segment_name='MY_HASH_TABLE_6';
SEGMENT_NAME
PARTITION_NAME                 SEGMENT_TYPE       TABLESPACE_NAME
     BYTES     BLOCKS    EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS
MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS BUFFER_
MY_HASH_TABLE_6
                               TABLE              USERS
   2097152        256          2        1572864                       1
2147483645                                         DEFAULT
TEST@db102 >

Default storage for locally managed tablespaces

the documentation says you cannot have a default storage parameter for locally managed tablespaces. Does this mean that we cannot specify
INITIAL
NEXT
PCTINCREASE
MINEXTENTS
MAXEXTENTS for such tablespaces, or is there another way we can, without using default storage?
thanks

I amnot sure where you read that part that the default storage clause can't be given.Please see here,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#sthref1149
From the doc,
Creating a Locally Managed Tablespace
If the CREATE TABLESPACE statement includes a DEFAULT storage clause, then the database considers the following:
If you specified the MINIMUM EXTENT clause, the database evaluates whether the values of MINIMUM EXTENT, INITIAL, and NEXT are equal and the value of PCTINCREASE is 0. If so, the database creates a locally managed uniform tablespace with extent size = INITIAL. If the MINIMUM EXTENT, INITIAL, and NEXT parameters are not equal, or if PCTINCREASE is not 0, the database ignores any extent storage parameters you may specify and creates a locally managed, autoallocated tablespace.
If you did not specify MINIMUM EXTENT clause, the database evaluates only whether the storage values of INITIAL and NEXT are equal and PCTINCREASE is 0. If so, the tablespace is locally managed and uniform. Otherwise, the tablespace is locally managed and autoallocated.
HTH
Aman....

Locally Managed tablespaces?

Into the Design Editor, Admin tab: How can I define a tablespace as Locally Managed?

Harvinder,
Locally managed tablespaces are part of the new features of Oracle 8i. the advantages
are when they database objects need to allocate space, they need not go through the
data dictionary, they can find the free space
through bitmaps in the datafile, hence the name locally managed tablespaces.
this improves performance because recursive sql (update/insert/select of data dictionary tables) is avoided.
temporary tablespaces are prime candidates for locally managed tablespaces.
yes the whole database can be created with locally managed tablespaces..but with some restrictions. see oracle documentation for further details.
Mukundan.

Bitmap indexes to track extents in locally managed tablespaces

does any body have any idea that how oracle tracks free and used extents with bitmap indexes in locally managed tablespaces ?
please reply

There are no bitmap indexes, there is a 64k tablespace header block containing the bitmap of occupied and free extents.
Sybrand Bakker
Senior Oracle DBA

Rollback segment in locally manage tablespace

Is it possible to create rollback segment in
locally manage tablespace in oracle 8i(8.1.6)
kuljeet pal singh

Srini,
Both the 10gR2 and 11gR2 versions of the database are using automatic undo management.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> show parameter undo
NAME TYPE VALUE
_undo_autotune boolean TRUE
undo_management string AUTO
undo_retention integer 14400
undo_tablespace string UNDOTBS1
SQL>
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 14400
undo_tablespace string UNDOTBS1
SQL>
Do you know anything about Oracle no longer automatically creating R0 in 11gR2?
Thanks,
Bill

Locally managed tablespaces in Apps 11.0.3

Hi,
we are on Oracle Apps 11.0.3. we recently upgraded the database to 8i ( 8.1.7.4 ). I would like to change some high activity tablespaces to locally managed tablespaces to improve performance. Are there any issues in doing this ? Can I benefit from this or will I have any issues.
thanks
Ram

We moved all the tablespaces to locally managed. Although we convereted the tablespaces to locally managed, occassionally we would see some of the ddl commands hang, cause being system still trying to update fet$ and uet$ tables. We were able to fix this by creating new locally managed tablespaces and move the contents to new locally managed tablespaces.

Explain local manage tablespace and dictionary manage tablespace

hi all,
kindly help me to understand local manage and dictionary manage tablespace
i have read search result and oracle corporation book still unable to understand
what i know that local is managed by bitmap(no redo) and dictionary is managed by dictionary(generates redo) plz explain this as well
and also suggest me some documentation.
thanks
Navin

Navin,
These are excerpts from Oracle documentation
Dictionary Managed Tablespace_
If you created your database with an earlier version of Oracle, then you could be using dictionary managed tablespaces. For a tablespace that uses the data dictionary to manage its extents, Oracle updates the appropriate tables in the data dictionary whenever an extent is allocated or freed for reuse. Oracle also stores rollback information about each update of the dictionary tables. Because dictionary tables and rollback segments are part of the database, the space that they occupy is subject to the same space management operations as all other data.
Lcaolly Managed Tablesapce_
A tablespace that manages its own extents maintains a bitmap in each datafile to keep track of the free or used status of blocks in that datafile. Each bit in the bitmap corresponds to a block or a group of blocks. When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status of the blocks. These changes do not generate rollback information because they do not update tables in the data dictionary (except for special cases such as tablespace quota information).
Locally managed tablespaces have the following advantages over dictionary managed tablespaces:
Local management of extents automatically tracks adjacent free space, eliminating the need to coalesce free extents.
Local management of extents avoids recursive space management operations. Such recursive operations can occur in dictionary managed tablespaces if consuming or releasing space in an extent results in another operation that consumes or releases space in a data dictionary table or rollback segment.
The sizes of extents that are managed locally can be determined automatically by the system. Alternatively, all extents can have the same size in a locally managed tablespace and override object storage options.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#sthref518
Regards

Portal, Tablespace defragmentation and Locally Managed tablespaces

We are setting up a Big portal installation. We want to use seperate small, medium and large tablespaces for data, lobs and index as described in the de-fragmention start living white paper. We will also use locally managed tablespaces.
Has anybody set-up a portal installation like this. What where the large and medium data, index and lob segments ?
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by David Stoller ():
Anyone try using IFS in a Locally Managed Tablespace? Is it OK?<HR></BLOCKQUOTE>
Yes, we have all tablespaces managed locally. No problems with that.

ORA-03264: cannot drop offline datafile of locally managed tablespace

Hi list
A datafile was acidentally created on filesystem in one node of two nodes RAC.
After that the filesystem on which the datafile was created was out of space because of automatic control file backup and sysadmin move this datafile to another device. And before this action RMAN backup stopped work.
Now we replace the datafile to the original location, but it stay offline and recover status, and we cant bring them online because the customer dont have necessary archive logs to recover this datafile. RMAN backup is now working. But now we need to create a DataGuard on a third server and want to drop this datafile.
This datafile dont have any data segment and stay in most critical tablespace of the customer application which have more datafiles. This datafile in question isnt the first datafile of the tablespace.
SQL> select file#, status from v$datafile where name='/oracle/product/db/ars/dbs/arsystem.old';
FILE# STATUS
21 RECOVER
SQL> select file#, status from v$datafile_header where name='/oracle/product/db/ars/dbs/arsystem.old';
FILE# STATUS
21 OFFLINE
How can I drop this datafile?
Thanks
Cristiano

Review this metalink note, what to do:
How to 'DROP' a Datafile from a Tablespace
Doc ID:111316.1
If you cannot recover the datafile, you have to export the 'rest' of the tablespace (after statement 'alter database datafile '/oracle/product/db/ars/dbs/arsystem.old' offline drop;' was successfully issued). Afterwards drop the tablespace,recreate it and import the data).
Werner

Convert a tablespace to local managed

Is it possible to have a local managed tablespace and convert it to dictionary managed?

Really I have not seen that posibility directly with a command but you could check the ALTER TABLESPACE command but remember that you could do this:
1.- Create a tablespace dictionary managed if the system tablespace is not locally managed
2.- Move all tables and indexes to that tablespace found in the another tablespace.
Joel Pérez
http://otn.oracle.com/experts

Local Management of Tablespace - Help

We are using oracle 8i std edition on solaris. We want to create a locally
managed tablespace for a particular schema. The objects of this schema
will be imported every day from the same schema on another same database server.
The existing schema tablespace is locally managed with system allocation type.
1.We want to know what are the points to be kept in mind while creating a locally
managed tablespace in the new db.
2. Should the tablespace have a single datafile or more than one(The existing one has
3 datafiles)? Which one is better? (There will be no activity on this new db as it is
for standby only. If the existing one fails, this db will be used.
4. Since we are going to export from the existing one and import into the new db schema
every day ( the schema in the new db will be dropped and recreated daily before import),
will there be any problems that we will encounter by doing so?
Please let me know all the information so that we do not face any problem after
implementing this.
Note: Currently the failover schema tablespace is dictionary managed and we plan to
entirely drop this tablespace and create a new one by the same name but locally managed
this time. So what steps to be taken while dropping the tablespace and creating a new one
by the same name? Will there be any problems because of this? Is a db restart required
after this? Kindly enlist the points and steps.
We appreciate your immediate help.

93469, to answer some of your questions:
1- You need to determine if the new tablespace should be locally managed using uniform extents or autoallocate. The answer should probably be based on how much variation exists between the current object sizes (used allocation). If you have a lot of very small tables and a few large one then autoallocate may be a better choice that uniform extents.
2- Why use three files if one will do? You should have a file management policy about file sizes and allocations so you should follow it.
3- The best way to answer this question is to try the import and find out. There are some imp/exp bugs in 8.1 but since your tablespace names will match you will avoid the only one that comes to mind. Tables with LOB objects imported into a db where the target tablespace does not exist so that the table defaults to the owner default tablespace will fair if the LOB segment tablespace points to a non-existing tablespace since Oracle development failed to default it also. But if you do not have LOB segments this is not an issue. Come to think of it I do not think you can import a table with a LOB table into an autoallocate tablespace in version 8.1.
HTH -- Mark D Powell --

Convert from dictionary to local managed?

Hi all,
Good day!
when we convert from dictionary to local managed is it dependant on CPU or no of extent?
Thanks in advance
Elina

How are you converting the tablespaces? 8 hours seems excessive if you are using dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL , I have seen situations where creating new locally managed tablespaces and moving the objects accross takes a long time as the old extnets are deallocated from the UET$ table and added to FET$. in these cases the speed of an individual CPU core is the limiting factor as SMON handles the deallocation of extents.
If this is the case then migratig the tablespace to locally managed using dbms_space_admin then migrating to a new tablespace may be faster, if not then can you post what method you are uing to migrate and the version of the database
Chris

Storage clause for locally manged tablespace with unifom size extents

in oracle 9i PERSONAL EDITION
I HAVE CREATED A TABLESPACE TEST1 AS LOCALLY MANAGED WITH UNIFORM SIZE AS 256K.MY DB_BLOCK_SIZE IS 4K
I HAVE CREATED A TABLE XYX IN THE TEST1 TABLESPACE WITH THE STORAGE (INITIAL 52K NEXT 52K)
WHEN I QUERIED THE DBA_EXTENTS IT SHOWS THE INITAIL EXTENT AS 256 K
BUT WHEN I QUERIED THE DBA_SEGMENTS IT SHOWS THE INITAL_EXTENT AS 52K.
IS THEIR ANY SIGNIFICANCE OF SPECIFYING THE STORAGE CLAUSE IN LOCALLY MANAGED TABLESPACES.

take a example what is effect of set storage parameter in table whoes tablespace is locally manager and have uniform size
i have a tablespace whoes
[b]uniform size is 32k
but when i create a table then i set initial 128k
now when table is create it create 4 extent
of 32 each(32*4=128)
because tablespace uniform size is 32
if we give intial 256 then it create
8 extent(32*8=256)
like
create tablespace tt_check
datafile 'E:\ORACLE\SAFE_DATA\tt_check.dbf' size 10m
extent management local uniform size 32k;
create table tt_1
(no number)
tablespace tt_check
storage(initial 128k
next 128k);
1* select extent_id,segment_name,tablespace_name,bytes from dba_extents where segment_name='TT_1'
QL> /
EXTENT_ID SEGMENT_NAME TABLESPACE_NAME BYTES
0 TT_1 TT_CHECK 32768
1 TT_1 TT_CHECK 32768
2 TT_1 TT_CHECK 32768
3 TT_1 TT_CHECK 32768
hope it will help you
kuljeet pal singh

How to change the dictionary-managed taclespaces to locally managed

Hi,
how to change the dictionary-managed taclespaces to locally managed tablespaces in 9i?
Many thanks.

Hi
execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL ('TABLESPACE_NAME');

Downsides to Locally Managed Tablespaces?

Similar Messages

Maybe you are looking for