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

Similar Messages

  • 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 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 datafile grows fast

    Hi, all
    The undo datafile in my database growed fast yesterday. I want to find out which DML SQLs caused the datafile growing, is it possible?
    Thanks,
    Siko.Lee

    Rafi (Oracle DBA) wrote:
    Hi,
    Do you want the result like this:
    SQL> sho user
    USER is "SYS"
    SQL> select
    2  to_char(begin_time,'yyyy-mm-dd hh24:mi:ss')
    3  starttime,
    4  to_char(end_time,'yyyy-mm-dd hh24:mi:ss')
    5  endtime,
    6  undoblks,
    7  maxquerylen maxqrylen
    8  from v$undostat;
    STARTTIME           ENDTIME               UNDOBLKS  MAXQRYLEN
    2011-02-22 16:54:00 2011-02-22 16:58:13          0          0
    2011-02-22 16:44:00 2011-02-22 16:54:00         12          0
    2011-02-22 16:34:00 2011-02-22 16:44:00         42          0
    2011-02-22 16:24:00 2011-02-22 16:34:00          8          0Best regards,
    Rafi.
    http://rafioracledba.blogspot.com
    Thanks, Rafi
    But I want to know which DML SQL generated the maximum undo data in the past.

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

  • Esbigtbl tablespace growing fast, help...

    Hi to all,
    There is a Tablespace in the es_mail schema that is growing more or less 1GB a day (esbigtbl). Please can someone explaim me if that is normal, how to know why is gowing so much and how to limit the growing velocity?
    Regards
    Luis Neves

    Hi,
    At last we solved our problem, we had BUG 3036037 and after solving that everything became normal. Now i have another question:
    We "cleaned" 9/10 of our mail tablespaces, but Enterprise Manager keep saying that they are in full use (but its not, for sure). Is it possible to compact or shrink them? And why EM says that they are full?

  • FLASHBACK OFF FOR UNDO TABLESPACE????

    Hi all
    As my Undo tablespace growing evryday 2 GB & NOW it reached 19,
    Database size is 6GB only
    using Oracle 10g Release 2 without patch Set (release 1002000100) on Hp-Unix OS
    Can i use the Undo tablespace with FLASHBACK OFF option?
    what are the Consequences for Turning off the FLASHBACK,
    Can we use this type of Undo tablespace with Flashback OFF???
    CREATE UNDO TABLESPACE UNDOTBS03 DATAFILE
    '/app/oracle/product/oradata/prod/undotbs03.dbf' SIZE 1000M AUTOEXTEND OFF
    ONLINE
    RETENTION NOGUARANTEE
    BLOCKSIZE 8K
    FLASHBACK OFF;
    THANKS ALOT

    Oracle Flashback Database: feature is similar to conventional point-in-time recovery in its results, allowing you to return a database to its state at a time in the recent past. It is, however, much faster than point-in-time recovery, because it does not require restoration of datafiles from a backup and it requires application of fewer changes from the archived redo logs.
    UNDO  Tablespace: Oracle db save the old value when a process change data in undo tablespace.
    I think that you can change de default UNDO tablespace as NO AUTOEXTEND, and
    Configure
    SET UNDO_MANAGEMENT=AUTO
    SET UNDO_RETENTION= ( second need for logger transaction )
    UNDO_RETENTION specifies (in seconds) the low threshold value of undo retention. For AUTOEXTEND undo tablespaces, the system retains undo for at least the time specified in this parameter, and automatically tunes the undo retention period to satisfy the undo requirements of the queries.
    For fixed- size undo tablespaces, the system automatically tunes for the maximum possible undo retention period, based on undo tablespace size and usage history, and ignores UNDO_RETENTION unless retention guarantee is enabled.

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

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

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

  • Undo tablespace increasing

    hello
    my database version is 11.2.0.1.0
    My undo tablespace was around 36 gb and around 4gb was free.
    But now the size is decreasing and it is decreasing fast. What should i do. I increased it by another 2gb. How do i monitor it so that i can tune it without resizing it again.
    please guide me.
    Thanks in advance.

    user12045405 wrote:
    hello
    my database version is 11.2.0.1.0
    My undo tablespace was around 36 gb and around 4gb was free.
    But now the size is decreasing and it is decreasing fast. What should i do. I increased it by another 2gb. How do i monitor it so that i can tune it without resizing it again.
    please guide me.
    Thanks in advance.Decreasing or increasing? It's not an issue but a normal thing since 10g onwards. Please see MOS Doc 413732.1 .
    HTH
    Aman....

  • How to estimate undo tablespace size in 11g?

    I found someone document said, use this sql to estimate undo tablespace:
    select (UR*(UPS*DBS))+(DBS*24) as "bytes" from (select value as UR from v$parameter where name='undo_retention'),(select (sum(undoblks)/sum(((end_time-begin_time)*86400))) as UPS from v$undostat),(select value as DBS from v$parameter where name='db_block_size');
    but in my 11g database, the "select value as UR from v$parameter where name='undo_retention'" is 0. so above sql is always get 196608(8192*24)
    How to estimate undo tablespace size in 11g?
    Thanks very much!

    for undo segments size you should turn it to be autoextend on as well undo management set to be AUTO
    i.e
    undo_managment='AUTO'
    for retention see that link
    Ora-01555, snapshot too old: rollback segment number 2 with name "_SYSSMU1
    BTW as hemant stated leave it to be auto which is good approach but make sure enough space on disk has been
    dedicated for undo segments are allowed to grow to the size they need to be based on the requested undo_retention.
    Khurram                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

Maybe you are looking for