UPDATE To USER$.SPARE6的sql导致数据库hang住

应用反应数据库在9点05分左右运行缓慢

下面我们通过ash对当时的数据库会话做出分析

--查看历史active会话的event数

select INSTANCE_NUMBER,EVENT,BLOCKING_SESSION,count(*) from dba_hist_active_sess_history 

where sample_time>= to_date('2018-06-04 09:00:00','yyyy-mm-dd hh24:mi:ss') and  sample_time<= to_date('2018-06-04 09:30:00','yyyy-mm-dd hh24:mi:ss')

group by INSTANCE_NUMBER,EVENT,BLOCKING_SESSION

order by 4,2,3,1

;

library cache lock严重，而且还有log file switch incomplete的问题

 

--查看1534session

select INSTANCE_NUMBER,session_id,EVENT,BLOCKING_SESSION,sql_id  from dba_hist_active_sess_history 

where sample_time>= to_date('2018-06-04 09:00:00','yyyy-mm-dd hh24:mi:ss') and  sample_time<= to_date('2018-06-04 09:30:00','yyyy-mm-dd hh24:mi:ss')

and session_id=1534

;

library cache lock的堵塞源头还是log file switch

查看当时的sql

一个update user$的语句，这是一个数据库内部的sql，按理说应该不会造成问题

--alert日志

--select INST_ID,group#,thread#,bytes/1024/1024 mb,members,status from  gv$log order by 3,2

redo log配置还是比较大的，3组1gb，事务量不大就不会造成check point not complete的问题。

因为当前环境是12.1.0.2，没有打补丁（因为之前打补丁时遇到bug），在mos上搜索update那条sql，很容易就搜到了。

bug 25839004，只要打上最新的补丁就行了。

因为psu中的readme只有opatchauto方式打补丁，但是opatchauto在这个库上打不了补丁（这也是bug），导致遇到更多的bug，只有自己整理手动打补丁方案。12c的坑还是多呀。

参考文档：

UPDATE To USER$.SPARE6 Performs Poorly (2-Second Execution Time) and Consumes CPU (文档ID 2280676.1)

Bug 25839004 : SLOW LOGIN UPDATE USER$ QUERY WHEN TDE AND DBFIPS_140 ENABLED