Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 261

Overview of Resource Manager in Oracle 12.1
Before launching into the description of the changes to Resource Manager in 12c, a little bit of background knowledge
is necessary. On many site visits I noticed that Resource Manager was not implemented besides the standard
deployment by Oracle. This does not do the technology justice, but on the other hand the problem is exactly the way
I saw it on site: the business users have to analyze their application and define the usage of Resource Manager in
their database. On many occasions “the business” however feels uncomfortable making this decision. Hopefully the
following paragraphs allow them to make a more informed decision, based on the facts.
What exactly is that Database Resource Manager (DBRM) then? In the simplest form a definition could be
as follows: the Database Resource Manager allows the administrator to use a variety of criteria to logically group
users or workloads into a resource consumer group. A resource consumer group defines how many resources in a
database can be assigned to users in the form of a resource plan directive. Since Oracle 10, users can be moved into
a lower resource consumer group when they cross the threshold for their allowed resource usage. Beginning with
Oracle 11, they can also be moved back to the initial consumer group once their downgraded calls are completed.
This is especially useful in conjunction with connection pooling and web applications where one session can no
longer be directly associated with an individual, as it was in the days of dedicated server connections and Oracle
Forms applications. In the connection pooling scenario, the application simply grabs a connection out of the pool
of available connections, performs its assigned task, and then returns the connection to the pool. Often these
operations are very short in nature. Connection pooling offers a huge advantage over the traditional way of creating
a dedicated connection each time a user performs an operation against the database, greatly reducing the overhead
associated with establishing a dedicated server process. Before the Resource Manager can become active, it is
important to define a mapping between a database user and the corresponding resource consumer group. Once that
is established—most often based on the service name the user uses to connect—the resource plan can be created and
activated. What you just read was the state-of-play before Oracle 12 and the same principles apply for a 12c non-CDB
as well.
Thankfully Oracle extended DBRM to take Pluggable Databases into account. The new DBRM in Oracle 12.1
operates on two different levels, in a Container Database:

• On the CDB level

• On an individual user-PDB level

This allows the administrator to define the potential share of workload available to each PDB first before breaking
the CPU quantum down to the individual PDB, where the inter-PDB Resource Manager will work its magic.

Resource Manager for the Container Database
The new extension to the Database Resource Manager in Oracle 12.1 allows the administrator to rank the importance
of PDBs within a CDB. The new DBRM makes allowance for the fact that some PDBs are more important than others,
or simply to ensure that no individual PDB can starve others for performance. DBRM is essential when it comes to
enforcing service levels and predictable performance in the consolidated environment. Depending on the service
purchased by the database user you could assign it into the Gold/Silver/Bronze class. Resource Manager is slightly
different in a CDB compared with a non CDB. DBRM decisions are made on two levels: first on the CDB level, then on
the individual PDB level. You will see a little later in the chapter that the syntax reflects this.
Instead of a Resource Plan you create a CDB plan in DBRM for the multi-tenant database. The CDB plan
directives of concern for managing the resource consumption between PDBs are

• Shares

• Utilization limits

• Parallel Execution (PX)