首先，为什么要介绍/使用HugePage?
在步入正题之前,先讲一个非常普遍的数据库性能问题。
众所周知,Oracle数据库使用共享内存(SGA)来管理可以共享的一些资源;比如shared pool中存储了共享的SQL语句及执行计划,buffer pool中存储了数据块。对这些资源的访问,其实就是Oracle使用OS的API来访问内存资源的过程。内存操作理应/通常意义上都是很快的,这时候Oracle数据库可以很正常的工作。
但是
a)如果SGA内的某一部分被swap到硬盘上,那么再次访问它,就需要花非常多的时间
b)如果OS本身的内存非常的大,那么管理/访问到我们需要的内存的过程就需要更长时间。
在这些情况下,我们往往会碰到诸如latch/mutex/library cache lock[pin]/row cache lock的问题.
Linux下HugePage 可以解决由以上两种问题引发的性能波动。
我们知道，在Linux 64位系统里面,默认内存是以4K的页面（Page）来管理的,当系统有非常多的内存的时候,管理这些内存的消耗就比较大;而HugePage使用2M大小的页面来减小管理开销。HugePage管理的内存并不能被Swap，这就避免了swap引发的数据库性能问题。所以，如果您的系统经常碰到因为swap引发的性能问题的系统毫无疑问需要启用HugePage。另外，OS内存非常大的系统也需要启用HugePage。但是具体多大就一定需要使用HugePage？这并没有定论，有些文档曾经提到12G以上就推荐开启，我们强烈建议您在测试环境进行了充分的测试之后，再决定是否在生产环境应用HugePage。
当然，任何事情都是有两面性的，HugePage也有些小缺点。第一个缺点是它需要额外配置，但是这完全是可以忽略的。另外，如果使用了HugePage，11g新特性AMM（Automatic Memory Management）就不能使用了，但是ASMM（Automatic
Shared Memory Management）仍然可以继续使用。
接下来，我们对配置HugePage需要完成的步骤进行介绍。以下步骤以RHEL5为例。
a)设置memlock的限制，更改/etc/security/limits.conf加入下面的行
注意上面的数字是以 K 为单位的，可以让它的值稍微比系统的物理内存小就可以了
b)检查memlock是否生效，要使用oracle的用户执行下面的操作，如果没有生效尝试重新登陆系统
c)如果使用11g数据库，确认参数MEMORY_TARGET和MEMORY_MAX_TARGET已经设为0
d)启动数据库，并运行Document
401749.1提供的脚本来计算应该分配多少HugePage页面。例如：
e)更改/etc/sysctl.conf，把上一步得到的值指定给vm.nr_hugepages参数
f)重启数据库和OS。
g)验证HugePage是否已启用
如下图，HugePage一共分配了1496个页面，其中有6个页面为Free,那么使用了1490个页面,每个页面为2048K.
最后，如果您想了解更多的和HugePage相关的问题，请参考以下的note。
Note 361323.1 : HugePages on Linux: What It
Is... and What It Is Not...
Note 361468.1 : HugePages on Oracle Linux
64-bit
关于这个主题，如果有后续的问题欢迎点击链接参与我们在中文社区的讨论。