有时候在一些实际项目中会遇到回滚文件异常增大的情况，一般来说都是由于大事务造成的，而如何找出这个大事务对应的操作则是比较关键的问题。达梦其实提供了关于回滚段相关的动态性能视图，V$PSEG_COMMIT_TRX会记录已经提交但还没有purge的事务信息，而V$PSEG_ITEMS 则会记录回滚系统中相应回滚项的信息，也就是正在执行的事务对应的回滚信息。
以下sql帮助我们在大事务提交后分析确定出对应的sql操作，仅限从事务提交后，回滚purge之前，因为一旦超过undo_retention后v$pseg_commit_trx中对应登记的事务信息就被清除了：

select
        i.n_used_pages*page/1024/1024 used_roll_space_MB,
        h.top_sql_text                          ,
        p.item_nth,
        p.trx_id,
        p.cmt_time,
        h.affected_rows
from
        v$pseg_commit_trx p,
        v$sql_history h    ,
        (select top 1 * from v$pseg_items order by n_used_pages desc) i
where
        p.trx_id=h.trx_id
    and i.nth   =p.item_nth
    and i.n_used_pages>0
    and affected_rows >0
    order by used_roll_space_MB desc;
复制

在做增删改查操作过程中，v$pseg_items使用到的页数是动态在增加的，但是对应的nth_item必须在此事务提交后才能在v$pseg_commit_trx中捕获到，而需要找到对应这个耗费回滚段空间的sql必须先获取到对应的trx_id，才能在v$sql_history或log_commit日志中找到对应sql，故在大事务执行过程中无法抓到对应sql操作，只要当大事务提交后才能抓到对应sql以及它使用过的roll空间大小；
需要注意的是，v$pseg_items记录的是回滚项对应正在使用的pages，而繁忙的生产系统其中一个回滚项（默认一个实例有17个回滚项）可能会有多个I/D/U操作都已提交但还没有被purge（例如还没有到undo_retention时间），所以这个联合查询查出来对应是一个回滚项中多个还没有来得及被purge的事务所占用的回滚空间总大小，具体是哪个sql还需具体分析，但这时已经把范围缩到很小了比较容易确定是哪个sql操作引发的。值得注意的是，我们不能完全按照影响行数来判断，因为call的影响行数记录值永远是1，无法得知真实影响行数；
下面举个栗子说明一下：
1.首先查看17个回滚项对应的信息，主要关注u_used_pages字段

select * from v$pseg_items;
复制

2.然后查看以下测试表T3占用空间情况：

3.执行delete操作，删除10,230,000条记录

4.再查看v$pseg_items发现nth_item=10对应使用了12522个page
我们可以换算一下,12522*32k/1024/1024=391MB，比T3表实际占用空间要稍微小一些，考虑到其他的一些空间消耗，作为查找占用回滚段空间的操作是没有问题的。

5.commit提交后，使用上述sql进行查询对应的事务操作：

上述方法虽然只能在事务提交后，且回滚purge前查到，但大事务造成的回滚文件大小增加都会相当迅猛，所以我们可以配合监控回滚文件大小来使用，则可以更加精准找到对应大事务操作。

注意：
当出现大事务时，log_commit日志中一定会出现大量分配回滚段的信息：

而当大事务执行完并commit后，经过UNDO_RETENTION时间后，日志一定会出现大量purge操作，与此同时我们可以发现，做purge这个操作对应的trx_id记录的就是当初大事务的trx_id：