云和恩墨技术通讯:Oracle AMM自动内存管理引起数据库阻塞

各位亲爱的用户/读者朋友们:

为了及时共享行业案例,通告共性问题,达成知识共享和提前预防,我们整理和编辑了《云和恩墨技术通讯》(4月刊),通过对过去一段时间的知识回顾和故障归纳,以期提供有价值的信息供大家参考。 同时,我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来,为您提供具有前瞻性的支持信息,保持对于当前最新的数据库新闻和事件的了解,其中包括重要数据库产品发布、警报、更新、新版本、补丁等。

本期目录:

  • 新闻:2019年4月份数据库流行度排行版
  • 经验:低效应用脚本
  • 经验:AMM自动内存管理引起数据库阻塞
  • 频发:记DFS LOCK HANDLE等待的一次故障处理
  • 频发:不合理的序列CACHE值造成的性能故障
  • 警示:IBATIS 2.3.0同步锁bug导致大量STUCK线程
  • 预警:ORACLE近期关注之SCN问题
  • 问题:GES_PROCS资源限制导致ORA-00020
  • 问题:ENQ: TX – ROW LOCK CONTENTIION
  • 公告:墨天轮正式上线DB-RANK

部分精选-AMM自动内存管理引起数据库阻塞

Oracle 11g推出了自动内存管理(AMM)新特性,该特性引入后,虽然减轻了DBA手动设置共享内存的负担,但经常出现在shared pool和buffer cache之间发生频繁shrink/grow操作的现象,特别是shared pool的shrink操作,在一些高并发环境下,会刷出一批共享池对象,并间歇性持有shared pool latch,library cache lock等共享池的闩锁,从而引发数据库性能问题的风险,极端情况下,会导致数据库性能短时间内极速下降。

在云和恩墨的数据库最佳实践中,对于高并发的数据库,都建议关闭自动内存管理(AMM)新特性,而是采用固定的shared pool和buffer cache内存设置。在此我们分享一个近期的客户案例,供大家参考。

问题描述

当Oracle数据库使用自动内存管理(AMM)时,shared pool和buffer cache之间发生频繁的内存shrink/grow时有可能会引起数据库大量游标失效,随后的解析会导致大量library cache及cursor等待事件。近期在某数据库碰到这种情况,具体表现为故障时间段内数据库会话激增,并出现大量cursor解析类等待事件。

并且,出现的主要等待事件如下图:

这里,SGA: allocation forcing component growth等待,并伴随大量的library cache load/lock、cursor: mutex X/S等事件。SGA: allocation forcing component growth是内存自动增长的等待,其他等待事件主要为解析相关。大量的会话游标解析等待,但是并无明确阻塞源说明游标类等待是由于再次的SQL硬解析导致,这个很可能和自动内存管理有关。

同时,在此期间,buffer cache和shared pool均发生了快速的伸缩抖动。

可以看到,在19:09分时,shared pool内存从148,48M降低到14,336M,降低了500M, 为了腾出这500M,在高并发环境中,就会需要刷出一批共享池对象,并持有各种共享池的闩/锁,从而导致了性能问题。

问题原因

本库采用自动内存管理(AMM),在故障期间shared pool和buffer cache之间的内存shrink/grow,导致大量游标失效,随后的解析导致大量library cache及cursor等待事件。

问题建议

关闭自动SGA内存管理,sga_target=0,并根据环境设置适当的db_cache_size及shared_pool_size

下载链接:https://cs.enmotech.com/docDownload/2789

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2019-04-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券