小小的导出，没想到的意外-凯发app官方网站

本来导出数据不是大事，客户来电要求将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 '�ad%'
and a.ktuxeusn = b.us#;

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

参考：script to monitor smon rollback progress [id 1352046.1]

阅读(1686) | 评论(0) | 转发(0) |

上一篇：单机寂寞建库

下一篇：控制smon是否回滚事务

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们