客户的跑批任务由于逻辑放生错误，导致了insert上亿条数据，表空间使用率即将爆满，在和开发商量后，只能kill跑批，回滚事务。在回滚期间，观察了以下3个视
有关回滚的几个视图：

v$session_longops

该视图记录了所有时间超过6秒(绝对时间)的操作，这些操作包括：备份、恢复、统计信息收集、查询等，以及
Oracle的每个版本中新增的操作。

sofar：到目前为止完成的工作量，单位为units列值，一般为block
totalwork：总共的工作量，单位为units列值，一般为block
time_running：预计完成操作的剩余时间，单位为秒
elapsed_seconds：从操作开始总花费时间，单位为秒

v$fast_start_transactions

该视图记录了Oracle的回滚事务。
实际上不是所有的回滚都会记录在该视图中，例如一般的rollback就不会记录；当服务进程在提交事务(commit)前意外终止的话就会形成死事务(dead transaction)，PMON进程负责轮询Oracle进程，找出这类意外终止的死进程(dead process)，通知SMON将与该dead process相关的dead transaction回滚清理，这才会记录在该视图中，例如事务在提交前会话被kill，以及数据库实例意外关闭，shutdown abort等。

STATE: TO BE RECOVERED(即将回滚), RECOVERED(回滚完毕), or RECOVERING(回滚中)
UNDOBLOCKSDONE：当前回滚的undo blocks数量
UNDOBLOCKSTOTAL：总共需要回滚的undo blocks数量

v$transaction

记录了所有active的事务。
需要重点关注used_ublk，多次查询，如果used_ublk在增大，说明正在执行数据处理；如果used_ublk在减小，说明正在执行rollback，一直到used_ublk为0表示rollback结束，可以通过这个值大致估算出rollback的时间。

在事务回滚时，修改FAST_START_PARALLEL_ROLLBACK参数为true，以加快回滚速度。同时还需要观察undo空间的使用率，通常是需要临时增加undo文件，以避免undo没有空余空间。

with free_sz as
(select tablespace_name, sum(f.bytes) / 1048576 / 1024 free_gb
from dba_free_space f
group by tablespace_name),
a as
(select tablespace_name,

    sum(case
          when status = 'EXPIRED' then
           blocks
        end) * 8 / 1048576 reusable_space_gb,
    sum(case
          when status in ('ACTIVE', 'UNEXPIRED') then
           blocks
        end) * 8 / 1048576 allocated_gb

from dba_undo_extents
where status in ('ACTIVE', 'EXPIRED', 'UNEXPIRED')
group by tablespace_name),
undo_sz as
(select tablespace_name, df.user_bytes / 1048576 / 1024 user_sz_gb
from dba_tablespaces ts
join dba_data_files df
using (tablespace_name)
where ts.contents = 'UNDO'

and ts.status = 'ONLINE')

select tablespace_name,

  user_sz_gb,
  free_gb,
  reusable_space_gb,
  allocated_gb,
  free_gb + reusable_space_gb + allocated_gb total

from undo_sz
join free_sz
using (tablespace_name)
join a
using (tablespace_name);