暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

gaussdb 100之等待事件

白鳝的洞穴 2020-02-12
1250

    gaussdb 100在V1.0.1就提供了初步的等待事件,并且等待事件采集和WSR采集是缺省打开的,这是让运维人员十分兴奋的。老白在用ORACLE数据库的时候,也是等到了7.3才等来了等待事件与bstat/estat诊断,到了8.0才拥有了与WSR类似的utlbstat/utlestat工具。

    我们使用高斯100的等待事件可以通过三种方法,第一种方法是实时监控高斯100会话的等待事件情况,这个与我们在Oracle中监控v$session的情况类似,不过要注意的是,高斯100的等待事件接口可能还存在不完善的情况,v$session中虽然也有event的信息,但是v$session和v$session_event中的等待事件不太一致。从老白亲自分析的情况看,v$session_event中的数据更为准确。

从上面的图可以看出,在v$session中看到有49个idle wait的会话。因此很多DBA要从刚刚习惯oracle里从v$session_event视图转移到v$session视图(oracle 10以后)的DBA在高斯里又要转回去了。通过对会话的等待事件进行分析,可以确定数据库正常时的状态,从而识别数据库出现异常时的状态。这对于日常的数据库健康监控是十分有价值的。不过高斯的等待事件与数据库健康情况的对应关系还不是十分确切,高斯的等待事件是不是能够像Oracle一样反映出数据库的真实健康情况,还不是很确定,还有待在实际应用中进一步的完善。
第二种使用等待事件的方法是分析某段时间内系统等待事件的整体情况。这个可以从v$system_event(db_system_event)视图来查看:

从上面的结果可以看到,目前高斯100提供了27个等待事件,这和Oracle数百个等待事件还是有一定差距的,不过这些等待事件大多数我们是经常使用的,因此对于我们分析数据库的整体健康情况也基本上够用了,起码是聊胜于无吧。分析一定时间段内的等待事件的次数与平均等待事件有助于我们了解数据库的整体健康与性能状况。

第三种使用等待事件的方法是通过WSR报告,这也是最为简单的一种方法,对于判断一定时间段内数据库的健康与性能状态是十分有价值的。

TOP 10系统等待事件,是WSR报告周期内的V$SYSTEM_EVENT的分析。

会话TOP 2 EVENT是ORACLE数据库的AWR报告所没有的,对于分析某个会话或者某个应用为什么出现问题有一定的帮助。
根据老白上面的介绍,大家对高斯100的等待事件的情况可能有了一些初步的了解。因为华为的官方文档很简单,并且没有一些INTERNAL的资料透露出来,另外老白的库也不是一个实际生产库,因此只能点到为止的分析一下,使用等待事件判断数据库健康与性能也只是一个初步的猜测,具体高斯的等待事件能发挥多大的作用,还需要在实战中去沉淀与积累。


最后修改时间:2020-02-13 09:21:53
文章转载自 白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论