ITPub博客

首页 > 数据库 > Oracle > BEGIN SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_02', 'SYS'); END;

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

原创 Oracle 作者:DBA_每日记 时间:2019-12-05 13:24:08 0 删除 编辑

问题背景:


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


 


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


数据库在取数据块时为了保护内存的数据结构而加了latch(一种锁,很短暂),当SQL逻辑读过高,在并发的情况下大家都要去取相同的数据库而产生的等待,

出现这两个等待事件,基本上是由于大量的逻辑读竞争造成,那么直接去查逻辑读或物理读模块就可以看到问题所在。既然是并发情况下竞争去读取同一块,那边在AWR上看肯定是长时间无返回的语句


发现此sql占用了大量的read: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的争用。


来自 “ ITPUB博客 ” ,链接:/69950231/viewspace-2667059/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2019-10-09

  • 博文量
    110
  • 访问量
    47868