UNDO Tablespace is used to fill frequently

Hi Experts,
We have an issue with the UNDO tablespace frequently,where we dont see the space occupied for any active transactions and i can see only for "Retained for Use by Queries or Flashback" i.e. more than 2000M.
Can any one let me know how to purge this space and to free up the undo tablespace.
FYI -
Oracle Ver:10.2.0.2
OS :SUN OS
Undo Retention : 30 Mins.
Undo tblspace size:3G
undo_management:AUTO
Thanks Much!!
Senthil

Hi,
I think your undo tablespace contains data for inactice transactions and this is mainly because of higher value of undo_retention parameter.
This space will be overwritten automatically as and when the space will be required by the current transaction.
Thanks,
Navneet

Similar Messages

  • Undo Tablespace

    Hi,
    For one of the database, Undo tablespace has reached upto 2.5GB. I have created one more undo tablespace. If users are frequently commiting the transactions, why it is increasing. It is a development database.
    Can I delete the undo tablespace, once I conclude that the transactions are using the new undo tablespace?
    Pls guide me.
    Thanks,
    Raj

    Hi,
    Before going to recreate the undo tablespace calculate the optimal sizing undo and create make changes as per nedd.
    Read below post.... This may helps you....
    Undo growth
    Regards,
    Karthik

  • Undo Tablespace Retention gurantee

    Hi,
    From what I have read about undo Tablespaces ,If Undo Management is AUTO,and Retention is se to say 15 min and retention gurantee is disabled ,Unexpired transactions can be overwritten by the database,If such is the case then undo tablespace should never get filled up.
    But I have observed despite these settings,Undo tablespace filling issue still occurs.
    Please help me understand this.
    Thanks.

    Either
    1. Your undo tablespace datafile is small (inadequate for the volume of transactions)
    OR
    2. Oracle is using autotuneundo which causes it to retain Undo for longer than undo_retention period and use the undo tablespace datafile to the fullest.
    See Oracle Support notes
    "Oracle 10G new feature - Automatic Undo Retention Tuning [ID 311615.1] "
    "Bug 5387030 - Automatic tuning of undo_retention causes unusual extra space allocation [ID 5387030.8] "
    "Bug 5387030"
    Hemant K Chitale

  • 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

  • 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

  • What is the difference between undo tablespace and online redo log files.

    what is the difference between undo tablespace and online redo log files. I am confused
    as per my knowledge undo tablespace is used to store the undo information when a table is being updated so that, just incase we need to rollback a transaction we know what was present in the table earlier.
    when a transaction fails the SMON performs the rollback of the data.
    This undo data is stored in the undo tablespace and read consistency if any is enforced.
    is my understanding till here correct?
    Now, can this undo data/before image not be stored in the redo log buffer and online redolog files?
    can redo-log files not store this information?
    in fact, is it that when undo tablespaces exist in a database, the undo data/before image is stored in both the undo tablespace and also the redo log files?
    kindly clarify my doubt.
    thank you.

    This question has been asked many times before. The answer is always the same.
    Yes, redo contains the before image of data (and the after-image). Therefore, it **COULD** be used to roll back a transaction.
    BUT... Redo is written sequentially. Using it to rollback your transaction would involve reading through all the redo written by maybe thousands of other people. It would be painfully slow.
    Your transaction is, however, directly linked to just the UNDO that it generates (which is JUST the before image of the data). So, your undo is your undo and doesn't share space with anyone else's undo. Therefore, using it to roll back YOUR transaction is fast.
    The fact that undo is only the before image of the data also makes it faster than wading through a sea of before and AFTER images as you'd find in redo. About twice as fast, in fact, since there's half the data. Roughly.
    Redo also gets written and flushed to disk whenever there's a commit, 3 seconds are up or too much (1MB, actually) redo gets generated between flushes caused by other factors. Your redo gets flushed when those things happen, even if you haven't actually committed your transaction. And redo logs recycle themselves, meaning that your redo -even if your transaction hasn't been committed yet- can be over-written by later transactions. Try rolling back when that's happened, if redo was the source of your rollback data!
    Undo, however, cannot be over-written if the transaction has not been committed. Ever. If you don't commit for three years, there will be three years' undo stored in your database (assuming you had the space, of course!).
    I could go on, but that will do. Redo is there fore RECOVERY, after catastrophe. Undo is there for read-consistency (and the occasional change of mind). Two different functions. Two different mechanisms. Each one highly tuned to doing what it does, why it does it, most efficiently and effectively.

  • Oracle DB : UNDO tablespace filled 99%

    Hi,
    That's not a problem (I hope) but just a question on Livecycle ES DataBase.
    The Undo tablespace set to 4Gb, always filled 99%.
    Is it normal ? is there preconized size for it ? Does we have to maintain it ...
    The LiveCycle configuration is :
    ES (1) version 8.2.1 SP3, Jboss
    Oracle 10g
    The server is running on Windows Server 2003 Ent OS.
    Thank you for your response !

    It very much depends on the tool used to determine the usage of the UNDO tablespace. Many tools do not take into account that the UNDO tablespace and the TEMP tablespace may seem to be full (have correctly formatted blocks) while still having a lot of functional space available inside of those blocks.
    In other words, if the tool calculates the usage in the same way as data tablespaces, it will be reporting the wrong value. Ideally, the UNDO tablespace will always be close to 100% full using traditional calculation.
    Assuming the tool is doing it's calculation correctly, the second thing to note is that UNDO is the core to Oracle Consistent Read mechanism. (Which is, in turn, the core to many of the Flashback techniques.) The UNDO data, which is created at transaction time, must be available after the transaction has committed if a consistent read or flashback is invoked. The more UNDO, the further back in 'time' you can flash back.
    So the correct way to tune the UNDO is to specify the amount of time you require UNDO to exist. And you verify that using the DBA_UNDO_EXTENTS view and the STATUS column. Totally free space in the undo occurs when the STATUS is EXPIRED. If you have no EXPIRED extents, they can not be reused (except in a pinch) and the system will allocate more space to the UNDO tablespace if possible.
    A great reference is the thread at http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6894817116500
    I am curious - is 4GB UNDO really an issue?

  • SQL Statement using Undo Tablespace

    Hi
    Is there a way to find out which SQL Statement is using the highest amount of Undo Tablespace ?

    Query v$undostat.
    Use column "MAXQUERYID" for identgifying long running queries.
    Refer Metalink Note 262066.1 for undo information.
    Regards
    Sethu

  • How to exclude undo and temp from "Tablespace Space Used (%)"

    Dear All
    Is it possible to exclude undo and temp tablespace monitoring from "Tablespace Space Used (%)" matric?
    Thanks & Regards
    Quazi Abdur Rab

    If you use TEMP >=100 as Warning, this warning can still be raised.
    What version of the database is it? If Oracle 10g, Grid Control (the agent) searches the alert table in the database for alerts, so the database raises the alert and the agent just passes this alert to Grid Control.
    If you are using Oracle 10g, you can use the following statement (connected as sys):
    DBMS_SERVER_ALERT.SET_THRESHOLD(
    metrics_id => DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,
    warning_operator => DBMS_SERVER_ALERT.OPERATOR_GT,
    warning_value => '90',
    critical_operator => DBMS_SERVER_ALERT.OPERATOR_GT,
    critical_value => '100',
    observation_period => 1,
    consecutive_occurrences => 1,
    instance_name => NULL,
    object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
    object_name => 'TEMP');
    This will create the GT (Greater Than) instead of GE (Greater Equal).
    Kind regards,
    Dave
    ps. I'm using GC 10.2.0.3.0, so thanks for the note that 10.2.0.4 doesn't take 100+ values.

  • UNDO tablespace reaching maximum size - WHO is using it?

    My UNDO tablespace has been pretty static for a while but this morning it was at 93% and within 20 minutes I saw it at 98%. I added a datafile to buy some time, but is there any way I can identify specific sessions which may be filling it rapidly ?
    Thanks

    Thank you Pierre! I must have missed that particular piece. Mind you, it was a rather long thread!
    select sum(used_ublk) from v$transaction
    This now works..
    SELECT   SUBSTR (terminal, 1, 10) terminal, SUBSTR (osuser, 1, 15) osuser,
             SUBSTR (SID, 1, 3) SID, SUBSTR (username, 1, 18) username,
             SUBSTR (program, 1, 30) program,
             TO_CHAR (logon_time, 'DD/MM/YYYY HH24:MI:SS') logon_time,
             SUBSTR (command, 1, 20) command, SUM (used_ublk) undo_used
        FROM (SELECT   s.terminal, s.osuser, s.SID, s.username, s.program,
                       s.logon_time,
                       DECODE (s.command,
                               0, 'No Command',
                               1, 'Create Table',
                               2, 'Insert',
                               3, 'Select',
                               6, 'Update',
                               7, 'Delete',
                               9, 'Create Index',
                               15, 'Alter Table',
                               21, 'Create View',
                               23, 'Validate Index',
                               35, 'Alter Database',
                               39, 'Create Tablespace',
                               41, 'Drop Tablespace',
                               40, 'Alter Tablespace',
                               53, 'Drop User',
                               62, 'Analyze Table',
                               63, 'Analyze Index',
                               s.command || ': Other'
                              ) command,
                       used_ublk
                  FROM v$session s,
                       v$process p,
                       v$transaction t,
                       v$rollstat r,
                       v$rollname n
                 WHERE s.paddr = p.addr
                   AND s.taddr = t.addr(+)
                   AND t.xidusn = r.usn(+)
                   AND r.usn = n.usn(+)
              ORDER BY 1)
    GROUP BY terminal, osuser, SID, logon_time, username, program, command
      HAVING SUM (used_ublk) > 0
    ORDER BY SUM (used_ublk) DESC

  • Drop rollback tablespace after using UNDO

    I have switched to using UNDO instead of using rollback segments. The UNDO works fine, and I have sucessfully dropped all rollback segments. Now I try to drop rollback tablespace. Can I simplely issue drop tablespace command to drop it? the reason I hesitate to simply drop it is that before I do drop, I placed the rollback tablespace offline. And there are errors during transaction since some tables somehow still checking on this tablespace. Can I simplely drop rollback tablespace, and Oracle would clean this internally, and everything would be finr?
    thanks for your input.

    Hi,
    This is the steps to migration from rollback tablespace to undo tablespace (from 8i to 9i migration by manual upgrade) :
    SQL>alter system set undo_management=auto scope=spfile;
    SQL>create UNDO tablespace UNDOTBS  datafile ‘d:\database\mydb\system\undotbs01.dbf’ size 500M;
    SQL>alter system set undo_tablespace= UNDOTBS  scope=spfile;
    SQL>shutdown immediate
    SQL>startup
    SQL>select SEGMENT_NAME,TABLESPACE_NAME,STATUS from dba_rollback_segs; --Verirify creation and usage UNDO tablespace
    SQL>drop tablespace rbs including contents and datafiles;
    SQL>create pfile=’d:\database\mydb\system\pfile\init.ora’ from spfile;No need to drop old rollback segment.
    Nicolas.

  • Rollback segments using UNDO Tablespace?

    First, I created a database for a vendor with an Undo Tablespace UNDOTBS. Then the vendor requested me to create rollback segments instead. So I created a new tablespace RBSTBS just to hold these segments. When I tried to create the rollback segment using the newly created tablespace RBSTBS, it complained that I am not allowed to use non-system tablespaces.
    So instead, I used the Undo tablespace UNDOTBS to hold the rollback segment. It worked.
    Am I really allowed to use the UNDO tablespace to hold rollback segments? Can't I use normal tablespaces for rollback segments?
    Another thing, the vendor wanted me to create rollback segments of 200MB each. Where do I set this while creating the rollback segment? Is this the INITIAL, NEXT, or OPTIMAL size?
    I know that Oracle recommends using UNDO rather than rollback segments. Is there any advantage in using traditional rollback segments?
    Thanks for any help!

    Advantage with rollback segment is you can force your transaction to use any specific rollback segment, where as with undo you don't have any control. Oracle does it for us.
    Thanks and Regards,
    Satheesh Babu.S
    Bangalore.

  • If I have two undo tablespace, under what situation oracle will use another

    if I have two undo tablespaces, under what situation oracle will use another
    one is default undo tablespace, another is created manually
    will it use it when the default one is full?
    it seem like to be it won't use the second undo tablespace.
    thanks
    Edited by: user11402556 on Jul 3, 2010 2:18 PM

    You can have two Undo Tablespaces created with the CREATE UNDO TABLESPACE syntax.
    However, the current database instance will use the Undo Tablespace specified by the instance level parameter undo_tablespace.
    When you want to switch the datafiles of an undo tablespace from, say, one mount point to another (or when you want to "resize" an undo tablespace that has grown very large for specific one-off / adhoc jobs), you would create another undo tablespace, reset the instance level parameter to the new undo tablespace and wait for a decent interval (e.g. at least undo_retention or autotuned undo retention) before dropping the old undo tablespace.
    So yours is not a hypothetical question. Having two undo tablespaces is a real-world practice -- but the two are concurrently present for only a short duration, while transactions and queries switch from one to the other.
    (In RAC, each database instance must have it's own Undo tablespace as well).
    Hemant K Chitale

  • UNDO Tablespace :: Who is using how much of it ?

    Hallo,
    I'd like to know who is using how many blocks of the undo-tablespace.
    I know there's a view called v$undostat, but how to link this information to user, sql or session ?
    Regards,
    Mynz

    Execute the following query to determine who is using a particular UNDO or Rollback Segment:
    SQL> SELECT TO_CHAR(s.sid)||','||TO_CHAR(s.serial#) sid_serial,
    2 NVL(s.username, 'None') orauser,
    3 s.program,
    4 r.name undoseg,
    5 t.used_ublk * TO_NUMBER(x.value)/1024||'K' "Undo"
    6 FROM sys.v_$rollname r,
    7 sys.v_$session s,
    8 sys.v_$transaction t,
    9 sys.v_$parameter x
    10 WHERE s.taddr = t.addr
    11 AND r.usn = t.xidusn(+)
    12 AND x.name = 'db_block_size';
    SID_SERIAL ORAUSER PROGRAM UNDOSEG Undo

  • 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

Maybe you are looking for