Using HP PRM with Oracle Databases

5
Database Resource Manager
Oracle 8i and later have their own resource management tool named the Database Resource
Manager. The Oracle Database Resource Manager enables the database administrator to prioritize
the allocation of CPU resources among various groups of users and applications on a per-session
basis. The Database Resource Manager can specify CPU resource percentages, execution limits,
degree of parallelism, active session pool, and size of the undo pool for specific users and
applications. Hierarchies are supported as well.
Some of the Database Resource Manager allocation algorithms could operate inconsistently with the
manner in which PRM allocates resources if the Oracle database instance processes are assigned to
an FSS PRM group. When the system is at peak load, that FSS PRM group is guaranteed a
percentage of the CPU resources. However, if the Database Resource Manager is running, it assumes
that all the CPUs it detected at instance startup are still available. The Database Resource Manager is
not aware if the PRM FSS attempts to restrict it to a user-specified fraction of the CPU resources. For
example, even though PRM allocates 50% of the CPU cycles to an Oracle database instance on a
four-core system, the Database Resource Manager assumes it has access to all four cores, or 100% of
the CPU cycles, and will allocate CPU resources to users and applications based on that assumption.
It is not aware that PRM is allowing it to use only 50% of the CPU cycles. Because of this, the
Database Resource Manager can produce unexpected results in terms of resource allocation and user
access priorities. For this reason, the use of the Database Resource Manager is not recommended for
Oracle instances that are assigned to FSS PRM groups.
However, when the Oracle database instance is placed in a pSet PRM group, there is no
inconsistency. The Database Resource Manager determines how many cores are available to it at
instance startup and continues to monitor this value so it can dynamically adjust its internal algorithms
as cores are added and removed from its operating environment (that is, the pSet).
Memory resource groups
MRGs enable you to logically partition private (that is, user) memory and shared memory.
(Management of shared memory is available starting with PRM C.03.01 on HP-UX 11i v2 Update 2
and later.) MRGs do not, however, support the partitioning of user memory resource types such as
shared text or shared library code.
Managing private memory
You can associate memory resource entitlements with both FSS and pSet PRM groups. This entitlement
represents a guaranteed minimum amount of private real memory that the processes within a PRM
group are allowed to consume at times of memory contention. The total memory demands from the
applications running on a system can fluctuate and vary significantly as time progresses. When there
is no memory contention, PRM groups can freely borrow memory from other PRM groups as needed
and exceed their memory entitlements to satisfy their needs at the moment. However, the borrowed
memory must be returned when the system next experiences memory contention.
With the introduction of MRGs on HP-UX 11i, PRM C.02.00 and later offer memory isolation.
Memory isolation can be applied on a per-group basis to prevent the free flow of memory resources
among PRM groups when the system is not experiencing memory contention. Memory cannot be
loaned out to or borrowed from other PRM groups. Memory isolation is useful for applications such as
Oracle that need dedicated memory resources and for applications that tune their own memory needs
based on their allocated resources.