Shrinking Undo Table Space

Dear All,
Size of my Undo table space file has been more than 6GB. I am using Oracle 11g. How can I shrink the size of undo tablespace? Would it cause any problems for the Database?
Thanks

Dear Laura,
Its brings back following output:
SYSTEM     LOCAL
SYSAUX     LOCAL
UNDOTBS1     LOCAL
TEMP      LOCAL
USERS     LOCAL
When I try to shrink the undo tablespace I use the following command and out put message:
SQL> ALTER TABLESPACE undotbs1 SHRINK SPACE KEEP 1000M;
ALTER TABLESPACE undotbs1 SHRINK SPACE KEEP 1000M
ERROR at line 1:
ORA-12916: cannot shrink permanent or dictionary managed tablespace

Similar Messages

UNDO Table space management

Dear All,
My client Export/Import Process failed while Importing at quality server. Production Server Export process completed successfully.
It looks like your UNDO tablespace is too small to handle a large volume transaction. Either increase your UNDO tablespace size or commit more often. Received this error at QAR Server and client import process failed.
Pl. guide how to Increase UNDO Table space or if any more solution to resolve my issue.
Regards,
Naik Diptesh

Hi,
As per your error, it looks like that your Undo tablespace was full because of that your import failed. Undo tablespace you can increase from brtools in PSAPUNDO.
As you have not mentioned your database release. Please check below notes for undo management as per your release.:
Note 1035137 - Oracle Database 10g: Automatic Undo Retention
Note 600141 - Oracle9i: Automatic UNDO Management
Thanks
Sunny

Dropping Rollback table space in export dump and use the undo table space

Hi,
I want to upgrade my DB which is on 9.2.0.1.0 to 10.2.0.1.
I have done an export.
In order to import the DB I have created all the table spaces identical that of my export copy. While creating the Blank database I have already created Undo table space. In the exported DB I have a table space called rollback, how can I drop this table space and use undo table space. I believe this is the recommended table space that should be used in new releases
Thank you

Very briefly, these are the steps you will need to perform:
1) Create an UNDO tablespace the same size as the Rollback tablespace, e.g.:
CREATE UNDO TABLESPACE undo
DATAFILE ‘/ora/$ORACLE_SID/001/oradata/$ORACLE_SID/undo_01.dbf’ size 1000M;
2) Add the initialisation parameters UNDO_MANAGEMENT=AUTO, UNDO_TABLESPACE=UNDO. Omit the UNDO_RETENTION parameter unless it is to be set to a value other then the default of 900 (seconds)
3) Remove the initialisation parameter ROLLBACK_SEGMENTS
4) Bounce the database to bring the new parameters into effect.
5) Drop the Rollback tablespace including contents and datafiles
Cheers,
Jason

UNDO table space in oracle

Hi,
Recently i have added one data file(2GB) to undo table space.Later i gog to know it is not recommend to extent the undo table space.In oracle 9i undo management is handle automatically.(in my init<SID>.ora file undo_management='AUTO')
I have 3 data file undo_1,undo_2,undo_3.
undo_2 is the datafile of 2Gb that i have added.
My question is ....is there any possibility to remove that data file from the DB(undo_2) if possible how can i dod that.
Pls help me.
roshantha

SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SQL>
SQL>
##FIRST : CREATE AN ANOTHER TEMPORARY UNDO TABLESPACE FOR YOUR DATABASE USERS.
SQL> create undo tablespace UNDOTBS_TEMP datafile 'c:\undotbs_temp1.dbf' size 2G;
Tablespace created.
SQL> show parameter undo
SQL> alter system set undo_tablespace=UNDOTBS_TEMP;
System altered.
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS_TEMP
##NOW DROP YOUR UNWANTED TABLESPACE INCLUDING DATAFILES
SQL> drop tablespace undotbs1;
Tablespace dropped.
SQL> drop tablespace undotbs2 including contents and datafiles;
Tablespace dropped.
##NOW RECREATE THE UNDOTBS and RUSE THE FILE YOU WANTED TO
SQL> create undo tablespace UNDOTBS1 datafile 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\UNDOTBS01.DBF' reuse;
Tablespace created.
SQL> alter system set undo_tablespace=UNDOTBS1;
System altered.
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SQL>
hope it helps :-)
Thanks,
Z

Snap Shot too old error And UNDO Table space.

I posted [This Question|http://forums.oracle.com/forums/thread.jspa?threadID=718704&tstart=0] in PL/SQL forum. Now thought this would be a better place.
Thanks,
Karthick.

Karthik,
Its actually not the same thing when we talk about manual Rollback Segments and Automatic Undo Segments. Besides the fact that the former is created by us and thus needs to be managed properly in the terms of the size and other things, the later one is far more performance oriented. There are couple of enhancements which are done in terms of Automatic Undo , to quote a few, Undo Stealing is one .Another is the on the fly making the undo segments offfline and while starting up the database, only the needed ones are available . This enables the fast instance startup.
Wont oracle automatically adjust the UNDO_RETENTION parameter based on the UNDO table space size.
If you have read it from Orcle docs than you must have seen this advice is correct when the release is 10.2 onwards and the tablespace is autoextensible. If the tablespace is autoextensible than from 10.2 onwards, you don't need to worry about the undo_retention period. It will be set automatically. If the tablespace is not autoextensible than Oracle would set the parameter value to the duration of the query.
For the snapshot too old error, I would suggest you read this link,
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923
There is no other document AFAIK which explains it more clearly than this one.
HTH
Aman....

UNDO table space : ora :30036

Hi All,
How to fix ora 30036 table space error..
When the data is loading in to the table i got ora :30036 undo table space error.
What is undo table space error and how to fix this issues . pleas any one let me know.
The Error was:
Error Code :ORA-30036: unable to extend segment by 4 in undo tablespace 'UNDOTBS1'
Thanks
Sree
Edited by: 874823 on Oct 27, 2011 5:26 PM

Hi ,
The following is the table space info
TABLESPACE_NAME FILE_NAME
SYSTEM /oracle/oradata/TWDMQ/dbs1TWDMQ.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_52.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_53.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_54.dbf
SYSAUX /oracle/oradata/TWDMQ/sysaux01.dbf
UNDOTBS1 /oracle/oradata/TWDMQ/undotbs01.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_01.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_02.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_03.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_04.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_05.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_06.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_07.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_08.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_09.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_10.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_11.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_12.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_13.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_14.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_15.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_16.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_17.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_18.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_19.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_20.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_21.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_22.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_23.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_24.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_25.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_26.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_27.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_28.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_29.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_30.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_31.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_32.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_33.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_34.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_35.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_36.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_37.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_38.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_39.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_40.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_41.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_42.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_43.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_44.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_45.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_46.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_47.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_48.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_49.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_50.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_51.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_55.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_56.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_57.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_58.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_59.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_60.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_61.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_62.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_63.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_64.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_65.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_66.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_67.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_68.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_69.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_70.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_71.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_72.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_73.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_74.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_75.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_76.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_77.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_78.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_79.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_80.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_81.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_82.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_83.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_84.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_85.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_86.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_87.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_88.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_89.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_90.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_91.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_92.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_93.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_94.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_95.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_96.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_97.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_98.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_99.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_100.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_101.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_102.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_103.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_104.dbf
DE_DATA /oracle/oradata/TWDMQ/DE_data_105.dbf

Why does undo table space got full even when i commit between inserts??

Dears,
I have stored procedure which inserts around 5million record(insert select not applicable); and it always fails because of "ORA-30036: unable to extend segment by 8 in undo tablespace" although the procedure commits after every 10,000 records and the undo table space is 2GB. so my question is why does undo table space got full even if i commit?? & do i have other solution than making the undo auto extend??
am working on Orcale 9i RAC
Swaid A. McKey

Actually, i had the same problem that my UNDO tablespace starting eating too much space, my undo_retention is set as 3hours, but how can estimate it using the view.
Here the following sample output
SID     STATISTIC#     VALUE
3     151     0
3     152     0
3     153     0
Can anyone assist with it ? But i still have the strange feeling why would UNDO get full once commit is being used. Even i did try with AUTOEXTEND and it throw me the errors that can't extend UNDO tablespace.
Any ideas.....
Thanks !!
MB

UNDO Tables Space File deleted accidently

Dear All,
I performed following actions on my Oracle 11g Database under Windows 32-bits OS.
CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE 'C:\app\oradata\ABCD\undotbs2.dbf' SIZE 10 M AUTOEXTEND OFF ;
ALTER SYSTEM SET undo_tablespace = UNDOTBS2;
shutdown immediate
After this when Database went down I deleted UNDOTBS1 datafile from the folder permanently but before that I forget to use the following statement:
DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES;
When I tried to startup the database it successfully started instance and database if mounted but it can not be in OPEN mode. I receive the following error messages can any one help how to receover from this situation where as UNDOTBS2 is now default undo tablespace.
SQL> startup pfile='C:\app\admin\ABCD\pfile\init.ora.027200918250'
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1332892 bytes
Variable Size 197134692 bytes
Database Buffers 109051904 bytes
Redo Buffers 6340608 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'C:\APP\ORADATA\ABCD\UNDOTBS01.DBF'
Thanks

hi,
alter the undo_management=auto to manual in pfile and start up with that..
it will mount and show error
now alter database datafile 'undo_location' offline drop;
then create
CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE 'C:\app\oradata\ABCD\undotbs2.dbf' SIZE 10 M AUTOEXTEND OFF ;
ALTER SYSTEM SET undo_tablespace = UNDOTBS2;
then alter system undo_management=auto scope=spfile;
noe shutdown and startup the DB..
regards,
Deepak

Rbs with undo table space

i have oracle 9i and i am using rollback segment i would like to use undo. can it possible that i can use both for time been and then retier the rollback segment.

When you set for the automatic undo management, then Oracle will automatically manage the size of each undo segment and the number of undo segments.
Initial number of undo segements is determined by three parameters
- sessions, transactions, processes
Then Oracle automatically increases the size and the number of undo segments.
Addtional feature introduced in 10g that is realted to the undo tablespace is the FAST RAMP-UP feature. This feature allows oracle to turn on the proper number of undo segments needed during the normal operation right away using the historical information in AWR even if you restart your database.

SYSTEM table space is critical

Hi,
Generally we will not add any datafiles for UNDO table space because it is oracle managed tablespace.For SYSTEM table shall I add datafile if it reaches threshold value or not?
Regards,
ARNS.

Hi,
Normally there is no need to increase the SYSTEM table space.The SYSTEM tablespace should only contain system-relevant data (such as the Oracle Dictionary).If you do not specify a 'Default Permanent Tablespace' when you create the database, the SYSTEM tablespace automatically assumes this role.May be this is happening in your case.
The size of the Oracle Dictionary in the SYSTEM tablespace stabilizes over time. The AWR (Automatic Workload Repository) in the SYSAUX tablespace also becomes relatively fixed in size after a certain time, depending on the retention period. The SYSTEM and SYSAUX tablespaces therefore remain relatively stable in terms of size in the longer term.
Application data, on the other hand, is not stable, and usually grows in size. If user data is stored in the SYSTEM or SYSAUX tablespaces, these two tablespaces may continue to grow in an uncontrolled manner. Time-consuming reorganization is then required at a later stage to correct this.
If non-system database users use the SYSTEM tablespace to save their data, this may also cause the database performance to degrade. The following security problem also arises: If non-system database users store their data in the SYSTEM tablespace, the entire space in the SYSTEM tablespace may be occupied, which means that the database can no longer function. In terms of system availability, you should therefore always ensure that a tablespace other than SYSTEM or SYSAUX is defined as the special Default Permanent Tablespace.
Award points if useful.
Phani

Unable to shrink undo tablespace... Help!

Hi,
I have problems to shrink the system undo tablespace, which has grown up to 14 GB.
I use 9.2. Table space owner is 'SYSTEM', undo_management = AUTO.
I tried to shrink the greatest rollback segments by the commands
ALTER SESSION SET UNDO_SUPPRESS_ERRORS = TRUE;
ALTER ROLLBACK SEGMENT "_SYSSMU6$" SHRINK TO 20 M;
Oracle confirmed these commands, but nothing happened.
What am I doing wrong?
Hermann Mueller

You have seen the discussion about the undo segments, on the temporary tablespaces, you should be aware that the sort segment of a given temporary tablespace is created at the time the first sort operation takes place. The sort segment continues to grow by means of extent allocation until the segment size has reached the total storage demands of all of the active sorts running on the instance. Oracle will keep on allocating temporary space on demand unless the physical limit states otherwise.
Temporary segments are produced each time a sort operation (explicit -order by- or implicit -aggregation, reindexing-) requires to sort a set that cannot fit into memory. So if you detect excesive sort usage you should aim your monitors towards the sort operations (reports, reindexing, max, min, aggregations, order by ...). If your system has a DDS behaviour, this kind of operations are frequent as a massive sorting has to be peformed against millions of rows.
A Temporary tablespace will almost always appear to be near 100% full, that's because once oracle has allocated temporary space it doesn't release it back to the free space, it keeps it allocated even when the sort operation has finished. Criteria behind this fact is similar to the one oracle used to have when the rollback segments were in use, Oracle only allocated space and the dba should perform manual actions to release space, and the criteria is performance. Once it has allocated space this big, there are possibilities that the same circumstances that raised the temporary usage high water mark to this level are repeated, so if oracle keeps the mamimum allocated space, it won't have to allocate the same storage once more.
Main concern with temporary tablespace growth is not free space itself, but the reasons why this amount of space was allocated, so I suggest you to track the sql statements with sort operations. If you are certain the circumstances that motivated this amount of temporary resources to be allocated won't be repeated again, then you could think of resizing down your temporary tablespace. I suggest you to create a new temporary tablespace with the desired size, and alter the default tempoary tablespace to point to this newly crated temporary tablespace, and finally get rid of the original temporary TS.
~ Madrid

Error while shrinking a table

Hi All,
I am facing issue while shrinking a table PARAMETER_DETAIL which is a IOT partition table.
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
PL/SQL Release 10.2.0.2.0 - Production
CORE 10.2.0.2.0 Production
TNS for Solaris: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - Production
SunOS usa0300ux636 5.10 Generic_138888-03 sun4v sparc SUNW,Sun-Blade-T6320
When i am firing the below query,
alter table PARAMETER_DETAIL SHRINK space CASCADE;
alter table PARAMETER_DETAIL SHRINK space CASCADE*
ERROR at line 1:
ORA-10635: Invalid segment or tablespace type
I am getting this error.
Moreover, I have checked in dba_segments, the output is
SQL> l
1 select unique SEGMENT_NAME,PARTITION_NAME,SEGMENT_TYPE,TABLESPACE_NAME from dba_segments where SEGMENT_NAME='PARAMETER_DETAIL'
2* and OWNER='CDE'
SEGMENT_NAME
PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME
PARAMETER_DETAIL
PD_201107220130 INDEX PARTITION DATAFEED
PARAMETER_DETAIL
PD_201107211630 INDEX PARTITION DATAFEED
PARAMETER_DETAIL
PD_201107212030 INDEX PARTITION DATAFEED
SEGMENT_NAME
PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME
PARAMETER_DETAIL
PD_201107212100 INDEX PARTITION DATAFEED
PARAMETER_DETAIL
PD_201107210330 INDEX PARTITION DATAFEED
PARAMETER_DETAIL
PD_201107210630 INDEX PARTITION DATAFEED
SEGMENT_NAME
PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME
PARAMETER_DETAIL
PD_201107210830 INDEX PARTITION DATAFEED
PARAMETER_DETAIL
PD_201107211030 INDEX PARTITION DATAFEED
1490 rows selected.
SQL> select TABLESPACE_NAME,SEGMENT_SPACE_MANAGEMENT from dba_tablespaces;
TABLESPACE_NAME SEGMEN
SYSTEM MANUAL
UNDOTBS MANUAL
SYSAUX AUTO
TEMP MANUAL
USERS AUTO
DATAFEED AUTO
6 rows selected.
Please help me out to shrink this table.
Thanks

http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/schema.htm#ADMIN10161
Shrink operations can be performed only on segments in locally managed tablespaces with automatic segment space management (ASSM). Within an ASSM tablespace, all segment types are eligible for online segment shrink except these:
IOT mapping tables
Tables with rowid based materialized views
Tables with function-based indexesSince this is an IOT, any chance there is an IOT mapping table?
Since this appears to be a data warehouse, any chance there are ROWID based materialized views or function-based indexes?
Justin

Error ORA-10635 when shrink a table!!

Hi all,
I have a table created in a tablespace using ASSM and when i try to shrink this table i receive the error ORA-10635. I can do shrink on other tables that are on the same tablespace of that table that is giving me this error.
Anyone can help please??
Tks,
Paulo.

10635, 00000, "Invalid segment or tablespace type"
// *Cause: Cannot shrink the segment because it is not in auto segment space
// managed tablespace or it is not a data, index or lob segment.
// *Action: Check the tablespace and segment type and reissue the statement

Table space not reduce after delete in oracle 11G

Hi Team,
I have a DB 11.1.0.7 on unix.
I have execute delete tables on tablespace, but this not reduce.
Thanks

935299 wrote:
What segment space management type is defined for the tablespace in question?
MANUAL
Then you should check out the documentation some more.
But even if you shrink the table segement what is that going to do for the data file size?
I don't undertand you.
ThanksYour thread is titled "Table space not reduce after delete in oracle 11G" which implies to me that you are interested in reducing the size of a tablespace (which really means reducing the size of the underlying datafile(s)).
So, if you shrink the size of the sys.aud$ table, will that cause the datafile(s) to become smaller? Will it accomplish your goal? What else, if anything, needs to happen?

Table space not reduce after delete in oracle 10g

Hi..
Based on my system, i have found that my oracle table space did not reduce after the deletion query. Why ?.. Could somebody help me. As your info, I am using oracle 10g.
Thank you,
Baharin

After Delete the table space will not be set free. high water mark will not be reset. to regain the space you need to recognize the objects from which you deleted the data. This can be done in many ways.
1) Move the objects.
Alter table temp move --> optionally tablespace clause can be used. After this you need to rebuild table indexes.
2) With 10g table can be shrinked or reorganize to free the space.
alter table mytable enable row movement;
alter table mytable shrink space;
3) Export/Import
export the objects and drop and recreate with import.

Shrinking Undo Table Space

Similar Messages

Maybe you are looking for