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

Similar Messages

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

  • PSAPSR3 Tablespace is only growing very fast in PROD

    Dear All,
    In our Prod Server  -> PSAPSR3 Tablespace is only growing very fast (Note : with 5 days i have extened 2 time PSAPSR3 table space) .
    let me know the permament solution is only extending table space ? or any alternate solution to control specific table space growth ?
    pls check DB02 Table space details :
    PSAPSR3     219,640.00     10,010.81     95     YES     220,000.00     10,370.81     95     22     157,305     226,884     ONLINE     PERMANENT
    PSAPSR3700     71,120.00     3,506.75     95     YES     170,000.00     102,386.75     40     17     868     11,389     ONLINE     PERMANENT
    PSAPSR3USR     20.00     1.94     90     YES     10,000.00     9,981.94     0     1     38     108     ONLINE     PERMANENT
    PSAPTEMP     4,260.00     4,260.00     0     YES     10,000.00     10,000.00     0     1     0     0     ONLINE     TEMPORARY
    PSAPUNDO     10,000.00     8,391.44     16     NO     10,000.00     8,391.44     16     1     20     498     ONLINE     UNDO
    SYSAUX     480.00     22.88     95     YES     10,000.00     9,542.88     5     1     991     2,633     ONLINE     PERMANENT
    SYSTEM     880.00     5.44     99     YES     10,000.00     9,125.44     9     1     1,212     2,835     ONLINE     PERMANENT
    Kindly advise

    Dear MHO/Sunil/Eric,
    still the PSAPSR3 tablespace keep on growing ,
    Pls check the DB02 ,segments details .
    SAPSR3     BALDAT          TABLE     PSAPSR3     42,622.000     268.800     853     5,455,616
    SAPSR3     SYS_LOB0000072694C00007$$          LOBSEGMENT     PSAPSR3     5,914.000     191.533     277     756,992
    SAPSR3     CDCLS          TABLE     PSAPSR3     9,091.000     38.400     327     1,163,648
    SAPSR3     SYS_LOB0000082646C00006$$          LOBSEGMENT     PSAPSR3     1,664.000     37.067     209     212,992
    SAPSR3     BALDAT~0          INDEX     PSAPSR3     5,049.000     32.000     266     646,272
    SAPSR3     EDI40          TABLE     PSAPSR3     3,155.000     23.467     233     403,840
    SAPSR3     CDCLS~0          INDEX     PSAPSR3     1,965.000     19.200     214     251,520
    SAPSR3     BDCP2~001          INDEX     PSAPSR3     1,543.000     18.400     208     197,504
    SAPSR3     BDCPS~1          INDEX     PSAPSR3     4,039.000     17.067     247     516,992
    SAPSR3     APQD          TABLE     PSAPSR3     1,671.000     17.067     210     213,888
    SAPSR3     CDHDR~0          INDEX     PSAPSR3     2,183.000     12.800     218     279,424
    SAPSR3     CDHDR          TABLE     PSAPSR3     2,305.000     12.800     220     295,040
    SAPSR3     BDCP2~0          INDEX     PSAPSR3     1,000.000     12.533     196     128,000
    SAPSR3     ZBIPRICING~0          INDEX     PSAPSR3     320.000     10.600     111     40,960
    SAPSR3     WRPL          TABLE     PSAPSR3     288.000     8.700     107     36,864
    SAPSR3     FAGL_SPLINFO          TABLE     PSAPSR3     1,016.000     8.000     198     130,048
    SAPSR3     FAGL_SPLINFO_VAL~0          INDEX     PSAPSR3     736.000     8.000     163     94,208
    SAPSR3     ZBIPRICING          TABLE     PSAPSR3     208.000     6.931     97     26,624
    SAPSR3     MARC~Y          INDEX     PSAPSR3     176.000     5.533     93     22,528
    SYS     WRH$_ACTIVE_SESSION_HISTORY     WRH$_ACTIVE_2349179954_18942     TABLE PARTITION     SYSAUX     6.000     5.375     21     768
    SAPSR3     MARC~VBM          INDEX     PSAPSR3     152.000     4.867     90     19,456
    SAPSR3     MARC~D          INDEX     PSAPSR3     136.000     4.367     88     17,408
    SAPSR3     FAGLFLEXA          TABLE     PSAPSR3     2,052.000     4.267     216     262,656
    SAPSR3     RFBLG          TABLE     PSAPSR3     3,200.000     4.267     233     409,600
    SAPSR3     BDCPS          TABLE     PSAPSR3     1,280.000     4.267     203     163,840
    SAPSR3     BDCP~POS          INDEX     PSAPSR3     3,392.000     4.267     236     434,176
    SAPSR3     BALHDR          TABLE     PSAPSR3     864.000     4.000     179     110,592
    SAPSR3     FAGL_SPLINFO~0          INDEX     PSAPSR3     361.000     3.767     117     46,208
    SAPSR3     ACCTIT          TABLE     PSAPSR3     289.000     3.733     108     36,992
    SAPSR3     WRPT~0          INDEX     PSAPSR3     112.000     3.731     85     14,336
    SAPSR3     FAGL_SPLINFO_VAL          TABLE     PSAPSR3     448.000     3.467     127     57,344
    SAPSR3     COEJ          TABLE     PSAPSR3     1,089.000     3.200     201     139,392
    SAPSR3     ZBISALEDATA3          TABLE     PSAPSR3     176.000     3.200     93     22,528
    SAPSR3     COEP~1          INDEX     PSAPSR3     927.000     3.167     187     118,656
    SAPSR3     GLPCP          TABLE     PSAPSR3     891.000     2.933     183     114,048
    SAPSR3     ZBISALEDATA          TABLE     PSAPSR3     376.000     2.933     118     48,128
    SAPSR3     WBBP          TABLE     PSAPSR3     344.000     2.933     114     44,032
    SYS     WRH$_ACTIVE_SESSION_HISTORY     WRH$_ACTIVE_2349179954_18918     TABLE PARTITION     SYSAUX     6.000     2.594     21     768
    SAPSR3     FAGL_SPLINFO~1          INDEX     PSAPSR3     280.000     2.400     106     35,840
    SAPSR3     SE16N_CD_DATA          TABLE     PSAPSR3     72.000     2.333     80     9,216
    SAPSR3     KONH          TABLE     PSAPSR3     1,373.000     2.133     207     175,744
    SAPSR3     GLPCA          TABLE     PSAPSR3     2,437.000     2.133     222     311,936
    SAPSR3     BDCP~0          INDEX     PSAPSR3     1,863.000     2.133     213     238,464
    SAPSR3     SYS_LOB0000161775C00013$$          LOBSEGMENT     PSAPSR3700     5,210.000     2.133     266     666,880
    SAPSR3     BDCPS~0          INDEX     PSAPSR3     2,496.000     2.133     222     319,488
    SAPSR3     D010TAB          TABLE     PSAPSR3700     2,176.000     2.133     217     278,528
    SAPSR3     COEP          TABLE     PSAPSR3     2,117.000     2.133     217     270,976
    SAPSR3     FAGLFLEXA~0          INDEX     PSAPSR3     808.000     2.133     172     103,424
    SAPSR3     BSIS          TABLE     PSAPSR3     1,734.000     2.133     211     221,952
    SAPSR3     BSAS          TABLE     PSAPSR3     1,650.000     2.133     210     211,200
    SAPSR3     GLPCA~3          INDEX     PSAPSR3     382.000     1.867     119     48,896
    SAPSR3     BKPF          TABLE     PSAPSR3     1,012.000     1.867     198     129,536
    SAPSR3     FAGLFLEXA~3          INDEX     PSAPSR3     744.000     1.867     164     95,232
    SAPSR3     FAGLFLEXA~2          INDEX     PSAPSR3     661.000     1.867     154     84,608
    SAPSR3     WRPL~001          INDEX     PSAPSR3     112.000     1.867     85     14,336
    SAPSR3     WRPL~0          INDEX     PSAPSR3     112.000     1.667     85     14,336
    SAPSR3     PCL2          TABLE     PSAPSR3     1,000.000     1.600     196     128,000
    SAPSR3     GLPCA~2          INDEX     PSAPSR3     345.000     1.600     115     44,160
    SAPSR3     FAGL_SPLINFO~3          INDEX     PSAPSR3     136.000     1.600     88     17,408
    SAPSR3     MARC~WRK          INDEX     PSAPSR3     160.000     1.600     91     20,480
    SAPSR3     MSEG          TABLE     PSAPSR3     136.000     1.600     88     17,408
    SAPSR3     ZBISALEDATA~0          INDEX     PSAPSR3     208.000     1.600     97     26,624
    SAPSR3     ZBISALEDATA3~0          INDEX     PSAPSR3     195.000     1.500     96     24,960
    SYS     WRH$_ACTIVE_SESSION_HISTORY     WRH$_ACTIVE_2349179954_18894     TABLE PARTITION
    Kindly suggest

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

  • 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

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

Maybe you are looking for