All Your Eggs in One Basket – Thoughts on Pluggable Databases

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.