环境介绍：双机操作系统：solaris10数据库版本：oracle11gr164bit当前主机的主机名称和ip：fly-db2192.168.20.21当前备机的主机名称和ip：fly-db1192.168.20.20
环境介绍：
双机操作系统：solaris 10数据库版本：oracle 11g r1 64bit当前主机的主机名称和ip：fly-db2 192.168.20.21当前备机的主机名称和ip：fly-db1 192.168.20.20背景：
       主备机的物理内存均为94g，近期对备机的物理内存扩容一倍，并修改了数据库层面的相关内存参数，以及主备机的操作系统参数shmsys:shminfo_shmmax，注意是主备的shmsys:shminfo_shmmax参数均已修改，详情请查看下面链接的博文
今晚对fly-db1主机（目前的备机)的物理内存扩容一倍后，重启操作系统，因主备机的shmsys:shminfo_shmmax参数均已经修改，重启操作系统后，理论上该参数设置生效，通过双机软件将数据库从fly-db2切换到fly-db1，切换失败，在双机软件中，查看到out of memory错误，在数据库alert日志，查看到如下报错：
warning: the system does not seem to be configuredoptimally. creating a segment of size 0x0000000220000000failed. please change the shm parameters so thata segment can be created for this size. while this isnot a fatal issue, creating one segment may improve performance如果手工启动，则报错如下：sql> startupora-27102: out of memorysvr4 error: 22: invalid argumentbash-3.00$ oerr ora 2710227102, 00000, out of memory// *cause: out of memory// *action: consult the trace file for details     从以上报错分析，因为使用的是同一个数据库，操作系统层面只修改了shmsys:shminfo_shmmax参数,定位为当前备机fly-db1该参数设置未生效
   1、对比主备机的/etc/system文件，是一致的
bash-3.00#hostnamefly-db1bash-3.00# diff /etc/system /home/oracle/system_flydb2_131220.bak     2、百度之solaris out of memory,查看到以下blog，文章中涉及/etc/project文件，我们可以这么理解/etc/project文件，如果/etc/system和/etc/project中设置了相同的参数，则操作系统会忽略/etc/system的设置，而采用/etc/project的设置，/etc/project文件可以针对特定用户设置只对自己生效的参数
https://blogs.oracle.com/mandalika/entry/oracle_on_solaris_10_fixing   oracle on solaris 10 : fixing the 'ora-27102: out of memory' error
    3、查看到当前备机fly-db1主机的/etc/project中设置了max-shm-memory的最大大小为60g，即最大的共享内存段为60g，如下所示：
bash-3.00# hostnamefly-db1bash-3.00# cat /etc/projectsystem:0::::user.root:1::::noproject:2::::default:3::::project.max-shm-memory=(privileged,64424509440,deny)group.staff:10::::bash-3.00# bcscale=564424509440/1024/1024/102460.00000    4、查看当前主机（fly-db2）的/etc/project内容，未设置max-shm-memory的最大值，，所以在该操作系统，生效的是/etc/system的设置
bash-3.00#hostnamefly-db2bash-3.00# cat /etc/projectsystem:0::::user.root:1::::noproject:2::::default:3::::group.staff:10::::   5、将当前备机fly-db1的/etc/project修改成和当前主机的/etc/project一样
bash-3.00#hostnamefly-db1bash-3.00# cat /etc/projectsystem:0::::user.root:1::::noproject:2::::default:3::::group.staff:10::::   6、重启操作系统
bash-3.00# syncbash-3.00# syncbash-3.00# syncbash-3.00# shutdown -i6 -g0 -y  7、双机切换，成功切换到备机fly-db1
以下内容来自：https://blogs.oracle.com/mandalika/entry/oracle_on_solaris_10_fixingsymptom:as part of a database tuning effort you increase the sga/pga sizes; and oracle greets with an ora-27102:out of memory error message. the system had enough free memory to serve the needs of oracle.sql> startupora-27102: out of memorysvr4 error: 22: invalid argumentdiagnosis$ oerr ora 2710227102, 00000, out of memory// \*cause: out of memory// \*action: consult the trace file for detailsnot so helpful. let's look the alert log for some clues.% tail -2 alert.logwarning: einval creating segment of size 0x000000028a006000fix shm parameters in /etc/system or equivalentoracle is trying to create a 10g shared memory segment (depends on sga/pga sizes), but operating system (solaris in this example)responded with an invalid argument (einval) error message. there is a little hint about setting shm parameters in /etc/system.prior to solaris 10, shmsys:shminfo_shmmax parameter has to be set in /etc/system with maximum memory segment value that canbe created. 8m is the default value on solaris 9 and prior versions; where as 1/4th of the physical memory is the default on solaris 10and later. on a solaris 10 (or later) system, it can be verified as shown below:% prtconf | grep memmemory size: 32760 megabytes% id -puid=59008(oracle) gid=10001(dba) projid=3(default)% prctl -n project.max-shm-memory -i project 3project: 3: defaultname privilegevalue flag actionrecipientproject.max-shm-memoryprivileged7.84gb- deny-system16.0eb max deny-now it is clear that the system is using the default value of 8g in this scenario, where as the application (oracle) is trying tocreate a memory segment (10g) larger than 8g. hence the failure.so, the solution is to configure the system with a value largeenough for the shared segment being created, so oracle succeeds in starting up the database instance.on solaris 9 and prior releases, it can be done by adding the following line to /etc/system, followed by a reboot for the systemto pick up the new value.set shminfo_shmmax = 0x000000028a006000however shminfo_shmmax parameter was obsoleted with the release of solaris 10; and sun doesn't recommend setting this parameterin /etc/system even though it works as expected.on solaris 10 and later, this value can be changed dynamically on a per project basis with the help of resource control facilities . this ishow we do it on solaris 10 and later:% prctl -n project.max-shm-memory -r -v 10g -i project 3% prctl -n project.max-shm-memory -i project 3project: 3: defaultname privilegevalue flag actionrecipientproject.max-shm-memoryprivileged10.0gb- deny-system16.0eb max deny-note that changes made with the prctl command on a running system are temporary, and will be lost when the system is rebooted. to makethe changes permanent, create a project with projadd command and associate it with the user account as shown below:% projadd -p 3 -c 'ebs benchmark' -u oracle -g dba -k 'project.max-shm-memory=(privileged,10g,deny)' oasb% usermod -k project=oasb oraclefinally make sure the project is created with projects -l or cat /etc/project commands.% projects -l......oasbprojid : 3comment: ebs benchmarkusers : oraclegroups : dbaattribs: project.max-shm-memory=(privileged,10737418240,deny)% cat /etc/project......oasb:3:ebs benchmark:oracle:dba:project.max-shm-memory=(privileged,10737418240,deny)with these changes, oracle would start the database up normally.sql> startuporacle instance started.total system global area 1.0905e+10 bytesfixed size1316080 bytesvariable size4429966096 bytesdatabase buffers6442450944 bytesredo buffers31457280 bytesdatabase mounted.database opened.
本文出自 “斜阳悠悠寸草心” 博客，请务必保留此出处