问题背景:
用户来电报故障，他们一套正常运行的Oracle数据库，突然出现了10分钟左右的性能卡顿问题，期间全部的业务操作都变慢，他们通过查看问题期间的awr报告，发现数据库在问题时间出现大量的libary cache等待事件，但每秒的硬解析并不高，不知道是什么原因导致的数据库性能问题，需要我们查找问题的原因。
问题分析:
分析问题时间段的awr报告，可以看到问题期间的TOP等待事件相比与正常时间段，多了很多的涉及SGA内存池buffer pool，shared pool的内存latch锁等待事件。
查看数据库的配置以及运行指标，问题时间段数据库的负载相对还是比较高的，属于业务的高峰期，每秒的SQL执行35699次，并且存在一定数量的SQL硬解析每秒平均17次，此外，数据库的服务器内存配置为1T，SGA配置为500G，其中buffer cache和shared pool的配置分别为450048M以及50097M，这个内存配置还是比较大的。
继续往下分析，由于数据库服务器没有配置OSW等其他的资源监控工具，我们只能通过AWR里面操作系统的性能统计进行分析，可以看到问题时间段内存分页写入磁盘虚拟内存swap的计数VM_OUT_BYTES(Bytes paged out due to virtual memory swapping)数量有大幅的增长，短时间出现这么多的内存分页操作，很有可能是当时的操作系统内存已经耗尽或是内存参数配置不合理导致，而内存分页写入到磁盘的操作，会导致数据库性能出现下降甚至卡顿，因为在内存里面的操作速度跟在磁盘里面的操作速度不是一个量级的，这也难怪问题时间段数据库出现大量的内存池latch锁等待。
分析数据库当前的内存使用情况，当前服务器的配置内存为1T，HugePage巨页内存分配了402G，但可以看到HugePages_Free的剩余内存为396G，也就是说数据库其实没有使用到这一部分的巨页内存 ，而服务器程序进程的通常也不会使用到巨页内存，所以这部分内存被完全闲置。
从数据库实例最近一次启动的alert日志，也可以看到数据库实例初始化SGA的时候并没有用到巨页内存。
计算服务器总的内存分配情况，数据库SGA配置500G，PGA配置125G，因为SGA没有存放在HugePage巨页内存里面，所以实际的服务器内存分配情况为SGA+PGA+HugePage=1027G,这里还没算上集群以及操作系统其他服务使用使用到的内存，而服务器的内存为1T，实际可以使用为1010G左右，所以当前服务器的内存已经属于超配的情况。
对于服务器的内存出现超配的问题，只要数据库并发负载增高或者出现大排序或是使用了大量内存的慢语句，都很有可能会导致操作系统物理内存分页写入了磁盘虚拟内存，进而导致一个平常看起来运行正常的数据库突然出现了性能卡顿的问题。
问题解决:
当前的数据库服务器内存为1T，SGA配置为500G，对于这种大内存的数据库，开启大页内存的做法是合理的，因为它可以确保数据库SGA内存不会交换出去以及减少内存页的分配争用，但对于设置大页内存，一定要按正确的步骤进行设置，并确认数据库实例SGA内存已经使用到，小心将提升性能的方法变成引发性能恶化的问题。
大页内存大致步骤可以参考以下
1 计算大页内存的配置大小，可以使用官方的hugepages_settings.sh脚本进行评估或者按公式(SGA大小/M+5120M)/2M。
2 关闭数据库实例，并确认数据库实例使用到的共享内存已经释放。
3 变更配置操作系统文件/etc/sysctl.conf，配置大页内存参数。
--设置大页内存页数
vm.nr_hugepages= 66560
--设置大页内存的用户oracle的gid
vm.hugetlb_shm_group =543214 变更配置操作系统文件/etc/security/limits.conf，设置oracle用户大页内存资源限制为无限制。
oracle soft memlock unlimited
oracle hard memlock unlimited5 生效大页内存参数，并通过操作系统/proc/meminfo文件确认大页内存是否被使用。
sysctl -p6 启动数据库实例。
7 确认数据库实例使用到大页内存，并通过数据库启动的alert日志和操作系统/proc/meminfo文件确认大页内存是否被使用。
