问题概述
某客户一套19c生产环境在主机层面对内存进行了扩容,DBA随后对数据库的SGA的大小进行调整,调整完重启实例时报ORA-27104,无法正常启动实例。
如下图所示,SGA原大小为8G,现调整为32G
闭实例,再启动实例到nomount状态,提示ORA-27104报错:
问题原因
查看数据库alert日志:
提示‘System cannot support SGA size of 32GB’及‘Increase the system shared memory size to at least 32GB’:
在Linux下,系统共享内存由kernel.shmall、kernal.shmmax两个内核参数控制:
- kernel.shmall参数控制系统一次可以使用的共享内存总量(以页为单位)。在Linux 共享内存页大小为4KB,如果一个共享内存段的最大大小是32GB,那么需要共享内存页数是 32GB/4KB = 33,554,432KB/4KB = 8,388,608(页),该参数的值始终应该至少为: ceil(SHMMAX/PAGE_SIZE)。
- kernal.shmmax参数用于定义一个内存段最大可以分配的内存空间,单位为字节。这个值的设置应该大于SGA_MAX_TARGET或MEMORY_MAX_TARGET的值,最大值可以设置成大于或等于实际的物理内存。
查看操作系统中两个参数的配置情况:
发现kerlenel.shmall和kernel.shmmax参数配置的确过小,无法满足32G SGA的大小要求。
解决方案
1、调整kernel.shmall、kernal.shmmax参数。
kernel.shmall计算公式为:shmmax/page_size,推荐设置为物理内存大小除以分页大小。
kernal.shmmax计算公式为:单个内存段大小(bytes),推荐为物理内存的大小。
2、sysctl -p使参数立即生效。
3、再次启动实例,未报错,问题解决。
标签:kernel,27104,SGA,shmmax,参数,Oracle,共享内存,shmall From: https://blog.51cto.com/u_13482808/6507426