Reference Architecture: Consolidating Oracle Databases with Secure Resource Partitions in a Serviceguard Cluster Whitepaper

General considerations

It is common to have a single Oracle administrative domain for systems running multiple Oracle

database servers. With SRPv2, you can create an isolated execution and administration domain,

enabling the creation of multiple Oracle administrative domains, one for each SRP. By creating

individual administrative domains, you can restrict which databases database administrators can

access.

In this reference architecture, you deploy each Oracle database within a single SRP, creating a 1 to 1

SRP to Oracle mapping. Database administrators must log in to each individual SRP to perform

administrative tasks. If a user is responsible for managing multiple databases, the administrator can

add the user ID to the UNIX group allowed to log in to additional SRPs. This access provides the user

Start/stop

In this Reference Architecture, the database starts and stops automatically with the SRP. The SRP starts

and stops with the system.

At system start/stop, a single SRP rc script is executed. This script starts and stops each SRP that is

configured to automatically start and stop (see /etc/rc.config.d/srpconf). When an SRP starts or

stops, its SRP private start/stop scripts (/var/hpsrp/<SRP>/sbin/init.d) are executed, very similar to

the system startup/shutdown. By placing the Oracle startup scripts in the SRP private rc directory, the

database starts and stops with the SRP, even during normal operating times. This increases SRP

portability and helps ease integration with Serviceguard.

CPU entitlements

SRPv2 uses PRM to enforce CPU entitlements for the workloads running within the HP SRPv2. PRM

supports two types of CPU entitlements:

 Fair Share Scheduler (FSS)—CPU entitlements are specified in shares of the available cores. FSS

groups are configured with a minimum (guaranteed) CPU entitlement and optionally a maximum

(CAP) CPU entitlement that the group must not exceeded even if unused CPU cycles are available.

 Processor Sets (PSET)—A PSET assigns CPU entitlement by assigning a subset of the system cores

that are dedicated to that group.

You can configure an SRP using either of these entitlements. FSS enables the greatest resource

utilization in which the SRP can use available CPU beyond its guaranteed shares (up to its CAP if

configured). PSET reserves the core for the group even if the workload does not require the resource,

making it unavailable to other workloads on the system.

Before choosing a CPU scheduling type, consider Oracle licensing options. For FSS, Oracle licensing

requires that all cores on the system are licensed. For PSETs, only the cores in that PSET require a

license. In this Reference Architecture, PSETs are used for CPU scheduling. For more information on

Oracle licensing, consult with Oracle. For detailed information on using PRM with Oracle databases,

see the HP white paper Using HP Process Resource Manager with Oracle databases:

http://h20338.www2.hp.com/hpux11i/downloads/PRM-Oracle_white_paper.pdf.

Software installation

When deploying an Oracle database server within an SRP, consider the following application

software installation/deployment options:

 Single installation/Multi-instance—You can install a single copy of the application on the system

supporting multiple instances of the application. Each instance of the application shares the same