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

Similar Messages

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.

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

Can UNDO tablespace be locally managed?

I read in the Oracle 9i Administrators guide that the SYSTEM tablespace can ONLY be dictionary managed. You do not have the option of having it locally managed. Is this the same for the UNDO tablespace? I couldn't find it anywhere in the Admin guide, one way or the other.
Michael

UNDO_TABLESPACE
Parameter type
String
Syntax
UNDO_TABLESPACE = undoname
Default value
The first available undo tablespace in the database.
Parameter class
Dynamic: ALTER SYSTEM
Range of values
Legal name of an existing undo tablespace
Real Application Clusters
Multiple instances can have different values.
UNDO_TABLESPACE specifies the undo tablespace to be used when an instance starts up. If this parameter is specified when the instance is in manual undo management mode, an error will occur and startup will fail.
If the UNDO_TABLESPACE parameter is omitted, the first available undo tablespace in the database is chosen. If no undo tablespace is available, the instance will start without an undo tablespace. In such cases, user transactions will be executed using the SYSTEM rollback segment. You should avoid running in this mode under normal circumstances.
You can replace an undo tablespace with another undo tablespace while the instance is running.
See Also:
Oracle9i SQL Reference.
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch1218.htm#REFRN10227
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/toc.htm
Joel P�rez

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

Shrinking a Locally Managed Temporary Tablespace

So, even thoguh the documentation is pretty clear about how to use this feature, I cannot get it to do what I expect it to do for me.
And that would be shrinking the tempfile ;)
Now lets face it, I have a large tempfile and want to resize it without restarting the database:
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Di Nov 20 05:49:59 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
SQL> select file_name
, ceil(bytes / 1024 / 1024) "size MB"
from dba_temp_files
FILE_NAME size MB
R:\MXVC01\TEMP01.DBF 31,231
SQL> select su.username
, ses.sid
, ses.serial#
, su.tablespace
, ceil((su.blocks * dt.block_size) / 1048576) MB
from v$sort_usage su
, dba_tablespaces dt
, v$session ses
where su.tablespace = dt.tablespace_name
and su.session_addr = ses.saddr
USERNAME SID SERIAL# TABLESPACE MB
VPXADMIN 15 15 TEMP 14
VPXADMIN 17 5 TEMP 1,203
VPXADMIN 17 5 TEMP 1
VPXADMIN 18 3 TEMP 7
VPXADMIN 19 3 TEMP 1
VPXADMIN 144 3 TEMP 1
VUMADMIN 156 2597 TEMP 1
7 rows selected.
Or this one:
SQL> select tablespace_size/1024/1024 "tablespace_size mb"
, allocated_space/1024/1024 "allocated_space mb"
, free_space/1024/1024 "free_space mb"
from dba_temp_free_space
tablespace_size mb allocated_space mb free_space mb
31230,9922 1228,99219 30002
Documetation from here: http://docs.oracle.com/cd/E11882_01/server.112/e25494/tspaces007.htm#ADMIN12353
+"Shrinking a Locally Managed Temporary Tablespace+
+Large sort operations performed by the database may result in a temporary tablespace growing and occupying a considerable amount of disk space. After the sort operation completes, the extra space is not released; it is just marked as free and available for reuse. Therefore, a single large sort operation might result in a large amount of allocated temporary space that remains unused after the sort operation is complete. For this reason, the database enables you to shrink locally managed temporary tablespaces and release unused space.+
+You use the SHRINK SPACE clause of the ALTER TABLESPACE statement to shrink a temporary tablespace, or the SHRINK TEMPFILE clause of the ALTER TABLESPACE statement to shrink a specific tempfile of a temporary tablespace. Shrinking frees as much space as possible while maintaining the other attributes of the tablespace or tempfile. The optional KEEP clause defines a minimum size for the tablespace or tempfile.+
+Shrinking is an online operation, which means that user sessions can continue to allocate sort extents if needed, and already-running queries are not affected.+
+The following example shrinks the locally managed temporary tablespace lmtmp1 to a size of 20M.+
+ALTER TABLESPACE lmtemp1 SHRINK SPACE KEEP 20M;+
+The following example shrinks the tempfile lmtemp02.dbf of the locally managed temporary tablespace lmtmp2. Because the KEEP clause is omitted, the database attempts to shrink the tempfile to the minimum possible size.+
+ALTER TABLESPACE lmtemp2 SHRINK TEMPFILE '/u02/oracle/data/lmtemp02.dbf';"+
OK, lets do it:
SQL> alter tablespace temp shrink tempfile 'R:\MXVC01\TEMP01.DBF';
alter tablespace temp shrink tempfile 'R:\MXVC01\TEMP01.DBF'
ERROR at line 1:
ORA-03214: File Size specified is smaller than minimum required
It seems there is a bug? Should I report it, or is it the expected behaviour?
Now lets try this one:
SQL> alter tablespace temp shrink tempfile 'R:\MXVC01\TEMP01.DBF' keep 2048M;
Tablespace altered.
SQL> select file_name
, ceil(bytes / 1024 / 1024) "size MB"
from dba_temp_files
FILE_NAME size MB
R:\MXVC01\TEMP01.DBF 31,231
So .... this lasts about *10 minutes*, and nothing changes?
It seems there is a bug? Should I report it, or is it the expected behaviour?
Could someone enlighten me, what this SHRINK is actually doing?
Is it worth to report this as bug, if not a software bug it is at least a documentation bug because it doesn't mention under which conditions it is working?
P.S.: OMG the posting looks terrible, who's the one to blame for this forum software where it is not possible to use fixed size fonts, or format paragraphs as code, or what about the fact that the forum software is using default SQLPlus output as META for some graphical lines?
Isn't this the forum for Oracle Database users?
Edited by: Gerrit Haase on 20.11.2012 13:44

So, you are kidding with me? No? Who are you?
How can I block users here? Is there a moderator present at this forum?
Maybe you read my initial post again?
I didn't look at the wrong place.
I reported you for general abuse.
SQL> define
DEFINE _DATE           = "20.11.12" (CHAR)
DEFINE CONNECTIDENTIFIER = "MXVC01" (CHAR)
DEFINE _USER           = "SYS" (CHAR)
DEFINE _PRIVILEGE      = "AS SYSDBA" (CHAR)
DEFINE SQLPLUSRELEASE = "1102000200" (CHAR)
DEFINE _EDITOR         = "Notepad" (CHAR)
DEFINE OVERSION = "Oracle Database 11g Release 11.2.0.2.0 - 64bit Production" (CHAR)
DEFINE ORELEASE = "1102000200" (CHAR)
SQL> SELECT * FROM dba_temp_free_space;
TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE FREE_SPACE
TEMP 3,2748E+10 1306517504 3,1443E+10
SQL> select TABLESPACE_SIZE/power(2,20), ALLOCATED_SPACE/power(2,20), FREE_SPACE/power(2,20) from dba_temp_free_space ;
TABLESPACE_SIZE/POWER(2,20) ALLOCATED_SPACE/POWER(2,20) FREE_SPACE/POWER(2,20)
31230,9922 1245,99219 29986
SQL> ALTER TABLESPACE temp SHRINK SPACE;
Tablespace altered.
SQL> select TABLESPACE_SIZE/power(2,20), ALLOCATED_SPACE/power(2,20), FREE_SPACE/power(2,20) from dba_temp_free_space ;
TABLESPACE_SIZE/POWER(2,20) ALLOCATED_SPACE/POWER(2,20) FREE_SPACE/POWER(2,20)
31230,9922 1244,99219 *29986*
R:\mxvc01>dir temp
Volume in drive R is Disk_R
Volume Serial Number is 248B-61D4
Directory of R:\mxvc01
20.11.2012 08:09 32.748.077.056 TEMP01.DBF
1 File(s) 32.748.077.056 bytes
0 Dir(s) 8.259.297.280 bytes free
SQL> alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF';
alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF'
ERROR at line 1:
ORA-03214: File Size specified is smaller than minimum required
*It clearly says that there is 29986 MB Space FREE and the above shrink space changes nothing and so does shrink tempfile:*
SQL> alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF';
alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF'
ERROR at line 1:
ORA-03214: File Size specified is smaller than minimum required
SQL> alter tablespace temp shrink tempfile 'R:\mxvc01\TEMP01.DBF' KEEP 20M;
Tablespace altered.
R:\mxvc01>dir temp
Volume in drive R is Disk_R
Volume Serial Number is 248B-61D4
Directory of R:\mxvc01
20.11.2012 08:24 32.748.077.056 TEMP01.DBF
1 File(s) 32.748.077.056 bytes
0 Dir(s) 8.259.280.896 bytes free
*... nothing changes, the tempfile isn't smaller now ...*

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.

Diff betwwen dictionary and locally managed

hai
plz explain me abt diff betwwen dictionary and locally managed

Hi,
Its some of themost hot topics over the internet.Please read the manuals given by Adith they would explain the things.
For starting,
DMT
In the old versions,whenever Oracle usedto allocate space for a datafile and later on, uses that space,it used to maintain the information in some data dictionary tables(hence the name Dictionary managed).This used to create a huge amount of performance impact as for each space operation,there was a check on the data dictionary tables whether the space is there or not?This also used to lead lots of extra undo/redo getting generated because the tables in teh dictionary has to be updated.This wsa a setback.
LMT
Oracle changed the mechanism.Now the same informaiton is maintained with the Datafile header.There is no dependency on the dictionary and hence its more faser.As well this wont generate the extra undo/redo so it will always begood.This is achieved by tracking the space by bits in a seperate segment called bitmap segment.
Well I guess that should be enough,more and much more detail in the docs.So please read them.
Aman....

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 >

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

Explain local manage tablespace and dictionary manage tablespace

Similar Messages

Maybe you are looking for