云和恩墨技术通讯：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