Undo tablespace keeps growing

Hello,
my undotbs is growing 14g (although i my undotbs actul size is 9g) I try to resize datafiles, but
this may not work.
So, i am assuming to perform this task
>
- Create a new undo tablespace as :
SQL> create undo tablespace UNDOTBS2 datafile '<complete file path>' size <smaller size>;
- Change parameter UNDO_TABLESPACE
SQL> alter system set UNDO_TABLESPACE=UNDOTBS2;
- Drop UNDOTBS1
SQL> drop tablespace UNDOTBS1 including contents and datafiles;>
but my question is , is it worthy to delete the undotbs1 whose having alot of data and if i deleted
this (undotablespace) data ,i will not able to recover it thoroughly?
db_version:10.2.0(linux)

sunny kichlooIf your concern is regarding how to resize Refer this thread
>
i have already try this but it still growing and day-today we are running large transaction on our db.
marcopb Try to investigate why your undo tablespace is growing... and think about why your next undo tablespace won't grow as the previous...
>
our db size is 60g and we are running on heavy transection on it (everday)

Similar Messages

Undo tablespace keeps on growing

We have a 3rd party application running on our oracle(10.2.0.4) database running on 64bit solaris(sparc) machine.
Since few days my undo started going up. I increased the size from 2g to 5g. Still it is at more then 90%levels.
I ran this query to see which session is using maximum undo
SELECT a.sid, b.name, a.value
FROM v$sesstat a, v$statname b
WHERE a.statistic# = b.statistic#
AND a.statistic# = 176
ORDER BY a.value DESC
From this i found the session which is using max undo.
When i query this sid from v$session i see this is inactive
my undo retention is set to 9000 and undo management is auto
how can i check if i have expired undo blocks that are not being used

>
Since few days my undo started going up. I increased the size from 2g to 5g. Still it is at more then 90%levels.
I ran this query to see which session is using maximum undo
SELECT a.sid, b.name, a.value
FROM v$sesstat a, v$statname b
WHERE a.statistic# = b.statistic#
AND a.statistic# = 176
ORDER BY a.value DESC
From this i found the session which is using max undo.
When i query this sid from v$session i see this is inactive
my undo retention is set to 9000 and undo management is auto
>
With an UNDO_RETENTION of 2.5 hours set, I am not surprised that you use up to (or even more than) 5g space in the UNDO tablespace! I would even call that moderate.
What is your concern? If you don't have the space for your UNDO tablespace, lower UNDO_RETENTION accordingly. Notice that UNDO_RETENTION is the wish to preserve before images for that long time even if their transaction did already commit. Why have you set it to that (relatively high) value of 2.5 hours?
Kind regards
Uwe
http://uhesse.wordpress.com

Undo tablespace growing without reusing space

Hi,
I'm running an Oracle9i database on Solaris. I am using the automatic undo management and I have one undo tablespace. The UNDO_RETENTION value is 900. I have created the undo tablespace this way (clause in create database statement):
UNDO TABLESPACE "UNDOTBS1" DATAFILE '/u04/oracle/oradata/my_dbname/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
The undo tablespace datafile is now close to 3G. I have other servers running the same setup, and their undo datafile size is still 200M. There is currently no active transaction in the database. Any idea why this is happening? Is there any tables I can check for clues?
Many thanks,
Gloria

Should Oracle automatically shrink the undo tablespace (datafile) when it is not needed anymore? Say at one point the database really needs 3G of undo tablespace, but afterwards only 10M is needed, would the datafile be 'shrunk' back?
Also, how can I check if the database really needed the 3G of undo tablespace at one point? (I guess it's checking the level of activities in the database, but how do I do that for past data?)
I'm trying to decide whether the undo tablespace really grew due to a need at some point or is it a case of Bug 2660394 (documented in metalink note271119.1). The bug basically says that "An auto extensible undo tablespace MAY grow before reusing expired extents leading to more space use than actually needed".

Undo Tablespace and Temporary Tablespace - autoextend ?

- In general, should I allow the Undo Tablespace to grow (autoextend)?
- In general, should I allow the Temporary Tablespace to grow (autoextend)?

The size of undo tablespace should always keeps in mind otherwiase you eill get ORA-1555 or out of space errors.
This paper is to help DBA’s in calculating the size of UNDO tablespace by using a simple formula.
It is tough to know about the number of transactions and subsequently number of rows changed per second.
So I suggest having a “big undo tablespace” to start with and based on load, after doing some calculations and resize your UNDO tablespace.
In my case one of the applications was going to production (live), and I had no idea that how many transactions will happen against this database. All what I was told that there will be optimum (transactional) activity on this database.
So I started with UNDO tablespace with size of 3GB and datafiles with autoextend “on” .
Note:
In production, you must be very careful in using this (autoextend on) as the space may grow to inifinity very fast. So my advice is either dont use this option, or use with "maxsize" or continuously monitor space (which is tough).
I month later, I noticed the activity from V$undostat.
Here is the step by step approach:
Step 1: Longest running query.
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
1793
This gives you ideal value for UNDO_RETENTION. To be on the safer size you should add few more seconds to get the right value. So in my case, the size of undo retention should be say 2000 secs.
Step 2: Size of UNDO tablespace.
Size of UNDO needed = UNDO_RETENTION x [UNDO block Generation per sec x DB_BLOCK_SIZE] + Overhead(30xDB_BLOCK_SIZE)
Out of these we know UNDO_RETENTION and DB_BLOCK_SIZE
All we need is to find out “UNDO Blocks per second”
Which can be easily fetched from v$undostat
SQL> SELECT (SUM(undoblks))/ SUM ((end_time - begin_time) * 24*60*60) "UPS"
2 FROM v$undostat;
UPS
8.11985583
V$undostat stores data for every 10 mins and begin/end times are start/end time of those intervals. We multiplied it with 24*60*60 because the difference between two dates will be in days and to get to seconds, we need it to multiply with 24hrs*60mins*60secs
So now we have all the values needed.
Undo size needed = [8.12 x 2000 x 8192] + [30 x 8192] = 133283840 bytes = 127.11 MB

Undo tablespace growth

Hi ..
My undo tablespace is Growing rapidly from 1gb to 10 gb with an Hour.
Is there any ways to find out which operation Generates More Undo ..
Can i able to restrict it...

hi,
there is parameter that control the aging out of undo blocks that leverages size of UNDO tbs:
UNDO_RETENTION
You can guarantee that unexpired undo data is not overwritten even if it means that future operations that need to generate undo data will fail. This is done by specifying the RETENTION GUARANTEE clause for the undo tablespace when it is created by either the CREATE DATABASE or CREATE UNDO TABLESPACE statement. Alternatively, you can later specify this clause in an ALTER TABLESPACE statement.
more: UNDO RETENTION GUARANTEE

Insert as select - why is it writing so much Undo tablespace data?

Environment: Oracle 10g R2, Sun solaris, ASM
I have table A with 92 million rows. Table B, which is identical to table A, has 5 million rows. Table A only has three index columns ( no composite indexes ) and the average row length is 109 bytes.
I issued the command: insert into A select * from B; in order to append the rows from B to A. This command has been executing for over 4 hours. I've been watching the tablespace usage in EM and I can see the undo tablespace usage grow to over 9 GB's and the query is not finished. Meanwhile, the index tablespace has not grown at all. There is no other activity on this instance.
I've performed similar inserts in the past and it hasn't taken nearly this long. According to my calculations, writing all of the 5 million rows to Undo would only require about half a gig. Also, we thought there might be a 'ghost' session or process that was causing problems earlier, so we shut everything down and rebooted the server. There is no other activity.
Could anyone explain why it would write so much undo data? It's almost as if Oracle is making a copy of table A ( 92 million rows ) first.
Thanks,
BAH

Thanks, based on the information from the last two posts, maybe it's starting to make sense. Here is the table ( the column names have been changed to protect the innocent...)
TABLE A=
col1 NUMBER not null,
col2 NUMBER,
col3 VARCHAR2(15),
col4 NUMBER,
col5 NUMBER,
col6 FLOAT,
col7 FLOAT,
col8 FLOAT,
col9 FLOAT,
col10 FLOAT,
col11 FLOAT,
col12 FLOAT,
col13 FLOAT,
col14 NUMBER,
col15 NUMBER,
col16 NUMBER,
col17 FLOAT,
col18 FLOAT,
col19 FLOAT,
col20 NUMBER,
col21 NUMBER,
col22 FLOAT,
col23 NUMBER(17,2),
col24 NUMBER(17,2),
col25 NUMBER(13,5),
col26 NUMBER(13,5),
col27 NUMBER(13,5),
col28 NUMBER(13,5),
col29 NUMBER(13,5),
col30 VARCHAR2(1),
col31 VARCHAR2(1),
col32 VARCHAR2(1),
col33 NUMBER
pctfree 10
initrans 1
maxtrans 255
storage
initial 64K
minextents 1
maxextents unlimited
Column 1 is indexed as the primary key. Columns 2 and 3 have separate indexes. I was not aware of the 'Append' hint - so thanks for that. In researching, I found that if you use the append hint, it places all the rows above the HWM. If not, it looks for places within the tablespace. So, based on the info in post #3, perhaps it is writing all of the used blocks out to undo that are being modified with the insert? My calculation was straight forward ( 109 bytes for row length * 5 million rows ). I knew there would be some overhead, but the undo ts is now over 13.3 GB.
Thanks for the info.

Undo tablespace grows fast

How the undo tablespace grows very fast., how can we control on it. When I try to resize it did not allow me, what exact action can i take it.

>> How the undo tablespace grows very fast., how can we control on it.
It’s all depending on the DML transaction activities on your database i.e. frequent inserts,updates, and deletes.
>> When I try to resize it did not allow me, what exact action can i take it.
How/What you tried to resize it. Can you show the details??
Moreover, Do take a look at the Oracle Documentation on "Managing the Undo Tablespace"
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm
Regards,
Sabdar Syed.
Added the link.
Message was edited by:
Sabdar Syed

Undo tablespace growing fast

Hello All
We are having issues with undo tablespace growing... the oracle version is 10.2.0.1.0
the table is holding around 400000000 records and this table is also partitioned by range
any reason for this undo tablespace growing by at an high rate
regards
Kedar

Undo tablespaces are special tablespaces used solely for storing undo information. You cannot create any other segment types (for example, tables or indexes) in undo tablespaces. Each database contains zero or more undo tablespaces. In automatic undo management mode, each Oracle instance is assigned one (and only one) undo tablespace. Undo data is managed within an undo tablespace using undo segments that are automatically created and maintained by Oracle.
Every Oracle Database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. These records are collectively referred to as undo.
Undo records are used to:
Roll back transactions when a ROLLBACK statement is issued
Recover the database
Provide read consistency
Analyze data as of an earlier point in time by using Oracle Flashback Query
Recover from logical corruptions using Oracle Flashback features
When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.
You confuse TEMP with UNDO tablespace.
Best Regards,
Francisco Munoz Alvarez
www.oraclenz.com

ORA-30036: unable to extend segment, our UNDO TABLESPACE grow to 500 GB

Our client report that when they run their batch job the error "ORA-30036: unable to extend segment..." came into their log file.
I have checked with alert log but nothing there. We use Oracle 11g on Solaris 10 SPARC.
Any suggestion ?
Thanks & Regards

Refer to
Troubleshooting ORA-30036 - Unable To Extend Undo Tablespace [ID 460481.1]
ORA-30036: unable to extend segment by <N> in undo tablespace '<tname>' [ID 271664.1]

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

Undo tablespace grew 15GB +

Hi Guys,
During one of the processes my UNDO tablespace grew to 15GB(reached it's limit) and it keeps growing. I have made the size to 20GB and it going to fill that too. Can someone suggest a way to fix this issue? Can I create a new TS and drop the old one something like this:
CREATE SMALLFILE UNDO TABLESPACE "UNDOTBS2" DATAFILE 'D:\ORACLE\ORADATA\NGS1\UNDOTBS02.DBF' SIZE 200M REUSE
alter system set undo_tablespace = undotbs2
DROP TABLESPACE UNDOTBS1
If I drop the old UNDO tablespace do I have to follow some prerequisite for example set undo_retention=0 etc. Please let me know.
Thanks

Hello,
Even if the transaction is commited the Undo Tablespace can keep Undo records ( you have the
parameter undo_retention ).
When you create a new Undo tablespace then, you have to switch the database to it by
using the parameter undo_tablespace.
This is a dynamic parameter but, I use to restart the database so as to be sure that the old
undo tablespace is not used anymore. So that I can drop it.
Of course the database should be shutdown cleanly so that there's no transaction to rollback when
you start it up.
Best regards,
Jean-Valentin

UNDO tablespace increase more more .... spaces

I checked my Oracle database. I found undo tablespace increase more more spaces.
from 10G , now 40G
undo_retention = 15 minutes
Please help me
How I tune and monitor for track this problem?

Hello HunterX,
You have not indicated which version of database & on what platform. The Version number & platform is very important...I tell you why. Because i had the same issue with my database and handled successfully.
Please check the BUG No. Note:2660394.8 & also note no. 271119.1.
This explains that Undo tablespace is used and after the expiry of 15 minutes it does not use the EXPIRED extents. It again allocates the NEW extents out of your segment of the tablespace....And leads to continuous growing of UNDO Tablespace...
Do the follwoing i feel would be appropriate...Rest you can decide it better....
1. Create a New UNDO Tablespace may be undo_new of smaller size..
2. Do not keep autoextend ON and put some max size...may be 1 GB. Do not put it unlimited.
3. Stop the DB Instance
4. Change the name of new UNDO Tablespace in INIT.ORA file
5. Restart the DB Instance.....
6. drop the Old Tablespace UNDO & delete the datafile...
If stopping of DB Instance is not possible...(for production server), i hv few command which does the above on-line. But i do not remember them at this time...I will hv to refer my docs. If you feel i can try that for you...otherwise you may follwo above points.
Hope that helps to you. Thanks.
Regards,
Kamesh Rastogi

Problem with UNDO tablespace

Hi guys.
Our database has 50GB of undo tablespace. I decided to create a second undo tablespace and switch to the new one. Since doing that yesterday, the size of the old undo is 49GB (was thinking that the values will drop to zero) and the new tablespace keeps increasing in size! Its size now is about 20GB. I do have the following question.
a) If I restart the database, it the value of the old undo going to fall to zero?
b) undo_retention=86400. Setting this value to a lesser value say 800seconds, it is going to act the performance of the database? Is it going to release the space on the old undo?
Thanks and any help is appreciated.
David

The undo tablespace will not automatically shrink size, since you have a new undo tablespace in place. You can drop the old one if you don't plan to use it.
Set lower undo_retention will certainly help to contain the undo space usage. However you should query v$undostat and v$rollstat to estimate the amount of undo space required for the current workload then size the undo tablespace accordingly. Turn off the auto extend on undo tablespace.

CLEAN UNDO TABLESPACE

Hi Group
We need to free up an old UNDO tablespace (TS_ROLLBACK) because we have created a new one (TS_UNDO), ¿how can we do that?, we need to drop old UNDO tablespace but it keeps some extents active more than 4 days.
OWNER     SEGMENT_NAME     TABLESPACE_NAME     EXTENT_ID     FILE_ID     BLOCK_ID     BYTES     BLOCKS     RELATIVE_FNO     COMMIT_JTIME     COMMIT_WTIME     STATUS
SYS     SYSSMU8$     TSROLLBACK     0     51     122     57344     7     51               ACTIVE
SYS     SYSSMU8$     TSROLLBACK     2     104     8969     1048576     128     104               ACTIVE
SYS     SYSSMU215$     TSUNDO     3     107     3593     1048576     128     107               ACTIVE
SYS     SYSSMU229$     TSUNDO     0     107     6370     57344     7     107               ACTIVE
SYS     SYSSMU229$     TSUNDO     3     107     46985     1048576     128     107               ACTIVE
SYS     SYSSMU256$     TSUNDO     3     107     40073     1048576     128     107               ACTIVE
Thank you so much

When I try to drop the tablespace it shows the message:
ORA-30013: undo tablespace 'TS_ROLLBACK' is currently in use.
The result of the query is (i've copied 4 lines of 68, there is a transaction that have started on 15 January, could it be what locking the ts?:
ADDR     XIDUSN     XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC     STATUS     START_TIME     START_SCNB     START_SCNW     START_UEXT     START_UBAFIL     START_UBABLK     START_UBASQN     START_UBAREC     SES_ADDR     FLAG     SPACE     RECURSIVE     NOUNDO     PTX     NAME     PRV_XIDUSN     PRV_XIDSLT     PRV_XIDSQN     PTX_XIDUSN     PTX_XIDSLT     PTX_XIDSQN     DSCN-B     DSCN-W     USED_UBLK     USED_UREC     LOG_IO     PHY_IO     CR_GET     CR_CHANGE
C00000011B25E880     8     26     2204276     0     0     0     0     ACTIVE     01/15/10 18:03:24     135089268     23     2     104     9065     -17910     27     C000000117D19BF8     5635     NO     NO     NO     NO          0     0     0     0     0     0     0     0     0     0     13     23     37359     2
C00000011AC1ED80     271     26     3160     0     0     0     0     ACTIVE     01/21/10 08:00:03     341730228     23     3     107     22901     208     49     C000000117E65CE8     4199939     NO     NO     NO     NO          0     0     0     0     0     0     0     0     1     1     3     257     2492     0
C00000011B1F0A20     251     5     2102     0     0     0     0     ACTIVE     01/21/10 08:04:54     341785988     23     3     107     53963     194     43     C000000117E3D898     4199939     NO     NO     NO     NO          0     0     0     0     0     0     0     0     1     1     11     13     1008162     16
C00000011B25A138     255     5     2932     0     0     0     0     ACTIVE     01/21/10 08:17:49     342060712     23     2     107     3350     331     9     C000000117E1BDE8     4199939     NO     NO     NO     NO          0     0     0     0     0     0     0     0     1     1     3     5     19     0

Undo tablespace and instance recovery

Is UNDO tablespace is mandatory during instance recovery. ?
Suppose my undo tablespace has some active transaction and instance crashes making undo tablespace inaccessible.
Will database search for that undo tablespace during startup or I can simply create a new one and set as new undo tablespace ?
With Regards
Amt

Hi,
>>I am actually confused
Keep in mind that If an Oracle instance crashes, any changes that are made in the SGA are not written to the data files. When you restart the instance, the SMON background process automatically performs instance recovery by performing the following tasks:
• Rolling forward changes that are made in the online redo log files but not in the data files. Since all the committed transactions are written to the online redo log files, these are successfully recovered as result of rolling forward changes from the online redo log files to the data files.
• Opening the database. After the database is opened, users can log on and access any data that is not locked by un-recovered transaction.
• Rolling back all the uncommitted transactions.
In resume, during database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles.
But if your UNDO tablespace crashed, then you will need recover it, using steps like
1) shutdown abort (If the instance yet is up)
2) cp -a /backup/undo01.dbf /u01/oradata (restore the latest recent backup file)
3) startup mount
4) recover database or recover datafile '/u01/oradata/undo01.dbf'
5) alter database open;
In some cases, re-create it, also resolve the problem:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5669213349582
Missing UNDO tablespace in restore backup
>>I checked in test setup and it is actually waiting for missing UNDO tablespace.
Which exactly test you are doing?
Cheers

Undo tablespace keeps growing

Similar Messages

Maybe you are looking for