Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3494550
  • 博文数量: 738
  • 博客积分: 1860
  • 博客等级: 上尉
  • 技术积分: 7745
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-07 08:51
个人简介

偶尔有空上来看看

文章分类

全部博文(738)

文章存档

2023年(75)

2022年(134)

2021年(238)

2020年(115)

2019年(11)

2018年(9)

2017年(9)

2016年(17)

2015年(7)

2014年(4)

2013年(1)

2012年(11)

2011年(27)

2010年(35)

2009年(11)

2008年(11)

最近访客

分类: Oracle

2021-06-11 19:43:50


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

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

正常情况下,看到的是


异常情况下是

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

直接搜reliable messages,找到以下:
WAITEVENT:“可靠消息”参考说明(文档 ID 69088.1)

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


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

  1. col NAME_KSRCDES format a60
  2. SELECT b.addr "Channel context",
  3.        b.totpub_ksrcctx,
  4.        a.name_ksrcdes
  5.   FROM X$KSRCDES a,
  6.        X$KSRCCTX b
  7.  WHERE b.name_ksrcctx=a.indx
  8.    AND b.addr='&P1RAW'
系统层面检查channel的信息

  1. SELECT CHANNEL, SUM(wait_count) sum_wait_count
  2.   FROM GV$CHANNEL_WAITS
  3.  GROUP BY CHANNEL
  4.  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,有经验的一看就知道啥意思了。
>>未完待续。。。
阅读(11795) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~