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

Instance Caging
Instance caging has been introduced with Oracle 11g Release 2. It addresses a scenario where multiple databases run
on the same physical hardware, and might starve each other out of CPU resources. After you have seen that Database
Resource Manager is great to work within the same database (CDB or non-CDB), it does not allow you to manage
inter-database resources. Instance Caging to the rescue: in a nutshell, instance caging allows administrators to limit
the number of CPUs available to the database instance by setting the initialization parameter cpu_count . In addition,
a resource manager plan needs to be active for this feature to work in cases where resource usage is further defined.
As you saw in the previous section using a resource plan is very useful anyway, and not at all a high price to pay for the
instance caging feature.
To enable instance caging first ensure there is an active resource plan. You could for example query the
V$RSRC_PLAN view to find out which resource plan is in use, or alternatively by checking the V$PARAMETER view.
When you have made sure that there is a resource manager plan in place, all you need to do is to set the cpu_count
parameter. This parameter is dynamic and can easily be changed while the database is up and running. Since
cpu_count is the basis for many other derived parameters one should make adjustments carefully. It is best not to
change the parameter too drastically. You can either over- or undersubscribe your database server. Oversubscribing
in this context means that the sum of all database instances' cpu_count exceeds the value of available CPUs as seen by
the operating system. Alternatively you could divide the number of available CPUs and allocate them to the individual
databases.
Summary
Pluggable Databases are certainly the most exciting feature of Oracle 12.1. Designers of consolidation platforms have
ample use cases to directly embrace the new technology. The ability to create a new namespace in the form of the
Pluggable Database allows you to maintain multiple users with the same name in the same Container Database. The
same applies for roles of course, and the user concept allows you to have common users with fine-grained access
privileges, without having to be granted a “create session” privilege. This should allow for a smooth migration of most
enterprise monitoring software.
The many ways to create Pluggable Databases give the architects and designers a lot of flexibility with how they
want to provision the golden copy of the Pluggable Database. It can either be NFS exported, ready for cloning. The
source file name conversion clause makes it possible.
Another advantage that should not go unmentioned (again) is the fact that the unplug/plug operation can allow
the DBAs to upgrade databases very quickly. And even if the databases stay in place, you only patch one database for
hundreds potentially. Now that the foundation for the Pluggable Databases has been laid there is more to come. The
following chapters will deal with protecting your database from disaster using Data Guard. But the local database has
to be protected as well. Even though not really popular, database backups have to be performed regularly. And not
only that, you should also regularly restore a random backup to ensure the backups are not corrupted, and can be
restored in the worst case. Finally, there will be a chapter dealing with the migration to Oracle 12.1.