The shminfo_shmmax parameter modified by solaris is invalid.

Environment Introduction: Dual-machine operating system: solaris10 database version: oracle11gR164bit current host name and IP: fly-db2192.168.20.21 current slave host name and IP: fly-db1192.168.20.20

Environment Introduction: Dual-machine operating system: solaris10 database version: oracle11gR164bit current host name and IP: fly-db2192.168.20.21 current slave host name and IP: fly-db1192.168.20.20

Environment Introduction:

Dual-host operating system: solaris 10 database version: oracle 11g R1 64bit current host name and IP: fly-db2 192.168.20.21 current slave host name and IP: fly-db1 192.168.20.20

Background:

The physical memory of the master and slave machines is 94 GB. The physical memory of the slave machine is doubled recently, and the related memory parameters at the database layer are modified, and the operating system parameter shmsys: shminfo_shmmax of the Master/Slave machine. Note that the parameter shmsys: shminfo_shmmax of the Master/Slave machine has been modified. For more information, see the blog post at the following link.

After doubling the physical memory capacity of the fly-db1 host (current backup) tonight, restart the operating system, because the shmsys: shminfo_shmmax parameters of the master and backup machine have been modified, after restarting the operating system, in theory, the parameter settings take effect, through the dual-machine software to switch the database from the fly-db2 to the fly-db1, switching failed, in the dual-machine software, view out of memory error, in the Database alert Log, the following error is reported:

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 if manually started, the following Error is reported: SQL> startupORA-27102: out of memorySVR4 Error: 22: Invalid argumentbash-3.00 $ oerr ora 2710227102,000 00, "out of memory" // * Cause: Out of memory // * Action: Consult the trace file for details

From the above error analysis, because the use of the same database, the operating system level only modified the shmsys: shminfo_shmmax parameter, positioned as the current backup fly-db1 this parameter settings did not take effect

1. Compare the/etc/system files of the master and slave machines to the same

Bash-3.00 # hostnamefly-db1bash-3.00 # diff/etc/system/home/oracle/system_flydb2_13121_bak

2. Baidu's solaris out of memory, view the following blog, which involves the/etc/project file. We can understand the/etc/project file in this way, if the same parameters are set in/etc/system and/etc/project, the operating system ignores the setting of/etc/system and uses the setting of/etc/project, the/etc/project file can set parameters that only take effect for specific users.
Https://blogs.oracle.com/mandalika/entry/oracle_on_solaris_10_fixing Oracle on Solaris 10: Fixing the 'ora-27102: out of memory 'Error

3. Check that the maximum size of max-shm-memory is 60 GB in the/etc/project of the current backup fly-db1 host, that is, the maximum shared memory segment is 60 GB, as follows:

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. view the/etc/project content of the current host (fly-db2), without setting the maximum value of max-shm-memory, so in this operating system, the setting of/etc/system takes effect.

Bash-3.00 # hostnamefly-db2bash-3.00 # cat/etc/projectsystem: 0: user. root: 1: noproject: 2: default: 3: group. staff: 10 ::::

5. Change the/etc/project of the current backup fly-db1 to the same as the/etc/project of the current host

Bash-3.00 # hostnamefly-db1bash-3.00 # cat/etc/projectsystem: 0: user. root: 1: noproject: 2: default: 3: group. staff: 10 ::::

6. Restart the Operating System

Bash-3.00 # syncbash-3.00 # syncbash-3.00 # syncbash-3.00 # shutdown-i6-g0-y

7. Switch to the slave fly-db1

The following content is from: 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,000 00, "out of memory" // \ * Cause: Out of memory // \ * Action: consult the trace file for detailsNot so helpful. let's look at 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. 8 M 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 3 project: 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 = mongoshminfo_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 3 project: 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) 'oss % usermod-K project = OASB oracleFinally make sure the project is created with projects-l or cat/etc/project commands. % projects-l ...... OASBprojid: 3 comment: "eBS benchmark" users: 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 wocould start the database up normally. SQL> startupORACLE instance started. total System Global Area 1.0905E + 10 bytesFixed Size1316080 bytesVariable Size4429966096 bytesDatabase buffers64000050944 bytesRedo Buffers31457280 bytesDatabase mounted. database opened.

This article is from the "yangyang Youqing" blog. Be sure to keep this source