All your Eggs in One Basket – Thoughts on Pluggable Databases
Oct 1, 2012 / By Gwen Shapira
I hope that by now you’ve all heard about the fun that is 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 management of those consolidated databases is greatly simplified.
Awesome feature. Will work great for consolidation and I’m very excited about this possibility. I wish it was 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
Andy Mendelsohn in his general session today mentioned that the pluggable database framework is also useful for multi-tenant SaaS providers.
I spent large parts of my career working at 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, as painful as consolidation/migration can be. This migration took 2 years, BTW.
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 of groups of customers to additional clusters. 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, try to group them by SLA. Now I can move a small group of customers between clusters according to size, resources, SLA requirements, etc. Since DR is still at container database level, I will want to group them at least by DR requirements, so I’ll have a replicated cluster for customers who will pay for it, and non-replicated for the rest. Other features like transparent encryption can be managed at PDB level.
This also allows choosing between two different strategies:
Split the pluggable databases between multiple clusters to make sure we never have system-wide outage.
Or put all our eggs in one basket, and then watch the basket very closely by using 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 it is certainly exciting, I can now imagine new and better-than-ever solutions for my customers.
12 comments on “All your Eggs in One Basket – Thoughts on Pluggable Databases”
Leave a Reply
You must be logged in to post a comment.
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.
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.
Marc
Check this link for your question:
http://www.dadbm.com/2013/02/oracle-12c-pluggable-database-plug-unplug-and-clone/
Kirill Loifman
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.
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.
Hi,
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 :)
Cheers,
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)