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 2020-06-16 14:40  数据与人文  阅读(505)  评论(0)  编辑  收藏