今日同事发现他负责的一个数据库服务器出现了异常，症状为UNDOTBS表空间增大，导致磁盘空间不足，其请我协助解决这个问题。
系统是linux的，原则上来讲这个问题其实很好解决，建立新的UNDOTBS表空间，然后让系统默认使用这个表空间，等到切换完毕，删除老的UNDOTBS表空间即可。
但是在实际解决的时候却一波三折，现总结如下：
刚开始的时候给了他一个文档，其内容是如何建立新的UNDOTBS表空间并删除旧的，此文档详见http://blog.csdn.net/wxlbrxhb/article/details/14448777
但是他在使用之后等了一会发现现有的UNDOTBS表空间并未离线。手工执行了离线命令无效，估计此时应该还有数据在处理。
他有些着急，故此建议他重启数据库让后让再开起来这样数据库默认就直接使用新的UNDOTBS表空间了，旧的直接删掉。
但是重启后进入sqlplus开启数据库发现异常：
提示没有权限，有时候oracle没有加入DBA用户组也可能会有权限不足的问题出现，所以让他查了一下，结果发现oracle已经在DBA用户组中了。
看来思路还是不对，不是这个问题。尝试直接使用sqlplus / as sysdba登录，结果如下：
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"
注意到一个提示ORA-09945: Unable to initialize the audit trail file
，无法初始化审计文件。似乎有门，oracle在正常使用的时候会涉及到一个权限的审计问题，一般来讲会创建一个审计的文件在/u01/app/oracle/admin/tnitsora/adump下，正巧今天有空间磁盘空间不足的现象，会不会是因为这个所以无法创建新的审计文件从而导致了无法进入sysdba，并且无法正常启动数据库呢。
抱着这个想法进入了oracle目录，进入了/u01/app/oracle/admin/tnitsora目录下 ，使用du –sh查看各个目录的占用率，发现了问题，bdump居然有24G这也太大了。赶紧删除了bdump下的大部分文件，此时在使用sysdba登录发现已经可以正常登录了，进入之后开启数据库也正常，至此事情暂时告一段落。
Bdump这个目录存放的是后台进程跟踪文件目录，一般来讲这个文件夹下的文件是可以删除的。
同事把应用都起来之后发现新的UNDOTBS表空间增大的很快，半个小时就已经用了8G了，UNDOTBS增大是正常的，但是这也增大的太快了，决定继续分析处理。
先询问了近期是否有对数据库各类参数调整，同事表示没有，但是修改过表结构等方面的东西。一般来讲如果是undo_retention参数设置的时间过大有可能到导致UNDOTBS表空间中有大量未提交的数据从而快速增大，使用show parameter undo进行了查看未见异常。
询问其是否有自动备份数据库的脚本或者程序在运行，其表示没有。又查看了操作大量数据的job，发现和job也没关系，job是晚上执行的。
继续分析，想到如果一个表未做索引，那么他在进行dml时会产生效率很低，也有可能导致UNDOTBS表空间异常增大。一般来说INSERT生成的UNDO最少，因为对于INSERT而言，Oracle 只要记录其对应的一个“删除“行的rowid即可。其次就是UPDATE 操作，对于该操作而言，只记录修改的字节；通常，在多数情况下，我们只修改行的一小部分，那么，UNDO会将该部分记录。相对上述两种操作，DELETE操作会生成最多的UNDO，因为Oracle必须把整行的前影像都记录到了undo段中。
请按着我这边一个未出问题的数据库的表结构对比了数据量较大的几个表，发现索引都一样未见异常，奇怪了问题出在哪里？
在网上早来一段检查回滚段事务情况的语句
SELECT r.NAME 回滚段名,s.sid SID,s.serial# Serial,
s.username 用户名,s.machine 机器名,
t.start_time 开始时间,t.status 状态,
t.used_ublk 撤消块,USED_UREC 撤消记录,
t.cr_get 一致性取,t.cr_change 一致性变化,
t.log_io "逻辑I/O",t.phy_io "物理I/O",
t.noundo NoUndo,g.extents Extents,substr(s.program, 1, 50) 操作程序
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
发现有个进程一直在使用回退段，且已经执行了2个多小时了，状态还是active
查看到进程的名字为FAKE_xxx_ xxx _ xxx.exe，估计问题就出在他身上。将这个程序关闭之后再次检查UNDOTBS表空间，此时UNDOTBS表空间的增大情况已经减小，数据库回复正常。