OCP Upgrade to Oracle Database 12c Management

Examining the Management of Local and Common Users
In the last module, I reviewed the creation of container databases and the pluggable databases. The next topic will be the creation of the users. With a multitenant architecture comes the introduction of new types of users, the common user and the local user. This section will review the attributes of the common and local users, creating the users and the assigning of common and local privileges, as well as the common and local roles. The common users belong to the root container data dictionary and are known to all the pluggable databases that belong to the CDB. Once created, these common users are known to all current containers and will be known to any future containers in the CDB. There are also local users that are defined in a specific PDB and can only connect to that PDB. These are very rudimentary definitions, and you probably have similar questions as our Globomantics DBA, Mark. He wonders is there any difference in how a user will log into a PDB than how they currently log in to a non-container database. Is there a benefit of defining administrators as a common user compared to having them defined on each local database? If you have a common administrator or a user, can their access be limited to a subset of pluggable databases within the container database? What tasks can a common administrator perform that a local administrator cannot perform? And how does a common user know which system their work is going to affect? By the end of this module, you'll have a basic understanding of the answers to these questions.

Managing CDBs and PDBs
In the last module, I presented new attributes and areas of consideration for the creation of users, roles, and limiting their privileges on the system. In this module, I'm going to highlight the management of container databases and pluggable databases. One of the areas that Oracle claims as an advantage of the multitenant architecture is the ability to have separation of duties for database administration. You can have a container database administrator and a pluggable database administrator. The container database administrators will usually have areas of responsibility concerning the entire instance, such as performance, administration of common users, and the administration of common objects where pluggable database administrators are more focused on the management of the data, the users, the application objects. This module I'll dive a little bit deeper into the administration of the databases within the multitenant architecture. The goal of this module is to show how the operational procedures can be affected when switching to a multitenant architecture and using pluggable databases. I've touched on some of these topics already in previous modules. I'll do a little bit further investigation into areas such as connecting to a container, how you connect to root versus how you connect to a pluggable database. We'll also discuss in more detail the current container and what it means. We'll talk about switching containers and how to perform an administrative tasks on a container database and a pluggable database.

Managing Tablespaces in the Multitenant Architecture
This module will relate the basic management of tablespaces in the multitenant architecture to the tablespace management in a non-container database environment. I'll investigate some of the tablespace topics that are specific to the container database instance and pluggable databases. In the multitenant architecture, it's often stated that pluggable databases share the same resources such as memory and system processes of the container database instance. This seems to be a good aspect of the system, but what about tablespace management in the container database? Is everything truly separated, or are there shared tablespaces that might cause issues for the entire database if they're not managed appropriately? Mark, our Globomantics DBA, has divided his research into four areas. He wants to know if changes have been made to the views he uses to monitor tablespaces and if there are any views that he should be using. He wants to know if there is any sharing of tablespaces between pluggable databases. He wants to see if there are any specific approaches to tablespace management for the container database and the pluggable databases. Finally, he wants to know if a container database administrator can limit the storage resources utilized by a pluggable database.

Identifying the Benefits of a Multitenant Container Database
This module gives an overview of the Benefits of a Multitenant Container Database. Oracle promotes the multitenant architecture of the container database as achieving the goals of higher utilization of resources and simplified management of databases. I'm going to review some of the research our friendly Globomantics senior DBA, Mark, has found in regards to the benefits that Oracle proclaims. Mark has finished his initial research into the container database in the multitenant architecture, and it does hold promise for many of the development and non-enterprise business systems. He has built a good foundational knowledge of the capabilities such as the compatibility guarantee, cost reduction, easier monitoring and management of systems, easier performance tuning, and separation of duties and separation of applications. Let us take a little closer look at these areas and review what Mark has found.