Linux 10g( 10.2.0.1.0 ) 32位,shutdown immediate 后,一直卡住,半小时多还不结束。测试多次有一次等待大约50分钟后完成。每次只能abort关闭。
alert日志中,报错停留在 waiting for smon to disable tx recovery
top 中可看到smon 进程cpu使用100%
使用oradebug 设置跟踪smon的10046事件
sql>oradebug setospid 27186
sql>oradebug event 10046 trace name context forever,level 12;
sql>oradebug tracefile_name;
查看trc文件,一直刷的是:
delete from smon_scn_time where thread=0 and scn= (select min(scn) from smon_scn_time where thread=0);
使用tkprof 格式化后,发现smon一直就在执行这句,执行了8万多次,cpu、elapsed 均为3000多秒,query 达到10T的量
找到 http://blog.itpub.net/23850820/viewspace-2100141/
其他参考: https://blog.csdn.net/tianlesoftware/article/details/8734601
以下为链接中的解决方法:
索引和表中的数据不一致,只能重建索引。参考mos提供的方法:
drop index smon_scn_time_scn_idx;
drop index smon_scn_time_tim_idx;
create unique index smon_scn_time_scn_idx on smon_scn_time(scn);
create unique index smon_scn_time_tim_idx on smon_scn_time(time_mp);
analyze table smon_scn_time validate structure cascade;
但是也会碰到一个比较头疼的问题,删除和创建索引的时候,一致提示资源忙
我使用rebuild online 方式重建索引,一直无法完成,等待事件为TM锁,被smon 阻塞。
尝试多次重启后立即drop index 还是提示资源忙。。
其他人有提到设置12500事件,然后直接delete table 。 提示索引损坏。
实际情况:
删除索引报资源忙,rebuild online 一直无法完成。直接delete、truncate 报索引损坏
smon_scn_time 表中有大约12万数据,想着如果把表和索引中能对上的都删了,然后就没多少数据了,可能再drop index的时候会不会好些?
select /*+full(t) */ scn from sys.smon_scn_time t
minus
select /*+ use_index(t SMON_SCN_TIME_SCN_IDX) */ scn from sys.smon_scn_time t where scn is not null
两表分别minus一下,大概差十几
-- 删除绝大数数据
delete from sys.smon_scn_time t
where t.scn in (
select scn from sys.smon_scn_time t
intersect
select /*+ use_index(t SMON_SCN_TIME_SCN_IDX) */ scn from sys.smon_scn_time t where scn is not null
) ;
最终剩下12条。
shutdown abort ;
startup up;
立即执行两个drop index 语句,终于删除成功。
重建索引。。。观察,正常了
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24680677/viewspace-2284796/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/24680677/viewspace-2284796/