小小的导出，没想到的意外

本来导出数据不是大事，客户来电要求将A库数据导出，在B机创建实例，然后导入，登录数据库看看大小，有些小卡，没在意，查出大小17G，嗯，简单，查看可用的directory和磁盘空间，查看用户信息都正常，看了看cpu，有些忙呀，按说测试环境不应该这个样子。

导出看看
expdp \'/ as sysdba \' directory=DATA_PUMP_DIR dumpfile=t_%U.dmp logfile=t_exp.log full=y
跑了一小时才500多M！

top看sys%很高，一堆oracle进程瞎忙，alert.log没有告警，后台不知干啥呢（应该看v$session）。

经沟通，启停一下数据库吧，很慢很慢的。

看来是不正常的

根据刚才看top时确认smon、dbwr、vktm进程忙，其实这时应该知道是什么原因了。

逐一解决它！

alter system set db_writer_processes=4 scope=spfile;  --加了这个重启库很快了
alter system set job_queue_processes=0;  --防止干扰，其实没用
alter system set filesystemio_options=setall scope=spfile;  --似乎有关，先改改
alter system set "_high_priority_processes"='LMS*' scope=spfile; --肯定治理vktm高cpu
alter system set fast_start_parallel_rollback=false scope=spfile;  --并行恢复改为串行

重启数据库，会话里就不会看到很多并行恢复进程了。

查查回滚事务进度：

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'))  
   "Est time to OK",to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') riqi
   from v$fast_start_transactions;

一开始预估到23点，又要加班？出去吃了个饭，回来再看，嗯19:30结束。

通过观察，回滚期间redo更新很频繁，看来把测试库的redo log文件大小从50M调大到500M，再多加几组很有必要呀。

2月6日补充：
上述评估回滚进度的方法可能不准确，参照官方文档，查看undo进度执行以下脚本：
set lines 120
col undo_segment format a25
alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

select sysdate,b.name undo_segment, b.inst# instid, b.status$ status, a.ktuxeusn
xid_usn, a.ktuxeslt xid_slot, a.ktuxesqn xid_seq, a.ktuxesiz undoblocks
from x$ktuxe a, undo$ b
where a.ktuxesta = 'ACTIVE'
-- and a.ktuxecfl like '%DEAD%'
and a.ktuxeusn = b.us#;

每隔 2 分钟，执行一次上述语句，看 undoblocks 这列的值是否在减少，降低为0，说明事务结束。

参考：Script to Monitor SMON Rollback Progress [ID 1352046.1]

Monitor_SMON_Rolllback.sql