The shminfo_shmmax parameter modified by solaris is invalid.

Environment Introduction:

Dual
Operating system: solaris 10
Database version: oracle 11g R1 64bit
Host name and IP of the current host: fly-db2 192.168.20.21
Host name and IP of the current standby machine: 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.
Http://fly1116.blog.51cto.com/8301004/1343788
After the physical memory capacity of the fly-db1 host is doubled, the operating system is restarted, because the shmsys: shminfo_shmmax parameters of the master and slave machine have been modified, after the operating system is restarted, 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 configured
optimally. Creating a segment of size 0x0000000220000000
failed. Please change the shm parameters so that
a segment can be created for this size. While this is
not a fatal issue, creating one segment may improve performance
If you start it manually, the error is as follows:
SQL> startup
ORA-27102: out of memory
SVR4 Error: 22: Invalid argument
bash-3.00 $ oerr ora 27102
27102, 00000, "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#hostname
fly-db1
bash-3.00# diff /etc/system /home/oracle/system_flydb2_131220.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# hostname
fly-db1
bash-3.00# cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::project.max-shm-memory=(privileged,64424509440,deny)
group.staff:10::::
bash-3.00# bc
scale=5
64424509440/1024/1024/1024
60.00000

4, view the current host fly-db2) of the/etc/project content, the maximum value of max-shm-memory is not set, so in this operating system, the effect is the/etc/system settings

bash-3.00#hostname
fly-db2
bash-3.00# cat /etc/project
system: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#hostname
fly-db1
bash-3.00# cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::

6. Restart the Operating System

bash-3.00# sync
bash-3.00# sync
bash-3.00# sync
bash-3.00# shutdown -i6 -g0 -y

7. Switch to the slave fly-db1

 

The following content comes from:
https://blogs.oracle.com/mandalika/entry/oracle_on_solaris_10_fixing
Symptom:
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> startup
ORA-27102: out of memory
SVR4 Error: 22: Invalid argument
Diagnosis
$ oerr ORA 27102
27102, 00000, "out of memory"
// \ * Cause: Out of memory
// \ * Action: Consult the trace file for details
Not so helpful. Let's look the alert log for some clues.
% tail -2 alert.log
WARNING: EINVAL creating segment of size 0x000000028a006000
fix shm parameters in / etc / system or equivalent
Oracle 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 can
be 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 10
and later. On a Solaris 10 (or later) system, it can be verified as shown below:
% prtconf | grep Mem
Memory size: 32760 Megabytes
% id -p
uid = 59008 (oracle) gid = 10001 (dba) projid = 3 (default)
% prctl -n project.max-shm-memory -i project 3
project: 3: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 7.84GB-deny-
system 16.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 to
create a memory segment (10G) larger than 8G. Thus the failure.So, the solution is to configure the system with a value large
enough 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 system
to pick up the new value.
set shminfo_shmmax = 0x000000028a006000
However shminfo_shmmax parameter was obsoleted with the release of Solaris 10; and Sun doesn't recommend setting this parameter
in / 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 is
how 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: default
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 10.0GB-deny-
system 16.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 make
the 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 oracle
Finally make sure the project is created with projects -l or cat / etc / project commands.
% projects -l
...
...
OASB
projid: 3
comment: "eBS benchmark"
users: oracle
groups: dba
attribs: 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> startup
ORACLE instance started.
Total System Global Area 1.0905E + 10 bytes
Fixed Size 1316080 bytes
Variable Size 4429966096 bytes
Database Buffers 6442450944 bytes
Redo Buffers 31457280 bytes
Database mounted.
Database opened. 

 

 

This article from the "Yang youyoucuncaoxin" blog, please be sure to keep this source http://fly1116.blog.51cto.com/8301004/1343864