12c PDBs & Delphix: like chocolate & Peanut Butter

November 7th, 2013



Oracle 12c introduces the new Pluggable Database (PDB) functionality into the Oracle database. What’s the advantage of PDBs? PDBs eliminate the heavy memory overhead of starting up a full Oracle instance requiring a new SGA and full set of background processes. Instead,  we startup one container database (CDB) and then PDBs all share resources of the CDB. With a CDB & PDBs, there is one instance, one set of background processes, one SGA and these are shared among the PDBs. Starting a PDB only requires about 100MB  of memory as opposed to half a GB normally required to start an Oracle instance. Because of this reduced memory cost one can go from running 50  instances of Oracle on 20GB of memory to running 250 PDBs  in that same 20GB of memory. (numbers given by Oracle benchmarks)


One of the main use cases for PDBs is cloning a database for use in development and QA. With PDBs, one can easily give every developer in a development team their own copy of  a database, except for one thing. Each of those PDBs, even though they take up hardly any memory, still require a full set of datafiles. Creation of these datafiles is slow and costly. That’s where Delphix comes in.


With Delphix, having 10 copies of the same database takes up less than the size of the original database! How is that done? It’s done by compressing the original copy and then sharing all the duplicate blocks in that copy among all the clones.


Thus where PDBs give you database for free at the memory level,  Delphix gives you free databases at the disk footprint level and the combination of the two gives you practically free databases!




Oracle marketing slide showing 50 separate databases can run in 20 GB of RAM and 250 PDBs can run in 20 GB of RAM. “5x more scalable”




Screen Shot 2014-04-25 at 8.42.32 AM

Video example of how easy it is with Delphix to link to a PDB in one CDB and the provision it, thin clone, to another CDB on a different machine:

cloning, PDB

  1. Trackbacks

  2. No trackbacks yet.

  2. Ludovico
    | #1

    Hi Kyle,

    I’ve read your post, I think Delphix is a really interesting technology and for sure it can boost savings at disks level, but the savings Oracle claims at memory level leave me a little skeptic…
    Real memory requirements of Oracle are FAR from being the minimum required to start an instance.
    The assumption of Oracle is:

    20GB HOST / 500MB SGA = 40 non-CDB Instances
    ( 20GB HOST – 500MB CDB ) / 100MB PDB = ~ 200 PDBs

    Actually, an “average real” database may need, let’s say, only 8GB of SGA? saving few hundreds of MB per PDB doesn’t save you from needing still 7/7.5GB for the application load…

    So let’s make a more realistic hypothesis with a decent amount of RAM:

    196GB HOST / 8192MB SGA = 24 non-CDB Instances
    ( 196GB HOST – 500MB CDB ) / 7168MB PDB = 27 PDBs

    Am I missing something? What’s your opinion?

    PS, Sorry for that, I prefer to send to you a direct message rather than a comment on the post that can raise some doubts about PDB & Delphix consolidation… :-)



  3. khailey
    | #2

    Hi Ludovico,

    I completely agree.
    20GB / 250 PDBs = 80 MB per VDB which is hardly enough to run a database even if all of that could be given to a buffer cache and that’s not even including the shadow processes which are pretty memory hungry.
    It’s one reason I also wrote this blog post
    where we can leverage the shared cache on Delphix as like a super Oracle buffer cache mitigating the need for much buffer cache in the PDB.

    Personally, I don’t see the big advantage of PDBs especially when they license is $17.5K per core.

    On the other hand, the SGA demands of virtual databases does limit how many VDBs I can put on a machine. With PDBs the number I can put on one machine will increase substantially which is cool but I’m not sure if it’s worth the license cost. It’s a calculation that one will have to evaluate for their situation, but if I had Delphix then PDBs would certainly make my life easier as I could spin up significantly more clones on the same hardware.

    Another thing to keep in mind is that CDB + PDB should significantly ease upgrade complexity as one just has to upgrade the CDB.

    Waiting to hear more about peoples experiences on the ground with PDBs.


  4. Dird
    | #3

    I don’t rate PDBs as a feature. You’re only going to be doing it for databases that aren’t very busy and they’re ones where you could probably just impdp a schema & they would give you a day’s downtime to sort any object name clashes that may occur.

    You’re not going to move 2 busy systems together because
    1) They’re probably busy at the same time
    2) Your CDB has memory_max_target of 70gb but those two DBs (being high load) are used to 40gb…this param is still static in 12c
    3) one single LGWR

    SQL Server has had the same option (“attachable”/detachable databases) for years.

    You were talking about licensing…do they make you pay at the instance level or per PDB?

− six = 3