你的数据库存在行锁，可以查询一下数据库产生行锁的阻塞源。

通过AWR分析，主要等待事件：enq: TX - row lock contention。通过v$session,v$session_wait及vsession_event查看阻塞源。 单机环境通过以下SQL可以查到阻塞源，如果找不到阻塞源窗口，杀会话处理。 set lines 200 pages 100 col tree for a30 col event for a40 select * from (select a.sid, a.serial#, a.sql_id, a.event, a.status, connect_by_isleaf as isleaf, sys_connect_by_path(SID, '<-') tree, level as tree_level from vsession a
start with a.blocking_session is not null
connect by nocycle a.sid = prior a.blocking_session)
where isleaf = 1
order by tree_level asc;

从第一个与第二个AWR看主要的等待事件行锁：

行锁的平均等待已经达到45013ms
原因分析：
1.检查一下enq:tx-row lock contention对于的会话情况，以及阻塞源情况。
SQL参考：
set linesize 300
set pagesize 400
col username for a15
col event for a30
col machine for a10
col program for a25
col spid for a15
col sql_id for a15
col status for a10
select a.sid,a.serial#,b.spid,a.username,a.event,a.machine,a.program,a.sql_id,a.blocking_session as blocker,a.status,a.paddr,a.p1,a.p1raw,a.p2,a.p2raw
from v$session a,v$process b
where a.paddr=b.addr
–and a.inst_id=3
and a.event like ‘enq%’
order by a.sid;
可以通过blocking_session查到阻塞源的会话id，还可以参考SQL：
set linesize 300
col username for a10
col event for a30
col machine for a20
col status for a15
col program for a20
col sql_id for a15
col spid for a15
select a.sid,a.serial#,a.username,a.event,a.machine,a.program,a.sql_id,a.status,b.spid
from v$session a,v$process b
where a.paddr=b.addr
and a.sid in (
select blocking_session from v$session
where event like ‘%&event%’);
event修改为enq: TX - row lock contention
2.从第三个AWR看出存在log file sync
这个可以检查一下redo日志的大小
从操作系统看这个数据库是安装在windows上面的。

建议：
1.行锁检查，修改业务逻辑，检查是否存在长期不提交或者回滚的DML操作。
2.检查业务是否存在select for update操作。
3.检查一下redo的大小情况，检查一下磁盘的IO情况