Database Reference
In-Depth Information
Another grant is executed in PDB “DB2”, this time the DBA role is granted to the C##GUSER account. Note that
even though C##GUSER is a common user, it currently cannot connect to any other PDB than PDB1 and PDB2.
Neither can it connect to CDB$ROOT. Connecting as C##GUSER to PDB1 you can see that the user really only has the
connect role granted by checking the session_privs view:
select count(1) from session_privs;
COUNT(1)
----------
1
Likewise, the granted privileges in the PDB2 database match the DBA role, and the view session_privs returns
221 rows.
Local roles
Local roles are best compared to roles in Oracle before 12.1. In fact, they behave exactly as before. This is mainly
thanks to the promise Oracle made of backward compatibility. Local roles have a defined namespace within the PDB
they are created in. Similar to the local user, multiple roles with the same names can exist in different PDBs.
Playing nicely with others
One of the major concerns of staff responsible for managing production databases are rogue, or “runaway” queries or
databases which can have a severely negative impact on the other users on the same hardware. Oracle addresses the
“runaway” session and database over the many database releases now, and 12.1 is no exception to the rule.
There are a number of weapons in the DBA's arsenal to prevent resource starvation. Some are based on the
operating system, and others are based on the Oracle kernel. Some operating systems, as well as some virtualization
solutions allow you to create lightweight operating system images on to which a database home is installed. Most
often you would set resource limits on the virtualized server in the form of memory and CPU. Ideally, this technology
integrates with the base operating system to allow for better NUMA-awareness. What Oracle kept telling us users over
time was that Operating System scheduling has the downside that it's difficult to quantify, for example by looking
at Automatic Workload Repository (AWR) reports. Is the high CPU usage now down to the Oracle instance being
extremely busy, or is it down to a resource capping operating system? Like Jonathan Lewis famously said about “know
your data,” the same principle applies in this situation: know your environment.
The use of Oracle provided technology allows us to benefit from the instrumentation of the kernel in form of the
wait interface. Before Oracle 12c it has been possible to use the Database Resource Manager (or DBRM) to manage
resource consumption within the same database. The Exadata-only I/O Resource Manager furthermore allows the
administrator to regulate I/O bandwidth between databases. Instance Caging allows you to limit the CPU usage of a
specific database instance. Let's have a look at these features in the next sections.
I/O resource Manager will not be covered in this chapter, for more information about the IOrM please refer to
Expert Oracle Exadata , also from apress.
Note
 
 
Search WWH ::




Custom Search