Posted on October 15, 2012 by Randy Hardee
Tags: Oracle, 12c
As we all know, the next major release of the Oracle Database has been in Beta testing since earlier this year, so lots of us were expecting some pre-release information about the “12c” version to be leaked at the 2012 Oracle OpenWorld event in October. Both Larry and Andy included some general statements about new features/functionalities in the Database 12c release, but not any “official” statements in detail.
So here's a brief summary from what we heard:
- The 'c' stands for Cloud (no big news here), and many of the 12c changes are focused on enabling and improving the Oracle DB in multi-tenancy and consolidation situations, i.e. running lots of Oracle Database in the same server or cluster. Not just 3-4 instances, but potentially dozens of databases sharing the same hardware platform and resources.
- The primary challenges in running lots of Oracle Databases together in the same address/resource space have always been 1) overhead and resources, especially memory, 2) management and isolation, and 3) version/upgrade control.
- Introducing the Oracle Database 12c Pluggable Database. There's lots of blogs that go into technical details about the Container DB and Pluggable DB (CDB and PDB), but basically Oracle has started separating the “database instance” from the “database” by dissecting the data dictionary and objects between the CDB and PDB. For example, the admin schemas and common objects like SYS and SYSTEM are part of the CDB and shared across the PDBs, as well as running resources like controlfiles, redo logs, SGA, and other processes. Namespace or Application definition data dictionary objects, schemas, and objects are mirrored and/or owned at PDB level. Look for more technical details in later blogs.
So what does that allow us to do? Well, let's make some assumptions based on what we know:
- Running multiple Oracle Databases in the same address space would require much less memory now since multiple databases can share memory and process resources. Instance overhead would shared across running PDBs.
- In multi-tenant apps, we can have the same schemas running under one CDB as separate PDBs i.e. Customer1 can be a replica of Customer 2,3,N without impacting data model or other implemenation tricks. This is huge for SaaS/Cloud and Managed Application solutions.
- Resources can be managed at the PDB level, i.e. between/within, up/down, plans, etc. Likewise, the PDB isolation allows for more flexibility and improvements in security, backup/recovery/DR, and other database requirements.
- PDB databases can be provisioned and “moved around” more easily, i.e. more like a virtualization strategy than a copy/clone strategy.
- On the Versioning side, the PDB architecture should make patching/upgrade processes/procedures more streamlined, i.e. spin up a new PDB with the new version, pump/transport, test, and switch services. Or just unplug a PDB from a previous version and plug into a CDB at a later version (hopefully).
My two cents: there are lots of other 12c features, but the Pluggable Database was the major one that was “officially” announced at OOW. The 12c release will still support the non-PDB architecture, and many VLDB and OLTP databases would not benefit from PDB architecture anyway. But for multi-tenancy situations with small-to-medium sized databases, its a huge benefit, primarily due the reduction in per-instance machine resources. Also, for the growing trend towards database consolidation, it also makes having multiple database co-exist and “play nicely in the same sandbox” more realistic, cost effective, and manageable.