reliable message 可靠消息，偶遇了一把-凯发app官方网站

验证sql历史脚本，反复执行 insert into t1 select * from t1; 每次执行时间延长，这很正常，因为数据越来越多，执行几次后truncate 再测试，结果发现有一次特别慢，之前没事，奇怪。

看了一眼等待事件，居然是很少见的 reliable message事件。

正常情况下，看到的是

异常情况下是

遇到这种问题，怎么办？
老方法：去mos上搜官方的事件说明及诊断方法

直接搜reliable messages，找到以下：
waitevent：“可靠消息”参考说明（文档 id 69088.1）

定义：
当进程使用“ksr”实例内广播服务发送消息时，消息发布者会等待此等待事件，直到所有订阅者都消费了刚刚发送的“可靠消息”。发布者等待这个等待事件最多一秒钟，然后重新测试是否所有订阅者都消费了消息，或者直到发布。如果消息没有被完全消耗掉，等待会再次发生，重复直到消息被消耗掉或等待器被中断。
三个参数：

第一个参数展示通道上下文

col name_ksrcdes format a60
select b.addr "channel context",
b.totpub_ksrcctx,
a.name_ksrcdes
from x$ksrcdes a,
x$ksrcctx b
where b.name_ksrcctx=a.indx
and b.addr='&p1raw'

系统层面检查channel的信息

select channel, sum(wait_count) sum_wait_count
from gv$channel_waits
group by channel
order by sum(wait_count) desc

例如：

rbr channel 的值比较高，并不一定说明与这个事件相关，我当前版本是oracle 19.10。

等待时间：

等到所有订阅者都消费了消息。如果不发布以重新检查，则每秒内部超时。

寻找拦截器：

在诊断bug的增强功能可用之前，寻找阻塞者可能是一项挑战。有了这个修复程序，hanganalyze 转储可以帮助找到阻止程序。如果该修复程序不存在，则可以通过检查所涉及的实际通道找到有关阻止程序的线索 - 请参阅上面的 sql 。频道名称可以帮助提供有关可能的拦截器的线索。
systemstate 转储可用于查找阻止程序，但可能很昂贵，并且在系统状态转储输出阻止程序之前，情况可能已经发生了变化。

名词
ksr reuse block range (rbr)
ksr=kernel service reliable。

等待“可靠消息”是通信机制的一部分，当另一个进程向资源发布消息时，资源（称为通道）的多个订阅者会收到消息接收通知。进程向其他进程订阅的通道发送消息。当发送 reliable 消息时，消息发布者会等待“可靠消息”并阻塞，直到所有订阅者都消费了该消息。

这意味着如果数据库中的应用程序正在使用这些通道，则需要等待“可靠消息”。尽管这些等待可能不会导致性能问题，但当它们出现在 awr 报告的顶部时，可能会注意到它们的存在。

如果没有性能问题，可以忽略这些等待。

回到本问题，insert 应该是在寻找空间，也许是虚拟机有问题，先放放，我要进入另外一个问题
为什么出现load table conventional，有经验的一看就知道啥意思了。
>>未完待续。。。

阅读(11717) | 评论(0) | 转发(0) |

上一篇：tidib监控地址 wnm

下一篇：tidb查看执行计划和环境变量

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们