inmemory OOM了
有人问我有个SQL原来100ms的现在200毫秒了，为什么？我看了一下，他这个是依托inmemory硬抗的那种SQL。里面这个特性将数据放在内存中处理。这不是一个正式环境，我觉得开发能有此意识是非常不错的。在测试环境发现了问题，避免带病上阵。然后我检查了后台数据库负荷、AWR等等，从AWR中看没有多少inmemory的访问。难道没加载上来吗？查询了一下 select * from v$inmemory_area;
惊现OOM，我是第一次遇到。看上去应该是需要加载的数据超过了分配的内存。所以自然有一部分是无法使用了。
select owner,segment_name,inmemory_size,bytes,bytes_not_populated,populate_status,inmemory_priority from v$IM_SEGMENTS order by segment_name
用这个命令可以查到，一半的表失败了。
知道问题了就好说了。要么是加大内存来存放这些数据。
另外一个就是精细化调整了，选择部分列加入到内存，而不用的不加载，按需。
举例来说：
--create table t1 (id int, a varchar2(101),b varchar2(100));
Alter table t1 inmemory (id, a)
no inmemory(b);
再查询 SELECT * FROM GV$IM_COLUMN_LEVEL 可以看到有些就没加载进去。
其实多年经验告诉我，数据库就应该物理机给他一个大内存。用虚拟机抠抠索索的问题总是不断。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-2923926/ ，如需转载，请注明出处，否则将追究法律责任。
