在一体机X5-2S上遇到了该错误，起初以为是undo表空间不足。增加undo表空间。结果还是报该错误。
最后在mos上面找到这篇文档：IF: ORA-1628 Reported During Long Running Transactions (文档 ID 1951032.1)
Related Issues:
Long running transactions encounter ORA-1628 mostly due to the small extents allocated to the Undo tablespace. The Undo tablespace fragmentation can also be a cause. Refer to Doc ID 1951032.1 for details.
ORA-1628 can be reported for small transactions too. This can happen when the undo tablespace is fragmented or there is space crunch in the undo tablespace. High value of TUNED_UNDORETENTION also cause ORA-1628 error. Refer to Doc ID 1951033.1 for details.
ORA-1628 error during Import can be resolved by setting some IMPDP parameters. Refer to Doc ID 1955310.1 for details
有三个相关联的原因：
1.太多的小事务，分配太多小的undo extent。达到了32765个extents
2.undo_retention调整得过大。导致undo表空间不够用
3.impdp导入时候，可能发生。
生产环境中，我碰到的是第一类情况，小事务太多。怎样定位小事务
1.确定小的事务分配的undo段
SELECT b.usn,
tablespace_name,segment_name,
bytes "Extent_Size",
count(extent_id) "Extent_Count",
bytes * count(extent_id) "Extent_Bytes"
FROM dba_undo_extents a ,v$rollname b
WHERE status = 'ACTIVE'
and a.SEGMENT_NAME=b.name
group by b.usn,tablespace_name,segment_name, bytes
order by count(extent_id) desc;
2.确定会话事务（需要两个节点各自执行v$rollname,显示单节点的）
select a.inst_id,a.sid, a.serial#,b.XIDUSN,a.SQL_ID, a.username, b.used_urec, b.used_ublk*8/1024/1024 G
from gv$session a, gv$transaction b
where a.saddr=b.ses_addr
and a.inst_id=b.inst_id
and xidusn=&usn
order by used_ublk desc
解决方法：
1.可以应用event="64000 trace name context forever, level 25"该事件，同时应用补丁17306264
2.按照给出sql语句定位小事务的相关应用。然后让开发人员修改程序
参考资料：
IF: ORA-1628 reported due to Undo tablespace fragmentation - Bug 17306264 (文档 ID 1951022.1)
Troubleshooting ORA-1628 - max # extents (32765) reached for rollback segment <SEGMENT_NAME> (文档 ID 1580182.1)
IF: ORA-1628 Reported Even For Small Transactions (文档 ID 1951033.1)
IF: ORA-1628 Reported During Import (文档 ID 1955310.1)