这个一般是在 具有在跑大数据量的 transaction的时候 kill 掉了进程而导致 smon 去清理回滚段时导致的。这个在业务高峰期的时候，如果发现这个，有可能导致SMON 占用了 100% cpu 而导致 系统hang在那边。即使你shutdown immediate，Oracle也会等待 smon 清理完毕才能关机，而这个等待过程也许是漫长的。如果你shutdown abort，那么oracle 会马上 shutdown ，但是，当你 startup的时候，可能就会很慢，因为 smon 会接着清理 undo，这个等待过程也许是很漫长的：
这一次回滚由前一天上午11持续到隔天到早上6点
当Oracle处于open 状态，当Oracle回滚事务的时候，可以从used_urec，used_ublk数值可以初步估计Oracle回滚事务的速度。
SQL> select a.sid, a.username, b.xidusn, b.used_urec, b.used_ublk where a.saddr=b.ses_addr;当Oracle非正常关闭（如shutdown abort）时，再次open时v$transaction重置。或处于业务繁忙期，smon进程事务回滚，查询视图V$FAST_START_TRANSACTIONS中字段UNDOBLOCKSDONE，UNDOBLOCKSTOTAL估算smon恢复进度。
查看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;UNDO段分配情况：
SELECT r.status "Status",
r.segment_name "Name",
r.tablespace_name "Tablespace",
s.extents "Extents",
TO_CHAR((s.bytes / 1024 / 1024), '99999990.000') "Size"
FROM sys.dba_rollback_segs r, sys.dba_segments s
WHERE r.segment_name = s.segment_name
AND s.segment_type IN ('ROLLBACK', 'TYPE2 UNDO')
ORDER BY 5 DESC;可以通过下面命令，查看事务回滚估算时间
方法一：
SQL> select undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo",decode(cputime,0,'unknown',to_char(sysdate+(((undoblockstotal-undoblocksdone)
/ (undoblocksdone / cputime)) / 86400),'yyyy-mm-dd hh24:mi:ss')) "Estimated time to complete",to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from v$fast_start_transactions;方法2：
select ktuxeusn, to_char(sysdate,'DD-MON-YYYY HH24:MI:SS') "Time", ktuxesiz, ktuxesta from x$ktuxe where ktuxecfl = 'DEAD';
直接显示结束时间回滚并行参数
涉及参数FAST_START_PARALLEL_ROLLBACK，由于是动态参数，可以立即生效
alter system set fast_start_parallel_rollback=false;共三个参数可以设置
false：关掉并行
low：低并行（默认） 2 * CPU_COUNT
high：高并行 4 * CPU_COUNT
需要注意的是Oracle在回滚大事务并行回滚，但是在实践中可以发现当fast_start_parallel_rollback= Low/High，即启用并行回滚时常有并行进程因为各种资源互相阻塞导致回滚工作停滞的例子，当遭遇到这种问题时将fast_start_parallel_rollback设置为FALSE一般可以保证恢复工作以串行形式在较长时间内完成。
CPU相关可以查看
SQL> show parameter cpu;
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
cpu_count integer 4
parallel_threads_per_cpu integer 2
resource_manager_cpu_allocation integer 4cpu_count 表示oracle可以使用逻辑cpu数量
parallel 表示线程（大于1，代表可以超线程）
第一个参数的cpu个数，在linux下 cat /proc/cpuinfo processor等几个命令可以查看
windows下 cmd 输入wmic 输入cpu get
可以通过查看视图v$fast_start_servers中字段STATE ，如果只有一进程处于RECOVERING，其他进程处于IDLE，则可考虑将FAST_START_PARALLEL_ROLLBACK设置为false，关闭并行恢复。如果所有进程都处于RECOVERING状态，则可以考虑加大恢复进程，将其设置为high。
参考文档
https://blog.csdn.net/vic_qxz/article/details/52723598
