作者：沃趣科技高级数据库工程师  魏兴华 


Transparent Hugepage


从RedHat6, RedHat7, OL6, OL7 SLES11 和 UEK2 kernels开始transparent hugepage被默认开启，它允许大页做动态的分配，而不是系统启动后就分配好，根据Oracle MOS DOC：1557478.1，transparent hugepage导致了很多的问题，建议将其关闭 查看是否启用了transparent hugepage cat /sys/kernel/mm/transparent_hugepage/enabled [always] never []内的值是当前启用的值，上面的输出说明启用了transparent hugepage。 可以通过 /etc/grub.conf 文件来关闭transparent hugepage。



通过增加关键字transparent_hugepage=never来讲transparent hugepage关闭。 也可以通过开机启动后，echo相应的值到对应的文件来动态关闭transparent hugepage。



OS层面查看大页使用情况



HugePages_Total为所分配的页面数目，和Hugepagesize相乘后得到所分配的内存大小。43000*2/1024大约为84GB。

HugePages_Free为从来没有被使用过的Hugepages数目。即使Oracle sga已经分配了这部分内存，但是如果没有实际写入，那么看到的还是Free的。这是很容易误解的地方。

HugePages_Rsvd为已经被分配预留但是还没有使用的page数目。在Oracle刚刚启动时，大部分内存应该都是Reserved并且Free的，随着Oracle SGA的使用，Reserved和Free都会不断的降低。

HugePages_Free – HugePages_Rsvd 这部分是没有被使用到的内存，如果没有其他的Oracle instance，这部分内存也许永远都不会被使用到，也就是被浪费了。在该系统上有11.5GB的内存被浪费了。

最佳实践

对于Oracle来说，这是一个最佳实践泛滥的时代，所有的最佳实践其实都有特定的应用场景，而不是放之四海皆准，但是当今信息爆炸时代（数据库种类爆炸时代），很多DBA没有那么多的耐心去专注学习一门数据库，只是拿来主义从网上找出一些最佳实践来，不管三七二十一就用到自己的环境中（甚至是生产环境中），一定程度上来说，崇拜最佳实践是懒惰的结果。

针对于Oracle的内存分配方式，肉丝给大家推荐在核心系统上： 1.使用手工的SGA管理，这种管理方式已经非常的成熟，但是这种方式对DBA要求较高，一定程度上需要了解业务特点。 2.如果第一种方法你感觉到比较难，那么使用ASMM，但是为buffer cache,shared pool设定最小值的方式，这种方式是我非常推荐的方式。

至于AMM这种内存分配方式，由于不能使用大页，建议不要去用。

具体到内存如何分配，针对是OLTP场景，还是OLAP场景，有着不同的内存分配原则，即使是OLTP场景，针对进程数的多少，并发数的多少，SQL语句的特点，都会导致产生不同的内存分配方法。作为DBA要掌握基本的Oracle内存使用原理，然后根据实际情况去根据业务自身特点分配内存。

不管是OLTP系统或者OLAP系统，一般都建议至少为操作系统预留出20%的内存空间，这些内存空间用于kernal、page table以及一些其他的进程需要，例如rman备份，文件系统缓存。这个也是Oracle官方的建议。

把这一部分的内存刨去后，针对OLTP系统，可以考虑先尝试预留出20%的内存给PGA使用，80%的内存给SGA使用。如果系统上进程数比较多，特别是同时活跃的进程数比较多，需要给PGA预留出更多的内存，可以按照每个进程12M的PGA占用进行计算。

针对OLAP系统，刨去操作系统的预留内存后，可以考虑预留出50%的内存给PGA使用，50%的内存给SGA使用。毕竟在纯OLAP下，buffer cache其实不需要那么大的内存空间。

SGA、PGA分配好后，要考虑到是否需要为buffer cache、shared pool来手工设定一个值，就像上文已经提到过的，可以参考buffer cache 的命中率，Library Hit的命中率作为一个辅助参考.如果命中率较低，有可能是内存分配的不够合理。当然你还需要借助于像AWR报告这样的工具，根据SQL的执行计划等内容来进一步的做诊断，比如命中率低的原因可能不是分配的buffer cache小，而是存在大量的低效的全表扫描，进而导致命中率低，这样的话，需要优化的就是SQL，而不是继续加大buffer cache。再比如，如果你发现Library cache Hit比较低，可能并不是shared pool比较小，还可能是系统的SQL存在大量未使用绑定变量的情况，导致硬解析过重。

优化经常是个系统工程，不能一蹴而就，特别像Oracle是一个很庞大的复杂系统，对于问题的出现，更是要仔细推敲，不能轻易的下结论。随着做DBA时间越来越长，你也会越来越懂TOM的一句话：It depends。

关于作者

魏兴华，沃趣科技高级技术专家，主要参与公司一体机产品、监控产品、容灾产品、DBaaS平台的研发和设计。曾就职于东软集团，阿里巴巴集团，Oracle ACE组成员，DBGEEK 用户组发起人，ITPUB认证博客专家，ACOUG、SHOUG核心成员。曾在Oracle技术嘉年华、ORCL-CON、YY分享平台等公开场合 多次做过数据库技术专题分享。对Oracle 并行机制、数据库异常恢复方法、ASM等有深入的研究，人称”Oracle Internal达人”，对企业数据库架构设计、故障恢复、高并发下数据库性能调优有丰富的经验，擅长从等待时间角度分析解决数据库性能问题，是OWI方法论的提倡者和践行者。

个人邮箱: [email protected]

其它白皮书

SQL MONITOR: http://pan.baidu.com/s/1gfO2DtL

Parallel原理实现： http://pan.baidu.com/s/1i5xun9F

12C IN-MEMORY： http://pan.baidu.com/s/1ge7r1oZ

（全文完结）