It is fairly common for a specific application to request that its database objects (users, tables, indexes, and so on) be placed in a database isolated from other applications. Reasons cited for doing this are often security issues or performance concerns.
Before the advent of PDBs, think about how you solved the requirement of separate environments for various applications and development teams. Two common solutions employed are as follows:
• Create a separate database for each team/application that needs an environment. Sometimes this approach is implemented with one database per server, which often translates into additional hardware and licensing costs.
• Create separate environments within one database. Usually, this is achieved through separate schemas and distinct tablespaces. This approach requires that there not be any database object naming collisions between applications, for example, with objects such as usernames, tablespace names, and public synonyms.
PDBs provide the security isolation requirement; there is no direct access from one PDB to another. Even a user connected with SYSDBA privileges to a given PDB has no direct SQL access to other PDBs within the CDB. From a security and application perspective, you have totally isolated PDBs within the larger CDB.
As a DBA, instead of having to implement and maintain dozens of individual databases and associated operational tasks (such as provisioning new databases, installs, upgrades, tuning, availability, monitoring, replication, disaster recovery, and backup and recovery), you can manage any number of PDBs as if they were one database from the root container perspective.
Another significant advantage of the pluggable architecture is that a PDB can easily be cloned or transferred from one CDB to another.
This allows for more options when performing tasks such as provisioning new databases, upgrading databases, load balancing, or moving application data from one environment to another (such as from a development database to a test database).
Creating a new environment can be done by cloning another PDB. And, moving a PDB from a CDB simply requires that you unplug (via SQL commands) the PDB from the CDB and then associate the metadata and data files (plug in) with a new CDB.
Moving PDBs also provides additional options for upgrading databases, by creating a new CDB or upgrading an existing one.
The upgrade then is performed on the PDBs as they are attached or open. There are fewer databases to patch and upgrade, and you can upgrade one CDB instead of 100 databases.
Because of the consolidation, there is cost reduction along with maintaining the environment.
There is hardware consolidation and efficient use of the hardware instead of extra or unused resources by placing several database instances on different servers.
Performance tuning is captured in a consolidated area, and the SGA is available for all of the PDBs, which is easier to size and tune one instead of all of the individual databases.
Leveraging load balancing and resource management will allow for meeting SLAs and makes it easier to do migrations and upgrades.
