Need to delete large amounts of data from time to time because of work needs
Due to the ability problem, I am afraid to schedule the deletion.
And due to performance issues, only 4G undo tablespace on each node of rac

While deleting data naturally, pay attention to the use of undo tablespace, so as not to cause undo deficiency.

The first thing that is discovered is that companies generally use toad as a third-party management tool.
And found that the use of EM is often less than the use of toad

I am doing delete actions today, and I am constantly facing the situation of using it inside toad.
And see that EM is still within the control range (the remaining undo tablespace capacity is 2-3 times the peak business period)

But through the following statement (general view of the tablespace usage statement)

SELECT B.TABLESPACE_NAME,
       B.TOTAL_MB-NVL(A.FREE_MB,0) USED_MB,   B.TOTAL_MB TOTAL_MB,
       ROUND((B.TOTAL_MB-NVL(A.FREE_MB,0))/B.TOTAL_MB*100,2) USED_PERCENT,
       B.TOTAL_ALLOCATE_MB+NVL(C.NONAUTO,0) MAX_ALLOCATE_MB,
       NVL(B.TOTAL_ALLOCATE_MB,0) AUTO_MB,NVL(C.NONAUTO,0) NONAUTO_MB
  FROM
       (SELECT TABLESPACE_NAME,ROUND(SUM(BYTES)/1048576) FREE_MB
          FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME) A,
       (SELECT TABLESPACE_NAME,ROUND(SUM(BYTES)/1048576) TOTAL_MB, ROUND(SUM(MAXBYTES)/1048576) TOTAL_ALLOCATE_MB
          FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME) B,
       (SELECT SUM(BYTES)/1048576 NONAUTO, TABLESPACE_NAME
          FROM DBA_DATA_FILES
         WHERE MAXBYTES ='0' GROUP BY TABLESPACE_NAME) C
 WHERE A.TABLESPACE_NAME(+)=B.TABLESPACE_NAME
   AND C.TABLESPACE_NAME(+)=B.TABLESPACE_NAME
   AND B.TABLESPACE_NAME LIKE 'UNDO%'
 ORDER BY USED_PERCENT DESC ;

I saw a lot of usage.

TABLESPACE_NAME                   USED_MB   TOTAL_MB USED_PERCENT MAX_ALLOCATE_MB    AUTO_MB NONAUTO_MB
------------------------------ ---------- ---------- ------------ --------------- ---------- ----------
UNDOTBS1                             3885       4100        94.76            4100       4100          0
UNDOTBS2                             3138       4000        78.45            4000       4000          0

Then check if the part is out of date

SELECT DISTINCT STATUS, SUM(BYTES)/1024/1024, COUNT(*)   
FROM DBA_UNDO_EXTENTS GROUP BY STATUS; 

STATUS    SUM(MB)/1024/1024   COUNT(*)
--------- -------------------- ----------
UNEXPIRED            6654.5625       1531
EXPIRED                 347.75        291

The unexpired part is just equal to the undo usage of EM reality.

This is good, as we all know, the expired part can be overwritten (regardless of whether GUARANTEE is set)
After that, you can safely watch EM doing things.

In fact, everyone can use this sentence to see the actual use of undo, I guess EM is also using this sentence

select 
((select (nvl(sum(bytes),0)) 
from dba_undo_extents 
where tablespace_name='UNDOTBS1' 
and status in ('ACTIVE','UNEXPIRED')) *100) / 
(select sum(bytes) 
from dba_data_files 
where tablespace_name='UNDOTBS1') 
"PCT_INUSE" 
from dual; 

 PCT_INUSE
----------
88.1295732

Say a few more sentences
Everyone knows that there is a parameter UNDO_RETENTION indicating the minimum number of undo seconds the system keeps.

SQL> show parameter UNDO_RETENTION

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_retention                       integer     900

However, in the new 10g function, there is a stuff called (AUR), which is to automatically adjust the size of RETENTION according to the undo situation currently used by the system.
Of course, this auto-adjusted value is not less than the value of UNDO_RETENTION
Want to see how much adjustment?

SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
    TUNED_UNDORETENTION FROM V$UNDOSTAT;

And in 10g you can decide whether to enable undo retention guarantee
If it is NOGUARANTEE, then oracle will automatically overwrite Undo without expiration to ensure the smooth execution of DML

alter tablespace undotbs1 retention guarantee;
alter tablespace undotbs1 retention noguarantee;

Another interesting phenomenon is that the undo usage rate is high throughout the night.
Because it is RAC, I do different operations on two nodes, that is, delete different tables.
Later found a very high - close to 90%, so stopped the above operation
But undo did not release, until the operation on the second node was stopped, undo suddenly released all - became expired

SQL> SELECT DISTINCT STATUS, SUM(BYTES)/1024/1024, COUNT(*)     
  2  FROM DBA_UNDO_EXTENTS GROUP BY STATUS;  

STATUS    SUM(BYTES)/1024/1024   COUNT(*)
--------- -------------------- ----------
UNEXPIRED              119.125         16
EXPIRED              6715.1875       1694

References, metalink
FAQ – Automatic Undo Management (AUM) / System Managed Undo (SMU) [ID 461480.1]