Last week I attended the Northeast Ohio Oracle Users Group’s (NEOOUG) first meeting of 2013. The main topic of the day was the upcoming release of Oracle 12c. The “c” stands for “cloud”, and the focus is on making private cloud environments easier to deploy and manage.
Pluggable Databases
Up til now in Oracle, every database required its own memory structures and background processes. You could have multiple schemas using the same database/instance, but if you wanted to have separate databases, you needed to spin up a new instance. This meant managing memory, resources, patching, etc. between two separate environments. Spin up a couple more, and you can see where the management nightmare begins. Well, with version 12c, Oracle is introducing the concept of pluggable databases (PDBs). The idea is that you install a single container database (CDB), which manages the memory and background processes, and then you “plug in” user databases (the PDBs) into the CDB. All of the PDBs share the same pool of memory and processes. So instead of multiple instances, each with a single database, you now have a single instance housing multiple databases. Hmm, where have I heard that before…
Anyway, in addition to making resource management easier, it also makes patching easier, since you patch the container database and the patch is applied to all of the plugged in databases. The obvious question then was: what if you have an app that can’t be patched, like your ERP system? In that case, you can spin up a new container database, unplug the ERP database from the first container and plug it into the new container.
There were still some unanswered questions surrounding the whole multitenancy concept. Could you plug a PDB into a lower version CDB? Does each PDB have its own redo logs, control files, UNDO and TEMP spaces, etc. Details like that aren’t clear yet, or at least they weren’t clear at the meeting. What is known is that you’ll get one CDB and one PDB out of the box. Additional PDBs are a licensed feature ($).
But wait, there’s more!
While the pluggable database change was the big news of the afternoon, there are other new features in 12c that are also worth noting.
- Data Guard Far Sync – introduces the ability to asynchronously replicate your database to another geographically separate datacenter through the use of a Far Sync database. The Far Sync database is a stripped down database composed of only control files, redo logs, and enough data space to house the redo data being sent to the remote standby database. The idea is that the primary database synchronously sends redo data to the Far Sync database. The Far Sync compresses the redo data and sends it asynchronously to the standby database.
- Information Lifecycle Management – tracks extent or block-level statistics on read and update activity. This information can then be used to create a heat map of how data is being utilized (or not utilized) to better plan how to treat that data when it comes to storage. Business rules can also be put in place to automate partition compression or movement based on usage. It’s also smart enough to exclude DDL, statistics maintenance, and reads that result from full table scans.
- Data Redaction – dynamic data masking for queries based on rules created in the database. I thought this one was pretty neat, since previously you had to code the redaction of sensitive data at the application level. But this obviously left you open to other query tools. Now the database handles the redaction, based on business rules you create.
And that’s all, folks. If you’re interested in becoming more involved in the Oracle community here in the Cleveland area, check out the NEOOUG’s web site and consider becoming a member.
