1、行锁，查看top sql中dml类sql，可以看到awr中top elstime的update的sql正在执行中，建议排查是否业务有冲突。
2、io性能差。按照awr报告看，这是个OLAP数据库吧。如果需要可以从io性能或者优化sql入手
评论
有用 0
看上去
read by other session: % DB time 33.8%
enq: TX - row lock contention: % DB time 10.1%
direct path read: % DB time 3.1%
都是和SQL有关的，直接路径读，锁，还有索引问题
评论 有用 0-
IO方面物理读很高，平均每秒的物理读为785.7MB，Top 10中和物理读相关的event的%DB time之和
为33.8%+10.5%+3.1%=47.4%，并且主机内存有251.9GB，数据库sga+pga的内存使用只占29.95%，所以，一是在
不影响其他程序的前提下，考虑调大数据库的sga、pga，二是优化sql，按照SQL ordered by Reads列出的
top sql把物理读高的sql优化掉。 -
对于enq: TX - row lock contention等待事件，等待了393次，平均每次等待时长1378554ms，
也就是22.9分钟，可以认为是一条sql的执行在获取行锁资源上等待了22.9分钟，这个等待事件从ash中查找问题更方便，
select INSTANCE_NUMBER,sql_id,event,count(*)
from DBA_HIST_ACTIVE_SESS_HISTORY
where sample_time>=to_date(‘20210811 23:00:30’,‘yyyymmdd hh24:mi:ss’)
and sample_time<=to_date(‘20210812 00:00:38’,‘yyyymmdd hh24:mi:ss’)
and event=‘enq: TX - row lock contention’
and INSTANCE_NUMBER=2
group by INSTANCE_NUMBER,sql_id,event
评论 有用 0
