看上去
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有关的，直接路径读，锁，还有索引问题

1. 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优化掉。

2. 对于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