Solaris Resource Manager ORACLE Wrapper Version 1.0

WARNING: 

This is an unsupported software. Oracle will accept no liability for problems arising from its use, nor does Oracle warrant its fitness for any purpose. Its use is purely discretionary at the sole risk of the user!!

Introduction 
The purpose of this tool is to allow ORACLE instances to be managed effectively under the control of the Solaris Resource Manager (SRM). It does this by ensuring that all ORACLE background and server processes belonging to a particular instance run in an administrator-specified  limit node (lnode). The administrator can then manage the resources  consumed by each instance by configuring the limits for these lnodes.

SRM Background

When installed on Solaris 2.6, 7, or 8, the Solaris Resource Manager 1.x adds the ability to control and account for resource usage (i.e. CPU and virtual memory) among lnodes organized in a hierarchical grouping scheme called the scheduling tree, whose root is always the lnode "root".

With SRM, every user is considered an lnode (limit node), which is the unit of resource management. Note that the users need not be "real" users, in other words they must have a /etc/passwd entry, but need not have an entry in /etc/shadow. For example, though ORACLE instances are typically run as the user "oracle", in order to manage the resource usage of instance 1 separately from that of instance 2, we might create dummy lnodes named "oracle1" and "oracle2".

Each lnode has a set of limit attributes that are set up by the administrator to specify the resource usage for the lnode. For example, the "cpu.shares" attribute of "oracle" lnode, when compared with the "cpu.shares" attribute of oracle's sibiling lnodes and the "cpu.myshares"  attribute of oracle's parent lnode, determines what proportion of CPU time will be allocated to processes running in the oracle lnode. For example, consider the following configuration:

oracle (cpu.myshares = 2)
+-oracle1 (cpu.shares = 1)
+-oracle2 (cpu.shares = 1)

Assuming all three lnodes have active processes, since there are a total of four shares, processes running in the oracle lnode will receive 50%
of the CPU available to this scheduling subtree, while 25% will go to each of the oracle1 and oracle2 subtrees.

Another pair of useful limit attributes are "memory.myusage", which controls the amount of virtual memory that can be allocated by processes in an lnode, and "memory.usage", which limits the total virtual memory space used by an lnode and all of its children. Care should be taken to allow ORACLE instances to allocate as much memory as they might require during normal operation.

To learn more about the features, use and availability of SRM, please click here.  

ORACLE and SRM

For a standard ORACLE installation environment, instances are started up as the oracle user. Hence, all background processes will also run in  the lnode oracle, and are subject to its limits. Also, the server processes are usually spawned by a single Listener, and so they are automatically  associated with the Listener's lnode, which is typically oracle. This presents a challenge to independently managing multiple ORACLE instances  via SRM on a single system.

This software solves the problem by allowing the administrator to specify which lnode each particular instance (identified by its ORACLE_SID) should be associated with at run-time. This mapping is managed by editing a text configuration file in /var/opt/oracle/orasrm. After this software is installed, whenever an ORACLE process is started it will use its ORACLE_SID environment variable to look up its associated lnode, attach itself to that lnode, and then continue execution.

Installation and Configuration

Download the ZIP file. In the software package, you should find the following files:

README - Overview, Description and Installation Instructions
install.sh - simple install script
uninstall.sh - simple uninstall script
oracle_wrapper - the wrapper program
orasrm - sample of /var/opt/oracle/orasrm

The following three steps will set up this software for use with ORACLE. You must already have SRM running on the system.

1. Configure lnodes for use with ORACLE

The SRM ORACLE wrapper can only place ORACLE processes in the "oracle" lnode, or lnodes that are in the scheduling subtree of oracle. Therefore, you should plan out how many lnodes (how many independently managed sets of ORACLE processes) you would like to configure and create them beforehand (you can use the useradd command). Use the limadm command to  assign lnodes to the "oracle" scheduling group:

> limadm set sgroup=oracle oracle1
> limadm set sgroup=oracle oracle2

This places both the "oracle1" and "oracle2" lnodes under the oracle lnode. Hence, instances can be configured to run in these lnodes.

The user "oracle" must also be given group administrator privileges in order for processes to launch themselves under any lnodes in the oracle lnode subtree:

> limadm set flag.admin=set oracle

2. Create the configuration file

The file "orasrm" included with this package is a sample configuration file. This file must be copied to /var/opt/oracle/orasrm, and should be modified to indicate which lnode each instance should run in. The file must also be made readable by the user oracle. For example (assuming you have the appropriate privileges):

> cd {srm_wrapper path}

> cp orasrm /var/opt/oracle/orasrm
> chown oracle:oracle /var/opt/oracle/orasrm
> emacs /var/opt/oracle/orasrm (edit the file to suit your environment)

The format of the configuration file is clear from the sample orasrm file. Each entry in the file specifies the ORACLE_SID of an instance on the system along with its associated lnode, separated by a colon ":". For example, the two entries

instance1:oracle1
instance2:oracle2

will make all the processes of the ORACLE instance with ORACLE_SID=instance1 attach themselves to the lnode oracle1, and the processes of instnace2 will be in the lnode oracle2.

3. Install the wrapper program

Since this installation recreates oracle binary, you must shut down all active instances before installing the wrapper program. Once this is done, execute the "install.sh"scripts once each for different ORACLE homes on the system. So, if you have 3 ORACLE_HOMEs on a machine, this steps must be performed thrice after setting the oracle environment appropriately.

The script will rename the original oracle binary to "oracle.srm", and will replace it by the oracle_wrapper program included in the package.

A simple uninstall script "uninstall.sh" can also be executed for eachORACLE home installation to undo the effect of "install.sh".


Once the installation is complete, the instances may be started up and all processes should be assigned to their appropriate lnodes.

The wrapper program tests for various errors, most of which are non-fatal. That is, an error message will appear, but the program will still run. Bear in mind, though, that an error message indicates an unsuccessful attempt to run the Oracle process in the lnode nominated in the orasrm file.

Software Download

• Solaris Resource Manager Oracle Wrapper Version 1.0 

References and Acknowledgements

For more information on Solaris resource management, refer to the Sun Blueprints series book on Resource Management by Richard McDougall, Adrian Cockcroft, Evert HOogendoorn, Enrique Vargas, and Tom Bialaski.

This software was originally designed and implemented by Allan Packer (allan.packer@sun.com) of Sun Microsystems in March 2002. For more information on ORACLE and SRM, refer to page 215 of "Configuring and Tuning Databases on the Solaris Platform", by Allan N. Packer,
Sun Press, (c)2002.