All Your Eggs in One Basket – Thoughts on Pluggable Databases

Posted in: Technical Track

I hope that by now you’ve all heard about the fun that are pluggable databases. Oracle 12c will allow you to have multiple databases within the same instance. The databases will be completely isolated, so users in one DB will not see anything about the other databases on same instance, and each can have its own configuration and parameters. But SGA will be shared, so you don’t have to manually allocate memory to each DB, and in general, the management of these consolidated databases is greatly simplified.

This awesome feature will work great for consolidation, and I’m very excited about this possibility. I wish it were ready for production yesterday, but we’ll have to wait a while before we can deploy it, and the cautious DBA will wait for 12.2.

In his general session today, Andy Mendelsohn mentioned that the pluggable database framework is also useful for multi-tenant SaaS providers.

I spent large parts of my career working with the SaaS operations team, so the idea was intriguing. Given 12c and pluggable databases, how would I build the architecture for my former SaaS database?

Our SaaS system hosted thousands of customers. When we first started out, we were on SQL Server. SQL Server has had something similar (but not quite identical) to pluggable databases for many years now. But at 30-50 databases per machine, we ran out of resources, so we added more and more servers. When we reached 10 servers, the application servers, which had to communicate with all databases and all servers, completely saturated our network.

At this point, we decided to consolidate. We went with 3-node Oracle RAC cluster and migrated all the customers to the same schema, adding customer_id column to all tables and re-writing large parts of the app in the process. Yeah, consolidation/migration is painful. This migration took 2 years.

Consolidation had a serious drawback: What do we do when a single customer grows so fast that it overwhelms the cluster? We could add more and more nodes, but we were worried about the scalability in terms of table sizes. What we really wanted was to be able to split groups of customers to additional clusters and maybe even have clusters by customer size, importance, and SLA. Of course, with all our customers in one schema, splitting groups off was a huge challenge.

Pluggable databases seem like a good solution. I would figure out how many pluggable databases make sense per cluster. My guess is about 50 for Exadata half-rack, but who knows. I’d split the customers I have now into 50 groups and try to group them by SLA. Then I could move a small group of customers between clusters according to size, resources, SLA requirements, etc. Since DR is still at container database level, I would want to group them at least by DR requirements, so I’d have a replicated cluster for customers who would pay for it and non-replicated for the rest. Other features like transparent encryption could be managed at PDB level.

This would also allow choosing between two different strategies:
1- Split the pluggable databases between multiple clusters to make sure we never have system-wide outage.
2- Or, put all our eggs in one basket, and then watch the basket very closely by using the best possible high-availability solutions. Possibly Golden-Gate for zero-downtime maintenance and DataGuard for hassle-free, sure-to-work, DR.

It is not often that Oracle makes a major architecture change that opens new possibilities. As a consultant, I find it certainly exciting. I can now imagine new and better-than-ever solutions for my customers.



Want to talk with an expert? Schedule a call with our team to get the conversation started.

14 Comments. Leave new

Dominic Delmolino
October 1, 2012 7:53 pm

It will be interesting to see how easy it is to migrate a pluggable database from one container db to another — we used to do that with MySQL / SQL Server databases at the hosting company I worked at.

Marc Fielding
October 1, 2012 8:35 pm

Hey Dominic,

The whole idea behind pluggable databases is to make it easy to move them between container DBs. Think transportable tablespaces, but without the pain of cross-tablespace dependencies.



But the $64k question is, Option or Feature?


No official news on this yet. Since it is of value mostly for large customers, I’m betting on Option.

Raj Jamadagni
October 2, 2012 6:46 am

Why does this pluggable db concept remind me of the way Ingres worked? You had one instance of binaries running with common memory and you could start and stop individual ‘databases’. Of course my memory is of v4 through 6.


Yes, this feature is new to Oracle. Other databases had this for a while now.

Pavan Kumar N
October 2, 2012 9:50 pm


Nice to see new features of 12c, perhaps I trying to view what would be drawbacks (or) when compared to Oracle 11g. Specially the RMAN (Backup and recovery) I think about that perspective. 12c Container DB concept is primarily shooting at Cloud Customers, perhaps I think from non-Cloud customers perspective. Resource management concept got extended in order to management things. From Optimizer and number of process(new) would be extended since PDB are difference under one roof CDB.


Wondering how pluggable databases will work with dataguard. I’m guessing that all PDB’s in the instance must be setup on physical standby. Does that mean you cannot fail-over a single PDB? That would certainly change the way we utilize our standby.


Absolutely. Either all PDBs are replicated, or none are. At least in this version.


cheers fro your thoughts Gwen …
although there are big pros for this approach, i still can’t get my head around how the tunning will be done, what will happen with the object IDs when u bring in onde PDB from a different CDB?

Will still be unique :)



Tuning will be more complex than a single instance on a server, but easier than multiple instances on same server.

I hope there will be an option to generate AWR report for the entire complex, so we can get a big picture of who is using what resources.

ObjectIDs will not be an issue… imagine an extra column for each datadictionary table that will make objects unique regardless of where they came from. DBA_Objects will simply have 2 column primary key, but one of the keys will be hidden since you are inside a single PDB. (At least thats the concept, I don’t know the actual implementation)


While exploring 12c multitenant option, Got few question. Can you please clarify ?

1) Since SGA will be shared (set at CDB level), Any performance issue noticable by PDBs (multiple PDBs) ?. I have not seen clear reply on this on my google search.

2) Is resource manager enabled default at CDB level and Is it mandatory ?
I think SGA cannot be manually set at PDB level and cannot be controlled by resource manager ? How to overcome SGA memory issues if any ?

3) How do we calculate SGA/PGA while setting CDB initially ?
While onboarding new PDB databases, to change SGA to accommodate additional database memory , this requires bounce at CDB level. so will incur downtime, correct ?


Joseph Amalraj
July 11, 2014 6:56 pm

Having multiple instances on the same server can be better than having pluggable databases.


Leave a Reply

Your email address will not be published. Required fields are marked *