By OracleMultitenant on Aug 15, 2013
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!
- (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)
I tweet @OraclePDB #OracleMultitenant