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.