EBS 开启In-memory经历前后

背景描述

  2020年8月31日17：30左右，为EBS的数据库开启了In-memory的功能，并按照其中的advisor建议将89个对象加入了in-memory。9月1日17：30再次运行了EBS的inmemory advisor,并按照建议
  运行了sql.
  在开启了DBIM功能后，用户陆续反映流程流转资源等待，采购订单审批状态查询页面超时。系统使用没有提速，反而变慢了。
  9月2日17:30左右，关闭EBS应用，并禁用了EBS数据库的IM。应用前段功能没有好转。
  9月7日，EBS应用爆出大量的功能页面无法正常工作。项目上不能付款、费控月报跑步出来、产品管理平台的sql在数据库里能跑，却在应用端超时……
  

诊断过程

  拿出了开启In-memory前\中\后的一日相同时段（16：00-17:00）的awr报告和ash报告进行对比分析，通过分析发现DB的数据库负载并没有明显增多。
  最初判定的行级锁争用严重现象其实在IM设置之前已经存在。
  于是从应用上功能失常又能找到相关的sql入手，选取了跑费控月报的sql作为分析。
  在费控月报sql跑得期间，通过ASH报告发现，即使在禁用了DBIM后 该sql的执行计划依然采用了table access in_memory full。
  于是尝试将相关查询表设置为alter table pa_project_all no inmemory;设置后 发现费控月报sql查询所有数据从原有的70+分钟变为5秒。
  接着再将所有在开启in-memory后设置的表或分区，手动分别设置为 no inmemory,应用端恢复正常。
  

总结：

 1、EBS 系统具有特殊性，今后在升级、打补丁等动作方面均要慎重。
 2、查看awr报告对比分析，不用跨度太大，最好采用相同时段来做对比分析。
 3、AWR报告结合ASH报告，更能发现问题所在。
 4、借助执行计划，查看差别。（貌似cost并不一定反应真实问题）

5、对于EBS，紧紧拥常规的IM禁用办法（将in-memory参数设置为0 ）还不够，还需要对启用过IM的对象执行所有的关闭操作。

下图为对表取消IM前

对表取消IM后