共计 1513 个字符，预计需要花费 4 分钟才能阅读完成。
背景简介：
Oracle 版本:11.2.0.4 OS 版本：OEL5.8
在一次 Oracle 的 Dataguard 正常 switchover 过程中，遇到了一个极其诡异的问题，一条主业务的 SQL 语句在新主库的执行时间由之前的毫秒级别完成变成了 20-60 秒不等，为避免高峰业务超时必须尽快进行优化，否则只能走回退方案。
优化过程：
其实这个语句在之前将备库切换为 snapshot 备库做测试时表现是非常良好的，但是切换之后立马出了问题。在备库实际执行后获取到的执行计划与在主库一模一样，如下：
获取执行计划的语句如下：（语句出自 ITPUB 大神版主 lfree）
select * fromtable(dbms_xplan.display_cursor(NVL('&1',NULL), NULL, 'ALL ALLSTATS LAST PEEKED_BINDS cost partition -projection -outline &2'));这里的参数 1 和 2 全部设置为空即可，此语句可以查出当前会话中上一个执行过语句的真实执行计划。
此 SQL 中不涉及视图，所以这个执行计划是非常好的，在主库执行也是毫秒级别的，因此同样的执行计划在备库却非常慢就很值得思考了。
接下来我利用 set autot 工具得到了执行此 SQL 后的统计信息，发现存在大量物理读。这里就很搞笑了，真实执行计划中不存在表扫描，所以出现这么多的物理读一定是回表操作特别多，那么为什么回表？显然内存不够。
于是我将 SGA 加大至 80GB（比主库还大 20GB），重启数据库再查，问题依旧。
我依然坚信是缓存的问题，那么必须要搞清为何数据未被缓存至内存，对 Oracle 数据库来说大多有 2 个原因：
1、数据太多，内存太小。
2、不是热点数据，被 LRU 刷出内存。
首先排除第二条，原主库 60G 的 SGA 都可以，现在 80G 的 SGA 没理由不可以。
此外注意到一个现象，v$sgainfo 中的 buffer pool 在接近 30GB 时有一个很长时间的停顿，然后才慢慢增长至接近 70G（剩余部分属于 sharedpool 等）。
于是突然想到 NUMA 的问题，果然：
numactl –hardware 的运行结果：
这就尴尬了，在 /etc/grub.conf 的 kernel 一行后添加了 numa=off，重启服务器后果然问题被解决。
事后查看数据库日志找到了如下信息：
.
因此可以确认是操作系统未关闭 NUMA 特性引起的（只设置数据库禁用 NUMA 的隐含参数是无用的，Oracle 在 11GR2 之后已经默认禁用 NUMA，但只是数据库级别）。
关于 Oracle NUMA 的相关信息，参考官网文档：Oracle NUMA Usage Recommendation (文档 ID 759565.1)
名词解释：
什么是 NUMA：
NUMA 模式是一种分布式存储器访问方式，处理器可以同时访问不同的存储器地址，大幅度提高并行性。NUMA 模式下，处理器被划分成多个 ” 节点 ”（node），每个节点被分配有的本地存储器空间。所有节点中的处理器都可以访问全部的系统物理存储器，但是访问本节点内的存储器所需要的时间，比访问某些远程节点内的存储器所花的时间要少得多。
–OK，注意这几个字：大幅提高并行性。Oracle 数据库绝大多数时候进程都是串行的，除非特意设置并行度，而 SQL Server 也只有超过 cost 阈值才会并行，因此数据库服务器应该禁用 NUMA。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-06/144603.htm
