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

Similar Messages

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

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

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

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

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

ORA-30036 when modifying column in large table

Oracle version 10.2.0.4
Afternoon everyone!
I have a large table that I need to modify a column in - increasing from CHAR(3) to CHAR(6)
On altering the table I'm getting an ORA-30036: unable to extend segment but 8 in undo tablespace
Increasing undo tbs size isn't really an option, and I don't really want to go copying the table elsewhere either - again due to space limitations.
Is there a way to avoid this undo exhaustion? Will disabling logging for this table solve my issue? Or is there another way similar to the 'checkpoint' clause you can use when dropping columns?
Many thanks!
Adam M

Just in case nothing better appears and you can't increase the UNDO ...
1. Create a new table with the correct datatype
2. Insert data from the old table to the new table, in batches if necessary. Divide the data by key values if possible or get a range of rowids to process or something
3. Make sure dependent objects are created for the new table
4. drop the old table
5. rename the old table to the new table

Doubt regarding ORA-30036: unable to extend segment by 8 in undo tablespace

I am using 11g Release 1 Database .
I have to analyze the performance of two tables of different designs which serve the same purpose and come up with the design which is efficient .
SQL> desc staging_dict
Name                                      Null?    Type
SNO                                                NUMBER
CODE_FRAGMENTS                                     CLOB
CODE_FRAGMENTS_U                                   CLOB
CODE_FRAGMENTS_D                                   CLOB
CODE_FRAGMENTS_DO                                  CLOB
SQL> desc staging_dict1
Name                                      Null?    Type
SNO                                                NUMBER
CODE_FRAGMENTS                                     CLOB
CODE_FRAGMENTS_UD                                  CLOB
CODE_TYPE                                          VARCHAR2(5 CHAR)Initially I tried inserting a few thousand records into both the tables . Then I did some conversion on one column and I populate the result on other column of the same table . So I update the table in bulk mode and I commit for every thousand records .
I have a undo tablespace of 2G with undo_retention=900 , retention guratantee is not set for the undo tablespace .
When I tried the conversion and update on the first table (STAGING_DICT) it took more time for around 2500 records compared to other table and when I increased the number of records to 10000 it threw an error
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS'
But I didn't come across this error when I tried the conversion and update on the table for the same 2500 records (STAGING_DICT1) and it was also 10 times faster .
My doubt is does the error ORA-30036 occur because it is saving the undo image of all the four clob columns though I am doing conversion on one column and updating the other column (using only two columns in the update and only one column is affected by update command) ?
Also how is that having less CLOB rows prove more effective by adding one more VARCHAR column which differentiates the code_frament type in the STAGING_DICT1 table than having it as more CLOB columns as in STAGING_DICT table ?

Don't you think the error OP reported is kind of weird?
Because as you said, Oracle stores "undo" of lob in user tablespace not undo tablespace if the lob is stored out-of-line.
1. If the size of lob was small, small size of undo would be stored into undo tablespace,
and OP would'nt have undo tablespace shortage problem.
(How does small lob flood undo tablespace?)
2. If the size of lob was big, OP would have 01555 error on user tablespace not undo tablespace shortage error.
So, i think there are 2 theories that can explain this abnormality.
1. OP hit the bug of massive undo generation.
2. OP is using securefile which is 11g new feature.
Oracle documents says that undo for securefile lob is stored in "undo" tablespace, not user tablespace.
But unfortunately, i'm not sture about this coz i didn't try it myself

OEM Upgrade - ORA-30036: unable to extend segment by 8 in undo tablespace

Oem upgrade Installer failed on repository in upgrading to grid Control 10.2.0.5
757921: ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS'
757922: ORA-06512: at line 117
I added two datafiles to fix this error so I thought I had enough space now - installer failed when upgrading the repository with ORA-30036 unable to extend segment by 8 in undo tablespace 'UNDOTBS', When I hit retry it keeps failing on the same error. The upgrade is in STATUS -3. Could I run this as sysman and then go back to the installer screen and retry again.
execute emd_maintenance.set_comp_status('_
UPGRADE_', EMD_MAINTENANCE.G_STATUS_
CONFIGURED_READY);
If you have any tips going forward pleases let me know.,
Joseph

Has anyone encountered this error: doing re-installation on OEM upgrade. I can seem to find anything on metallink. There is no error code
txnRemoveConfirmation .
Joseph

ORA-30036: unable to extend segment by string in undo tablespace "string"

Hi hussein/helios,
EBS 11i
RHEL 4.6
Our users in Inventory - Order Management Module , tried to enter and save transactions, but they encounter this ORA-30036 error:
Unable to extend segment by 8 in undo tablespace 'APPS_UNDOTS1'
in Package OE_ORDER_WF_UTIL Procedure Start_FlowIn your experience how do you tune this package for an appropriate UNDO? What is the appropriate size for my UNDO? Do I allow it to
to autoextend? or just allocate enough space.
Thanks a lot,
Ms K

user_unlimited wrote:
Hi new2,
I don't get it clearly :( . I guess oracle already tuned these apps tablespaces extents. I just want to know if its >ok to increase it.Not all tablespace i found is tuned.
Do you have a productions EBS 11i? EBS R12 RUP 6 DB 10.2.0.0
what is the size of your UNDO?4GB
>
>
ThanksUNDO Tablespaces should contain between 1024 and 4096 extents
To check for UNDO and TEMP tablespaces that do not obey the extent size rules you can run the following query:
select tablespace_name, initial_extent, next_extent, pct_increase, min_extlen
from dba_tablespaces t,
(select tablespace_name tbspc,
sum(bytes) tbspc_sz,
count(*) num_files,
sum(bytes)/sum(blocks) blk_sz
from dba_data_files
group by tablespace_name) f
where
( initial_extent < (tbspc_sz - blk_sz * num_files) / 4096
or initial_extent > (tbspc_sz - blk_sz * num_files) / 1024
or next_extent != initial_extent
or pct_increase != 0
or min_extlen != initial_extent)
and tablespace_name = tbspc
and tablespace_name != 'SYSTEM'
and ( contents = 'TEMPORARY'
or tablespace_name in (select tablespace_name from dba_rollback_segs));My cases i found iitial extent 65536 and min_exlen 65536
check with this query then decide what will u do...
HTH

ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'

Hi experts,
I'm getting this error
"ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'"
will you please tell me the reason and suggest me, what to do.
OS - SunOS 5.10
oracle - 10.2.0.3.0

Hallo.
I have this problem 30036 after this request (ver. 10.2):
DELETE FROM AUDITDBA.SEOSDATA where COMPUTERNAME ='xxxxx' AND TIMSTAMP >= '18-03-2011' (! number of rows is less as 2 000 000)
I tried do this:
ALTER SYSTEM SET UNDO_RETENTION = 5;
But after next action "DELETE" again problem 30036..
Here is a "space status" from the system:
TABLESPACE_NAME VOLNE_MIESTO
CA_AUDIT 3714,1875 MB
SYSAUX 42,1875 MB
SYSTEM 5,25 MB
UNDO_TEMP 7998,0625 MB
USERS 999,125 MB
It's clear for me that datafile UNDOTBS is small but I have same questions:
1. What You recommend - use autoextend on for the UNDOTBS datafile or extend it manualy?
2. What size You recommend for the UNDOTBS when I have DB size cca 350 GB, into DB incomming cca 50 events (rows) per second and I need remove from this DB aproximetly 1/2 numbers of rows (old data)
3. Recommend me best way how I can remove old data from DB without problems as "30036"...
Thank You in advance
Peter

UNDO table space : ora :30036

Similar Messages

Maybe you are looking for