应用反应数据库在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