lgwr进程堵塞session的commit，但是lgwr本身是空闲等待

显示全部楼层 · 2019-1-25 11:35:05

本帖最后由 running_life 于 2017-5-15 11:05 编辑
环境：rhel6.311.2.0.4.4rac
情况描述：接到预警信息，session中有55个log file sync，查询blocker为lgwr，但是lgwr进程本身是空闲等待，且执行其他新的dml语句，commit正常。
另外，在半个小时前重启过该库的adg，同步模式是async的。
现在已经堵塞了很久了，只是因为新的commit没有被堵塞，所以没造成事故。但是这个情况怎么分析处理呢，简单的kill么，但是没找到原因。。。刚我又查了一次，这次堵塞没有了。。。大概堵了一个小时左右，就自动消失了。
上传了一个session的进程信息dump和lgwr进程的dump
不怎么看得懂，请路过的朋友，大神指点
=========================================================================================================
今天又发现这个问题了，故障时间段大约为7:16---8:06这次监控数据更完整，部署了oswbb监控15面收集一次数据，部署了dstat监控每秒收集一次性能数据
通过oswbb的oswprvtnet查看故障时段内私网性能波动不大，tracerote都是1ms一下，一般是0.17ms，高的时候有0.78ms左右
查看oswps，故障时刻cpu使用不高，lgwr进程cpu使用率也不高
通过dstat数据查看了故障时刻的网络，磁盘，cpu等使用情况，这些资源的使用率都非常低，网络最高也就15MB 左右，磁盘也是20MB左右，cpu为5%左右
查看lgwr日志，发现7:50左右有警告Warning: log write broadcast wait time 6966ms (SCN 0xb48.801b20a9)
其实我有点怀疑是post与poll切换导致的，但是在lgwr日志中没看到故障时间段之前或者之中有这个切换，在5月12号发现有切换。。。。
大家有什么建议
*** 2017-05-12 03:58:23.579
Warning: log write elapsed time 594ms, size 1KB
kcrfw_update_adaptive_sync_mode: post->poll long#=6 sync#=44 sync=1810 poll=3790 rw=1603 rw+=1603 ack=292 min_sleep=1056
*** 2017-05-12 04:25:52.291
Log file sync switching to polling
Current scheduling delay is 1 usec
Current approximate redo synch write rate is 14 per sec
NSS4 is not running anymore.
**************************************
**************************************
*** 2017-05-15 07:29:43.013
NSS2 is not running anymore.
NSS4 is not running anymore.
*** 2017-05-15 07:47:01.299
NSS2 is not running anymore.
*** 2017-05-15 07:50:03.313
Warning: log write broadcast wait time 6966ms (SCN 0xb48.801b20a9)
NSS4 is not running anymore.
*** 2017-05-15 08:03:28.535
NSS2 is not running anymore.
NSS4 is not running anymore.
*** 2017-05-15 08:17:22.680
NSS2 is not running anymore.
NSS4 is not running anymore.
*** 2017-05-15 08:31:19.860
NSS2 is not running anymore.

千问 · 2019-1-25 11:35:05

顶上去，大家帮忙顶顶

千问 · 2019-1-25 11:35:05

SHOW PARAMET log_archive_dest_1ER LOG_ 参数中是否有 AFFIRM

千问 · 2019-1-25 11:35:05

desert_xu 发表于 2017-3-3 21:00
SHOW PARAMET log_archive_dest_1ER LOG_ 参数中是否有 AFFIRM
没有，这个没有配置的，我刚又在另一套系统发现类似的问题了，也是lgwr堵塞了37个，但是lgwr本身是空闲的

千问 · 2019-1-25 11:35:05

running_life 发表于 2017-3-6 12:38
没有，这个没有配置的，我刚又在另一套系统发现类似的问题了，也是lgwr堵塞了37个，但是lgwr本身是空闲的
你是用v$wait_chain看到的这个现象么？把查询结果和SQL发出来
看看你说的空闲等待是什么？
或者差ASH的那些表，也可以~

千问 · 2019-1-25 11:35:05

zergduan 发表于 2017-3-6 13:09
你是用v$wait_chain看到的这个现象么？把查询结果和SQL发出来
看看你说的空闲等待是什么？
或者差ASH的 ...
SQL> select t.chk_time,t.chain_signature from tbl_mon_wait_chains t where t.chk_time=to_date('2017-03-06 12:50:01','yyyy-mm-dd hh24:mi:ss')
2;

CHK_TIMECHAIN_SIGNATURE
----------- --------------------------------------------------------------------------------
2017-03-06'rdbms ipc message'
2017-03-06'LNS ASYNC end of log'
2017-03-06'Streams AQ: waiting for messages in the queue'

37 rows selected

SQL>

千问 · 2019-1-25 11:35:05

zergduan 发表于 2017-3-6 13:09
你是用v$wait_chain看到的这个现象么？把查询结果和SQL发出来
看看你说的空闲等待是什么？
或者差ASH的 ...
大神，这时我的监控数据，如果发现有等待事件过多，将waitchain记录下来。。。
还好有记录。。。这些数据显示log file sync一致被rdbms ipc message堵塞，这个就是lgwr的等待事件

千问 · 2019-1-25 11:35:05

这个不是说rdbms ipc message 阻塞了log file sync.是说明阻塞者会话当前是空闲的,但它肯定持有某个lock . 比如一个DML 没有提交什么的.

千问 · 2019-1-25 11:35:05

qqjue 发表于 2017-3-10 18:35
这个不是说rdbms ipc message 阻塞了log file sync.是说明阻塞者会话当前是空闲的,但它肯定持有某个l ...
没有提交的等待事件应该不是log file sync吧