超大内存环境下的Oracle RAC参数设置建议

白鳝的洞穴 2023-10-18

1299

好久没写Oracle方面的文章了，最近有几个朋友在超过1TB物理内存上的数据库系统因为配置的问题，在高负载下出现了不稳定，宕机，莫名其妙的报ORA-4030等问题。自从三十年前第一次在一台32MB内存的小型机上安装Oracle 5.1以来，这些年的硬件进步确实太快了，内存也已经进入了TB时代。如果在一台TB级内存的服务器上运行一套负载较高，数据量达到几十TB的数据库的时候，是不是会与以前有所不同呢？我也在MOS上查找了一些资料，确实在超大内存环境下运行负载较高的Oracle数据库系统，在参数优化上还是要做些调整的，今天早上我就把这些资料汇总一下，提供给有需要的朋友。

首先在操作系统层面设置大页，关闭透明大页，设置vm.swappiness以及调整网络参数，这些都按照Oracle安装手册的要求去做就可以了。在RHEL 7以上，新版本下，如果物理内存足够的情况下，swappiness的设置不是必须的，不过设置为0或者小于10的值会更为稳妥一些。

除了上述比较常规的参数以外，我今天还要介绍一个比较陌生的参数，vm.max_map_count，这个参数用于进程中映射虚拟内存。CENTOS 7的默认值是65530。对于传统的服务器来说，这个值是够用的，而如果你的系统需要对一张百GB级别的表做扫描的时候，过小的max_map_count可能会导致在物理内存还十分充足的情况下出现ora-4030报错。Oracle对于12c的官方建议值是262144，是操作系统默认值的4倍。

接下来是一些数据库的参数，首先是DRM相关的参数。在Oracle较低的版本上（比如10g/11g）或者网络不是很好的环境中，直接关闭DRM可能是更好的选择。如果网络带宽够高，延时够稳定，那么在12C及以后的版本中，甚至在11g中，关闭DRM并不是必须选项。DRM对于性能来说是个双刃剑，除了一些特殊场景必须关闭DRM外，实际上也可以打开DRM以降低GCS的开销。如果你想要关闭DRM，可以设置：_gc_policy_time = 0。如果你没有关闭DRM，那么建议设置_gc_policy_minimum=15000。_gc_policy_minimum参数是一个隐藏参数，用于指定每分钟数据库对象至少要被访问多少次，才考虑修改它的主节点信息。在某些版本中，该参数的默认值是2400，对于负载较高的系统，这个默认值太小了，建议加大。

另外一个十分重要的集群参数是_lm_sync_timeout。这个参数的默认值也是偏小，这会增加大SGA环境下，RAC RECONFIGURATION或者DRM引发的lm同步超时的几率。Oracle建议在12.2或者更低版本中将该参数设置为1200。

_lm_tickets参数控制了RAC消息通讯中的tickets数量，在不同版本的Oracle数据库中，对于较大型、负载较高的数据库来说，是不够的，仅仅为1000。为了确保高负载的大型数据库在运行中不会因为tickets不足而导致性能问题甚至引发集群故障，该参数建议设置为5000或者更大。

如果你的系统的GCS相关的等待比较多，并且延时也比较高，那么很可能你的lm process数量不足了。在Oracle 12.2及以下的大多数版本中，gcs_server_processes参数的默认值是不够的，一般需要设置为默认值的2倍或者略高。不过设置该参数的时候一定要注意，lm processes的数量至少要比CPU的物理核数略低一些。

对于12.2或者更高的数据库版本来说，大家可能不会意识到有一个对GCS性能影响巨大的PDB参数TARGET_PDBS，这个参数设置了今后CDB里将会创建的PDB数量（不包含种子，根等）。因为随着Oracle数据库的自治能力提升，很多参数的默认值都会根据实际可能的情况做预留，GCS/GES相关的闩锁数量也是如此。如果你今后会使用PDB，那么一定要规划好大致的PDB数量（不用百分百精确，但是不能相差太大，如果相差太大，要重新调整该参数），并将此参数设置好。

最后讲到Oracle的SGA/PGA方面的配置了。超大内存环境当然与SGA有关，不过实际上Oracle对SGA的管理已经十分自动化，如果你使用11g，那么，建议还是采用SGA_TARGET和PGA_AGGREGATE_TARGET参数来控制PGA/SGA。而如果你使用12.2版本，那么无论使用memory_target还是使用sga_target，都没有太大的问题。唯一需要注意的是，你一定要将SGA的15%分配给SHARED_POOL_SIZE。共享池对于数据库并发性能十分关键，如果你的数据库的并发执行很高，不给共享池一个较大的最低配置，会导致SGA抖动加剧。当数据库负载很高的时候出现一次共享池的RESIZE，那么可能会对数据库的性能造成很大的影响。

最后一点要提醒的是，如果你使用了巨大内存，那么一些数据库的比较新的补丁建议都打一下。因为Oracle的一些初始版本都没有考虑到这些问题，因此或多或少都存在一些支持上的不足。比如对于表早期的11.2.0.3, 11.2.0.3.5 数据库 PSU是必须打的。如果你的服务器内存大于4TB，而数据库版本还是比较老的11.2.0.4，BUG 18780342会倒追在LINUX上无法在4TB内存的服务器上稳定运行Oracle 11.2.0.4，目前该修复已经包含在一些修复中，可以去MOS上通过bug号查找所需的补丁。