In this presentation I plan briefly to review the old architecture of Oracle Database.
I’ll discuss the new multitenant architecture along with the capabilities it enables.
We’ll talk about management of shared resources and how to upgrade to Multitenant.
Oracle Database 11g Architecture is non-CDB.
Oracle Instance : SGA & PGA + Background Processes
Oracle Database: Control Files, Data Files, Redo logs (Online and Archived), Parameter and Password files.
Memory and Background Processes – Oracle Instance
Storage - Database Files
Let's think about our traditional Oracle Database architecture.
Every time we create a database, be it a production database, a development or a test database, what do we do?
We create a set of files, we allocate a bunch of memory for managing the data, and we kick off a series of background processes.
And this is replicated for every one of the databases that we create.
As more and more databases are fired up, these replicated overheads quickly
consume the available server resources and this limits the number of applications we can run on any given server.
You can see how quickly we red-line the little resource meter here.
With Oracle Database 12c, we have a new multitenant architecture, featuring pluggable databases.
We can now create a single multitenant container database.
Into this we can plug multiple pluggable databases.
Now, the beauty of this new architecture is we don't need to make changes to our existing applications.
More importantly, we now only allocate one chunk of memory and one set of background processes for that container database.
So that's going to give us much greater utilization out of our existing IT resources. We’ll be able to host many more applications per database server.
So it's going to give us much greater scalability as we consolidate multiple pluggable databases into our new multitenant container database.
Let’s discuss this architecture in more detail.
First we’ll review the basic elements of our new concept.
Then we’ll look into what we had to overcome to achieve this.
Finally we’ll address some of the details around files, users, etc.
Let’s look at the components of a multitenant container database
We have the pluggable databases or PDBs
There are two parts to the term pluggable databases;
There’s “pluggable”, which is new and “databases” which is familiar.
Before we get to the revolutionary new stuff let’s discuss what hasn’t changed.
A pluggable database is a fully functional self-contained Oracle database. It’s not watered down in any way.
From the perspective of an application or an end user it hasn’t changed at all.
This is very important because it means that no application changes are required to adopt this new architecture.
[click]
We introduce a new concept: a root database
[click]
Into which are plugged various PDBs
[click]
And the combination is referred to as a multitenant container database or CDB
Read slide.
…for example, for a user connected to the CRM PDB to access data in the HCM PDB, he would have to do so using a database link, just as was the case with prior versions of the database.
Now what if we wanted to move a PDB from one container
[click]
to another?
With Oracle Multitenant, we can simply
[click]
Unplug it from the first
[click]
And plug it into the second container.
Read slide.
Now, all of this is achieved via SQL.
Here, for example we see two SQL statements that would be used first to unplug a PDB
And then to plug in a PDB
Notice that the manifest of the unplugged PDB is specified as an xml file.
Now, what did we have to change to be able to achieve this vision?
Let’s discuss what happens to a traditional Oracle database over time.
Here we need to distinguish between two parts of the database – the data dictionary and the user data.
When the database is first created, the only tables present are the Oracle data dictionary tables.
The only data they contain is the Oracle-supplied meta data for the database, such as the definitions of the Oracle data dictionary tables themselves, their columns, etc.
[click]
Now, as the user schema is added to the database, the definitions of these user tables, columns, indexes, etc are also stored in the data dictionary.
[click]
So, over time in a mature database, the data dictionary contains Oracle-supplied meta data of the Oracle data dictionary intermingled with the definitions of the user’s application schema.
That’s been fine until now, but it’s an obstacle to our new goal of being able to unplug an application-database and move it from one container to another.
The multitenant container database behaves as a single database from the operations point of view.
We only have a single set of Oracle background processes and a single, shared database memory requirement for the entire CDB,
Shared across all PDBs plugged into it.
This gives us very high consolidation density; in other words more applications per server.
This affords maximum reduction in capital expenses.
Let’s have a close look at some of the key capabilities that are enabled by this new multitenant architecture.
By managing many as one, we maximize OpEx reduction.
Here we see a single backup strategy for the entire container database
… with the granularity of a PITR capability at the individual PDB level.
High Availability – standby database maintained by Active Data Guard.
Plug in a new PDB into the production CDB
[click]
And you have a corresponding PDB in the standby
Transactions in the new PDB are replicated to the standby automatically,
just by virtue of plugging that PDB into the CDB in this Active Data Guard environment.
Another example of managing many as one with Oracle Multitenant is upgrading or patching.
Patches and upgrades are applied at the multitenant container database level.
[click]
All PDBs in that CDB are automatically upgraded in one fell swoop.
But if you want the granularity of a per-PDB upgrade, it can be done by unplug/plug into a second CDB, upgraded to the required level.
So applications can be upgraded as and when they’re ready.
[click]
In this example, ERP never moves to 12.x.
So, along with the advantages of managing many as one,
we’re beginning to see examples of the agility afforded by the new multitenant architecture.
The same cloning approach can be used to copy existing application databases.
Again, where the underlying file system supports copy-on-write we can create snapshot clones – extremely fast.
[click]
PDBs can be cloned from within the same CDB
[click]
And PDBs can be cloned from remote CDBs.
NOTE: A bug prevents remote clone from being used in 12.1.0.1. We hope that the fix will be included in 12.1.0.2.
As before, cloning is performed by using SQL.
Here are the SQL statements to create a local clone…
And to clone a PDB in a remote container, we need to specify the database link.
We’ve seen that we can achieve great reductions in operating expenses by managing many as one.
We have carefully selected the operations that can be performed at the level of the overall multitenant container database.
Here are some prominent examples.
Read slide
But we retain granular control where appropriate.
[click]
The sort of operations we still want to perform at the level of the individual PDBs are
Read slide
Now that we’re able to consolidate multiple applications into a single database we need to think about how to share resources appropriately.
We don’t want any single application to run away with all the resources of the system at the expenses of everyone else.
Now that we’re able to consolidate multiple applications into a single database we need to think about how to share resources appropriately.
We don’t want any single application to run away with all the resources of the system at the expenses of everyone else.
This is a simplistic visualization of our high-level concept.
We have three PDBs with different processing priorities:
DW is low priority,
CRM is medium
& ERP is high priority.
[click]
When only DW is busy, why not let it use all the resources in the system.
As the demand of the higher priority CRM system picks up,
DW has to yield some of its processing resources.
And as the High priority ERP system kicks in, the other two have to back off significantly.
Let’s see how it works in more detail.
[This is an opportunity to describe how we can now support inter database Resource Management. The dials are simply showing that as higher priority workloads come on the lower priority ones release resources. We aren't being specific about the resource. It could be CPU or Parallel Query Servers. ]
Read slide
PDBs vie for shared resources
Using Resource Manager we can configure policies to control how these resources are shared.
We can control CPU, Parallel execution servers, Sessions and, in Exadata, I/O.
For example this would allow us to configure a policy so that the first tenant in a large, powerful server experiences a realistic share of the resources that will eventually be shared as other tenants are plugged in.
Here’s an example of how we’d specify resource plans for the allocation of CPU between three PDBs
There are four total shares, 2 for HCM and one each for CRM and ERP.
That means that HCM is guaranteed 50% of the CPU whatever else is going on in other PDBs.
Similarly CRM and ERP are each guaranteed at least 25%.
However, there are no caps in this case, so that, for example, ERP could have 100% of the CPU if HCM and CRM were idle.
Now you’ve seen how wonderful Oracle Multitenant is, you’ll be eager to upgrade all your applications.
How do you do it?
I told you this architecture was easy to adopt. Easy as 1-2-3.
Step 1. Upgrade your existing databases in-place to version 12.1,
[click]
just as you’ve done upgrades to prior versions.
Step 2. Plug in the upgraded databases into a pre-prepared multitenant container database.
We call this process “adopting the database as a PDB”.
…and of course, step 3 is to change your applications to work with Multitenant.
[click]
Oh yes, that’s right! There is no step 3! No application changes are required to work with Oracle Multitenant!
Another option is to upgrade using replication.
[click]
Simply provision a new, empty PDB.
[click]
Then, using Oracle Golden Gate or Data Pump, replicate the data from the source database to the new PDB.
[click]
This approach might be more appropriate for a database in a much older version of Oracle, where version-by-version upgrades would be too cumbersome.