Fact: A CDB can contain up to 252 PDBs. 

Trick question: If I have 200 PDBs, how many CDBs do I need? 











Easy, right? One CDB! 
Wrong! (At least, probably!) 

With Multitenant, we can plug many PDBs into a single CDB, sharing overheads of background processes and SGA. This can increase hardware utilization – dramatically in some cases – and so reduce capital expenses by supporting more applications per server. Great! But wait, there’s more! We also reduce operating expenses by managing many as one. But that doesn’t mean that you should only have one CDB. In fact, we think you’re likely to want several. Let me explain. 

I’ve talked to a lot of customers in the last few weeks about their consolidation plans – specifically using Multitenant, of course. For a few there has been a hesitation… “We don’t want to consolidate all these applications because we don’t want our air traffic control app running alongside our eBusiness Suite and certainly not alongside all those smaller departmental apps!”

“Well,” I tell them, “that’s ok. I probably wouldn’t want to do that either – at least that’s not where I’d start my consolidation project!”

I’ve also heard a complaint that “this ‘manage many as one’ business is too inflexible. Why can’t I configure NOARCHIVELOG mode at a PDB level?”

Those apparently unrelated concerns end up with the same answer: It’s ok to have more than one CDB!

A prominent reason to have more than one CDB is to support different Service Level Agreements (SLAs). SLAs typically include specifications of availability and recoverability; things which tend to correspond to Oracle options such as Real Application Clusters (RAC), Active Data Guard (ADG) or perhaps settings like ARCHIVELOG mode (my customer’s question above). Remember that with Multitenant these things are defined at the CDB level and all PDBs plugged into the CDB inherit these characteristics. This is the “manage many as one” message.

So you’d typically have at least one CDB per SLA. Perhaps you’d have a CDB configured for your “Bronze” SLA with weekly full RMAN backups. For your “Silver” SLA you might have a CDB with Active Data Guard and daily incremental backups. (Of course there’d be a corresponding CDB on the standby side.) For the “Gold” SLA maybe you’d have all that and Real Application Clusters (RAC) as well for even higher availability and scalability. Of course you could configure additional CDBs to support any number of SLAs but in general you’d want to standardize on a few. 

With Multitenant, don’t think in terms of configuring these things at the application database level. Instead think in terms of the SLA requirements of the application and plug the application’s PDB into the appropriate CDB to achieve the required SLA. It’s so much easier because there are far fewer moving parts. Of course you can easily unplug/plug to move the PDB to a different CDB if the SLA requirements change!

Besides supporting various SLAs, here are some other reasons you’d want to create additional CDBs.
  • (Active) Data Guard – one primary CDB and one standby CDB
  • One for each combination of incompatible system parameters (Oracle version, character set, endianness…)
  • One spare for each CDB above, for patching/upgrading via unplug/plug
  • One for low throughput (but still business-critical) applications; one (in single-tenant configuration) for each mission critical one (and maybe one for a few medium-scale apps)
So you could easily end up with one or two dozen CDBs – and you’d be doing it right. Of course you’d still be getting the benefit of Multitenant because companies with a legitimate need for this many CDBs are used to managing hundreds of databases… some of our customers have thousands of them! With Multitenant, by using this approach, this nightmare is replaced by the relatively simple requirement to manage a few groups. 

I really like the message “manage many as one” but perhaps I should be looking for a new slogan… Entries on a postcard, please.

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler