enabling solaris project settings for crs [id 435464.1]

ENABLING SOLARIS PROJECT SETTINGS FOR CRS [ID 435464.1]

Modified 09-MAY-2011 Type BULLETIN Status PUBLISHED

In this Document Purpose Scope and Application ENABLING SOLARIS PROJECT SETTINGS FOR CRS Short Remark on CRS and multiple Solaris projects References

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.5 and later [Release: 10.1 and later ] Oracle Solaris on SPARC (64-bit) Oracle Solaris on x86-64 (64-bit) Oracle Clusterware (CRS) and patchsets 10.2.0.1 - 11.2.0.1 Sun Solaris Sparc and x86-64 (64-bit)

Purpose

This Note discusses options available to enable automatic start of CRS with Solaris 10 project settings. Due to the CRS fixes available in CRS versions 11.2.0.2 this note ultimately applies only to CRS versions not including a fix for bug 9442360 (bug id affecting 11.2.0.x CRS versions) or bug 5629487 (bug id affecting 10.2.0.x - 11.1.0.x CRS versions). If a fix for bug 5629487 or bug 9442360 is present in the CRS install then this note can be ignored or read as informational.

Scope and Application

Please notice that both Sun Microsystems and Oracle still support the old method of supplying these values for shared memory and semaphore parameters in /etc/system. The various methods presented in this document are thus not explicitly recommended although they have been verified to work.

ENABLING SOLARIS PROJECT SETTINGS FOR CRS

When enabling project settings for legacy type daemons (i.e. in Solaris 10 terminology those daemons not managed as SMF services) DBA's and System Administrators face difficulties to enable Oracle required OS parameters like SHMMAX or SEMMNS (this being the pre Solaris 9/10 and pre Solaris 10 Containers terminology) through the newer project settings and enable project settings at boot time. To enable project settings at boot time a basic difficulty arises as Solaris 10 does not support any user defined projects for legacy_run daemons. In order to overcome this difficulty two options exist: 1. change SYSTEM project settings which is active at boot time 2. use newtask -p <user project> command for the daemon needing project settings or other means of changing the task project. Solution 1: Change SYSTEM project settings This still can be achieved in at least two ways: A. Modify limits for the parameters of interest: Example:

projmod -s -K "project.max-shm-memory=(privileged,2.00TB,deny)" system projmod -s -K "project.max-sem-ids=(privileged,2048,deny)" system

I.e. /etc/project would look like:

system:0::::project.max-sem-ids=(privileged,2048,deny);project.max-shm-memory=(privileged,2199023255552,deny) user.oracle:100::::project.max-sem-ids=(privileged,2048,deny);project.max-shm-memory=(privileged,2199023255552,deny)

The last entry is needed for the Oracle user to startup instances when connecting directly with sqlplus in an user session while the first line for system project is needed by the boot time CRSD database startup or by manual srvctl startup. This method is not supported due to the problems described in below section:

of 3

11/26/2011https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=435464.1

"Problems which might be encountered when implementing Solution 1A" B. Instead of changing /etc/project (and /etc/user_attr as per below problem section) dynamic changes of system project through prctl command can be added in an own rc script:

prctl -n project.max-shm-memory -v <value needed> -r -i project system prctl -n project.max-sem-ids -v <value needed> -r -i project system

This own rc script would need to be executed before the rc3.d/S96init.crs would be executed and also an entry like "system:0::::" needs to exist in /etc/project for this solution to work. Example: /etc/rc3.d/S91proj:

#!/bin/sh prctl -n project.max-shm-memory -v 2.2TB -r -i project system prctl -n project.max-sem-ids -v 2048 -r -i project system

Solution 2: Assigning process to a different task and project This as well can be achieved in different ways but basically the CRSD daemon needs to receive the new project settings. A. either by editting the init.crsd script and adding a line like:

newtask -p <user_project> -c $$ or newtask -p <user_project> $ORA_CRS_HOME/bin/crsd $BOOTFLAG $*

The latter is implemented by Oracle's fix for bug 5629487, which is included in CRS 11.1.0.7 so this method should be considered supported. The fix for bug 5629487 needed more review for CRS 11gR2 and so it has been addressed for 11.2.0.x versions under bug 9442360 and included in the 11.2.0.2 release. B. Moving the CRS init scripts to SMF and adding to the new init.crsd service

<method_context project='some_userdefined_crsproj' > <method_credential user='root' /> </method_context> </exec_method>

This method is not supported either and shouldn't be used as long as CRS scripts are not yet integrated into SMF. Verification of project settings taking effect For Solution 1 to verify the system project settings were altered after issuing the above projmod command the following prctl command for the init process can be run: prctl -n project.max-shm-memory 1 which would need to show a line:

privileged 2.00TB - deny -

Problems which might be encountered when implementing Solution 1A It was reported that implementing Solution 1A was not allowing to startup the database service automatically at boot time of CRS. Some tests showed that adding project=system to /etc/users_attr for user root was at least allowing to startup manually the database through srvctl command.

I.e. /etc/user_attr needed to look like:

root::::auths=solaris.*,solaris.grant;profiles=Web Console Management,All;lock_after_retries=no;project=system

After more research this was found to happen due to Solaris CR#5000940:

Synopsis: project 0's rctls are not applied from /etc/project

Another observed side effect is that if someone logins to the server before CRS started up then automatic startup of the database might succeed. This too is included in the description of Solaris CR#5000940.

of 3


As per Solaris CR#5000940 the best way to avoid the problem is to execute a command like:

newtask -p system /usr/bin/true

before CRS startup, i.e. creating an rc script /etc/rc3.d/S91proj:

#!/bin/sh # # see http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5000940 # why this is needed # newtask -p system /usr/bin/true

would resolve these issues.

To summarize for Solution 1A to work these changes are needed:

/etc/project needs to have system project modified as in above example,

/etc/user_attr does not need to be modifed and

a script needs to be created (e.g. /etc/rc3.d/S91proj) containing the command "newtask -p system /usr/bin/true"

Short Remark on CRS and multiple Solaris projects

The current design of CRS/GRID is to support only the CRS/GRID install user's project to be enabled for the database instances which are automatically started as CRS resources. Unlike when starting up an instance in an user session and enabling whichever project might be desired the same is currently not possible in CRS/GRID. This statement refers to all current versions, patchset and PSU releases of CRS and GRID, i.e. 10.2.0.1.0 - 11.2.0.2.x

References

BUG:5629487 - WRONG RESOURCE CONTROL PROJECT SELECTED WHEN STARTING DATABASE USING SRVCTL NOTE:429191.1 - Kernel setup for Solaris 10 using project files. NOTE:603051.1 - SRVCTL FAILS TO START DATABASE WHILE SQLPLUS WORKS http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5000940

Related

Products

Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition •

Keywords

CRS-215; ORA-27102; PRKP-1001; SOLARIS; SRVCTL

Back to top

Copyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement

of 3


enabling solaris project settings for crs [id 435464.1]

Documents