I/O Resource Management and Instance Caging - Oracle Exadata Recipes: A Problem-Solution Approach - page 516

17-9. Limiting CPU Resources with Instance Caging
Problem
You wish to limit the number of processors that an Oracle instance can use on the compute nodes.

Solution
In this recipe, you will learn how to use the cpu_count database initialization parameter to restrict the number of
CPUs a database instance can use.

After selecting an instance to limit CPU resources for, log in to SQL*Plus as SYSDBA and
execute the following command. In this example, we will restrict the number of processors
on each database in the cluster to four and update the parameter in memory as well as the
server parameter file.

1.

SQL> alter system set cpu_count=4 scope=both sid='*';
System altered.
SQL>

2. Next, ensure that you have a resource manager plan enabled in your database. If you

are using Intradatabase IORM as presented in Recipes 17-4 and 17-5, this will suffice to
complete your instance caging setup. If you do not have specific Intradatabase (DBRM)
plans designed, you can simply enable the default plan using the following command:

SQL> alter system set resource_manager_plan='default_plan'
2 scope=both sid='*';
System altered.
SQL>

How It Works
Adjusting cpu_count is a means to limit compute node processor availability on per-instance basis and, when used in
combination with a DBRM plan, is also referred to as “instance caging.”
By default, Oracle will set cpu_count to the number of CPU cores times the number of threads per core in a
threaded architecture; on Exadata X2-2 models, this equates to 24 per compute node and on the X3 configurations, 32.
Historically, the Oracle DBA would typically not configure the cpu_count initialization parameter to anything
other than the default value, as it would impact a number of other performance-related configuration parameters
and would not restrict compute node CPU resources for an instance. With Oracle 11gR2, which is the database
version used for Exadata, setting cpu_count in combination with a DBRM plan places a hard ceiling on the number of
processor threads a single instance can use.
Why would you implement instance caging? When consolidating databases on Exadata, it is common for a
combination of production, non-production, critical, and less critical instances to be deployed across your compute
nodes. Instance caging enables you to protect your processor investment by restricting processor threads from less
critical databases, and it is commonly used in conjunction with I/O Resource Management.