The lack of space in the issue of undo table space Anomaly Enlargement

Today, colleagues found that he was responsible for a database server has an exception, the symptoms of UNDOTBS table space, resulting in insufficient disk space, which asked me to help resolve this problem.
System is Linux, in principle, this problem is actually very good to solve, the establishment of a new Undotbs table space, and then let the system default to use this table space, wait until the switch is complete, delete the old Undotbs table space can be.
But in the actual solution of the time but twists, now summarized as follows:
At first he gave him a document on how to create a new Undotbs tablespace and delete the old one, as detailed in this document http://blog.csdn.net/wxlbrxhb/article/details/14448777
But he waited after the use. The existing Undotbs table space is not offline. Manual execution of the offline command is not valid, and it is estimated that there should be data processing at this time.

He was in a hurry, so he suggested that he restart the database so that it can be opened again so that the database is directly using the new Undotbs table space by default, the old directly deleted.
But after rebooting, enter Sqlplus to open the database to discover the exception:

Prompt does not have permissions, sometimes Oracle does not join the DBA user group may also have the problem of insufficient permissions to appear, so let him check, and found that Oracle is already in the DBA user group.

It seems that the idea is still wrong, not the problem. Try to log in directly using Sqlplus/as SYSDBA, with the following results:
Sql> ora-09945:unable to initialize the audit trail file
Linux Error:28:no space left on device
Sql>
./dbstart:database instance "Tnitsora" warm started.

/u01/app/oracle/product/10.2.0/db_1/bin/dbstart:starting Up Database "Tnitsora"
Notice a hint ora-09945:unable to initialize the audit trail file
, the audit file could not be initialized. There seems to be a door, Oracle in normal use will involve a permission audit problem, generally will create an audit of the file under the/u01/app/oracle/admin/tnitsora/adump, happened to have a lack of space disk space today, Could it be that this is why it is not possible to create a new audit file resulting in a failure to enter SYSDBA and not start the database properly.
Holding this idea into the Oracle directory, into the/u01/app/oracle/admin/tnitsora directory, using Du–sh to view the occupancy rate of each directory, found the problem, Bdump incredibly have 24G this is too big. Hurriedly deleted Bdump under the majority of files, at this time in the use of SYSDBA login found can be normal login, enter after the database is also normal, this thing temporarily.
Bdump This directory is the background process trace file directory, in general, the files under this folder can be deleted.

Colleagues put the application up and found that the new Undotbs table space increased quickly, half an hour has been used 8G, Undotbs increase is normal, but this also increased too fast, decided to continue to analyze processing.
First asked whether there are various parameters of the database adjustment, colleagues said no, but modified the table structure and other aspects of things. In general, if the time of the undo_retention parameter is too large, it is possible to quickly increase the amount of uncommitted data in the Undotbs table space, using show parameter undo to see no exceptions.

Ask if it has a script that automatically backs up the database or if the program is running, and it says no. Also looked at the operation of a large number of data, the discovery and job does not matter, the job is performed at night.

Continued analysis, thinking that if a table is not indexed, then he will be inefficient in the DML, but also may cause UNDOTBS table space abnormally increase. In general, insert generates the least undo, because for insert, Oracle simply records the ROWID of one of its corresponding "delete" rows. The next is the update operation, in which only the modified bytes are recorded; Generally, in most cases we only modify a small portion of the row, and undo will record that part. With these two actions, the delete operation generates the most undo, because Oracle must record the entire line's front image in the undo segment.
Please press on my side the table structure of a database that has no problem compares a few tables with a large amount of data, and finds that the indexes are all the same without seeing anomalies.
Come early on the Internet a section to check the rollback segment transaction condition statement
SELECT r.name rollback segment name, S.sid sid,s.serial# serial,
S.username user name, S.machine machine name,
T.start_time start time, t.status status,
T.USED_UBLK undo Block, Used_urec undo record,
T.cr_get consistency Take, t.cr_change consistency change,
T.log_io "Logical I/O", t.phy_io "physical I/O",
T.noundo noundo,g.extents extents,substr (S.program, 1, 50) Operating Procedures
From V$session S, V$transaction T, V$rollname R,v$rollstat G
WHERE t.addr = s.taddr
and T.xidusn = R.usn
and R.usn = G.usn
ORDER by t.used_ublk Desc
Found that a process has been using the fallback segment and has been executing for 2 hours, state or active

View to the process of the name Fake_xxx_ xxx _ Xxx.exe, estimating the problem on his body. After this program is closed again check the Undotbs table space, the Undotbs table space has been reduced, the database back to normal.

The lack of space in the issue of undo table space Anomaly Enlargement