Oracle Database 19c (release 19.4 and later) now includes the ability to dynamically scale compute for Pluggable Databases up and down in response to workload demands using CPU min/max ranges. Scale-up and scale-down of compute resources available to a Pluggable Database can be configured to happen automatically, instantly, and dynamically without intervention.
CPU Allocation Approach
The most common approach to managing CPU resources is to NOT over-provision and simply allocate CPU according to what’s available. While this certainly is quite simple to implement, it will always result in under-utilization of system resources. All databases will spend some amount of time operating at LESS than the maximum allocated CPU (vCPU), so this approach results in lower utilization and therefore higher cost to the organization.
Whether CPU is allocated to Virtual Machines that each contain a single database, or CPU is allocated to individual databases residing on a single Virtual Machine, the result is the same. Each database is given an amount of excess CPU headroom, and CPU usage below that threshold will fluctuate. The result is excess un-used CPU capacity and higher costs as shown in the following graphic.
CPU Over-Provisioning
As noted earlier, one commonly used approach to capturing the un-used CPU resources is to simply over-provision the system. Each database can be given access to more CPU resources, such that the total amount allocated exceeds the amount of CPU on the system. Whether this is done at the system (Virtual Machine) level or by over-provisioning across and within databases, the result is the same. Over-provisioning is what causes the “Noisy Neighbor” problem and can result in unstable or unresponsive systems.
Shares & Limits
Oracle offers the ability to configure “shares” for each Pluggable Database within a Container Database. Each instance of a Container Database is given an amount of vCPU to use by enabling DBRM and setting CPU_COUNT. The Pluggable Databases within that Container Database are then given “shares” of the vCPU available to the Container Database. Each Pluggable Database then receives the designated share of CPU resources, and the system is not over-subscribed.
Each Pluggable Database can also be assigned a limit of CPU resources it can use, which serves to prevent wide swings in database performance. Without a limit imposed on a Pluggable Database, each database is able to use the ENTIRE amount of un-used CPU on the system, which can appear to users as a large variation in performance.
Oracle Database 19c (release 19.4 and later) now includes the ability to dynamically scale compute for Pluggable Databases up and down in response to workload demands using CPU min/max ranges. Scale-up and scale-down of compute resources available to a Pluggable Database can be configured to happen automatically, instantly, and dynamically without intervention.
CPU Allocation Approach
The most common approach to managing CPU resources is to NOT over-provision and simply allocate CPU according to what’s available. While this certainly is quite simple to implement, it will always result in under-utilization of system resources. All databases will spend some amount of time operating at LESS than the maximum allocated CPU (vCPU), so this approach results in lower utilization and therefore higher cost to the organization.
Whether CPU is allocated to Virtual Machines that each contain a single database, or CPU is allocated to individual databases residing on a single Virtual Machine, the result is the same. Each database is given an amount of excess CPU headroom, and CPU usage below that threshold will fluctuate. The result is excess un-used CPU capacity and higher costs as shown in the following graphic. CPU Over-Provisioning
As noted earlier, one commonly used approach to capturing the un-used CPU resources is to simply over-provision the system. Each database can be given access to more CPU resources, such that the total amount allocated exceeds the amount of CPU on the system. Whether this is done at the system (Virtual Machine) level or by over-provisioning across and within databases, the result is the same. Over-provisioning is what causes the “Noisy Neighbor” problem and can result in unstable or unresponsive systems.
Shares & Limits
Oracle offers the ability to configure “shares” for each Pluggable Database within a Container Database. Each instance of a Container Database is given an amount of vCPU to use by enabling DBRM and setting CPU_COUNT. The Pluggable Databases within that Container Database are then given “shares” of the vCPU available to the Container Database. Each Pluggable Database then receives the designated share of CPU resources, and the system is not over-subscribed.
Each Pluggable Database can also be assigned a limit of CPU resources it can use, which serves to prevent wide swings in database performance. Without a limit imposed on a Pluggable Database, each database is able to use the ENTIRE amount of un-used CPU on the system, which can appear to users as a large variation in performance.