Steadily Increasing UNDO but "seems" no process using the UNDO.!

Question

Hi All,
I've been reading some materials to solve this issue on our database (Oracle 11.2.0.3.0) . The problem is that we have been increasing UNDO from 35G to almost 60G now. and it is still increasing in usage. But I cannot detect any transaction using the undo. If you have any insights, that will be great. Below are the information I have gathered.
Datafiles are not autoextensible.
FILE_NAME                                                    BYTES/1048576 AUT MAXBYTES/1048576
****/undotbs1.260.802515529              31744 NO                 0
****/undotbs1.270.828813025              28672 NO                 0
Some undo parameters.
SQL> show parameter undo
NAME                                 TYPE        VALUE
undo_management                      string      AUTO
undo_retention                       integer     1800
undo_tablespace                      string      UNDOTBS1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
           19628
SQL> select max(undoblks) from v$undostat;
MAX(UNDOBLKS)
         9706
I cannot detect any transaction using the UNDO except for a MERGE statement that has been running for almost 3 weeks but it does not show up on the UNDO except for this Toad.exe. Could it be that there were some transactions not commited on the App side?
SID_SERIAL      ORAUSER    PROGRAM                                  UNDOSEG                   Undo
1265,47681            ENGI Toad.exe                                 _SYSSMU11_3724053292$     0K
Rollback                             Size                                        Undo            Com-              Command
Segment                             Kbyte Waits Extents   SID Username        records     LOG_IO mand MODULE       desciption
SYSTEM                                376     0       6
_SYSSMU1_2397580260$            1,116,152     7     202
_SYSSMU2_2704140093$            1,179,768     9     195
_SYSSMU3_2176824562$            1,185,912     6     115
_SYSSMU4_403671272$             1,120,376    11     185
_SYSSMU5_3141210127$            1,121,336     9     206
_SYSSMU6_3100186656$            1,184,760    10     203
_SYSSMU7_3622910069$            1,250,360     7     206
_SYSSMU8_1575691382$            2,823,288    11     220
_SYSSMU9_2782336430$            2,796,664    56     165
_SYSSMU10_1843652744$           3,331,184   261     580
_SYSSMU11_3724053292$           2,797,688   641      51  1265 TARIFFENGINE          0         13    0 TOAD 11.5.0. Unknown
                                                                                                      56
Thanks..

Answer 1

Hi Guys,
I found something. Below is the value of our tuned_undoretention ( too high which is 192 hrs or 8 days ).
SQL> select max(maxquerylen),max(tuned_undoretention) from v$undostat;
MAX(MAXQUERYLEN) MAX(TUNED_UNDORETENTION)
19628 691838
Here is our space for UNDO ( total of 60416 MB or 59G).
FILE_NAME                                                    BYTES/1048576 AUT MAXBYTES/1048576
***/undotbs1.260.802515529                                           31744 NO 0
***/undotbs1.270.828813025                                           28672 NO 0
Most of the space of the UNDO is consumed by the UNEXPIRED ( probably because of high tuned_undoretention? ). The ACTIVE are only 64MB.
SQL> select sum(bytes /(1024*1024)) from dba_undo_extents where status='EXPIRED';
SUM(BYTES/(1024*1024))
5914.4375
SQL> select sum(bytes /(1024*1024)) from dba_undo_extents where status='ACTIVE';
SUM(BYTES/(1024*1024))
64.0625
SQL> select sum(bytes /(1024*1024)) from dba_undo_extents where status='UNEXPIRED';
SUM(BYTES/(1024*1024))
42589.25
I came across this doc from metalink – “Master Note: High Undo Space Usage (Doc ID 1578639.1).” THANK YOU srini_Chavali
Within Master Note: High Undo Space Usage (Doc ID 1578639.1) there is a link to – “Automatic Tuning of Undo_retention Causes Space Problems (Doc ID 420525.1)” that discusses a possible workaround on this issue.
Thanks