reliable message 可靠消息，偶遇了一把

验证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 9913388的增强功能可用之前，寻找阻塞者可能是一项挑战。有了这个修复程序，HANGANALYZE 转储可以帮助找到阻止程序。如果该修复程序不存在，则可以通过检查所涉及的实际通道找到有关阻止程序的线索 - 请参阅上面P1“通道上下文”的 SQL 。频道名称可以帮助提供有关可能的拦截器的线索。

SYSTEMSTATE 转储可用于查找阻止程序，但可能很昂贵，并且在系统状态转储输出阻止程序之前，情况可能已经发生了变化。

名词  
KSR Reuse Block Range (RBR) 
KSR=kernel service reliable。

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

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

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

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