BEGIN SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_02', 'SYS'); END;

问题背景:

客户反馈系统突然很慢,查询awr报告

1 658whw2n7xkd2    BEGIN SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_02', 'SYS'); END;

数据库在取数据块时为了保护内存的数据结构而加了latch(一种锁,很短暂),当SQL逻辑读过高,在并发的情况下大家都要去取相同的数据库而产生的等待,
出现这两个等待事件,基本上是由于大量的逻辑读竞争造成,那么直接去查逻辑读或物理读模块就可以看到问题所在。既然是并发情况下竞争去读取同一块,那边在AWR上看肯定是长时间无返回的语句

发现此sql占用了大量的read:

1 BEGIN SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_02', 'SYS'); END;

当时没搞明白,这语句块代表啥意思,百度搜了一下是用EXPDP在备份数据,客户确认确实有定时备份任务,建议用户调整备份时间

数据泵expdp需要全表扫,要把数据块都读到内存中,进行导出,当进入内存后,expdp获得了数据块的latch,但是这时候有个sql进来了,
要访问的数据块expdp正在访问,SQL也要获得latch,虽然latch很快,但是此时访问的特别多,问题的严重性就出来了,
其实这个latch争用严重的时候并不是用户反馈慢这么简单,有的会直接使CPU使用率达到97%以上,或者直接导致session数据达到最大值,
新的session无法创连等!因此数据泵的导出最好放在业务低峰期间,并且要留有足够的运行时间,因随着数据库的数据量的增加,
原有一个小时备份结束的可能某一天需要几个小时才能完成,放在早上五点显然没有给运行留下太多时间,因此必须调整了删除这样的备份任务。

关于latch:cache buffers chains和wait list latch free的原理,buffer cache中block的header被放置到hash chains上,
而hash chains又是放在hash bucket中,多个hash bucket被一个cache buffers chains latch保护。当多个session并发访问同一个数据块上的数据,
每个session都要首先获得cache buffers chains latch,这样将造成cache buffers chains latch的争用。

posted on   数据与人文  阅读(1611)  评论(0编辑  收藏  举报

努力加载评论中...
点击右上角即可分享
微信分享提示