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 语句，终于删除成功。

重建索引。。。观察，正常了