Oracle Database 12C Melbourne Launch

I went to the Oracle 12C database launch yesterday, there was a good turn out and I saw a few familiar faces.

The event was well attended, the MC said it was bigger than Sydney.

The presenters were eager to give the impression that the new pluggable architecture is better than having databases on VMs - the idea that 100 pluggable databases in a Container database is better than
100 VMs with 1 database each. They argue this means more management, plus the management of the VM layer is an overhead, and it means more hardware.

While there are some merits to this - for example if you back up a container database it automatically backs up all the pluggable databases (and you can restore by pluggable database), and if you upgrade or patch the container database it automatically upgrades and patches all the pluggables, to me it also introduces some other problems.
If you lose the host, or the container database, you lose all 100 pluggable databases. They acknowledged this and said you need to have your HA / DR policies in place.
I also feel it introduces the other issue of patches / bug fixes. If one application running in a PDB (Pluggable database) needs a patch or bug fix, you have to apply it to all the others. If it introduces problems in one of the other PDBs, what do you do? Although this has also always been the case with multiple databases running from one ORACLE_HOME.

I'm not sure if organisations will feel the need to use these PDBs. It will be us (or architects) who will advise on them, and I'm in 2 minds. While there are some nice features for DBAs (see below), and Oracle think that it reduces the workload of DBAs (and therefore the need for so many), I think it introduces more work, particularly around the resource management. At the moment if I see a database in a VM is chewing CPU and Memory, I ask the Unix guys to add more. Now I have to look into the container / pluggable resource management and try to work out which one is doing the work and fiddle around. The same with the Automatic Data Optimisation - at the moment the application and business decide what data gets archived, now I will have to generate the heat maps and suggest / implement policies myself.
If I want to set up data guard I have a primary and a standby. Now I have to decide if it's worth putting in Far Sync Standby.
New security features like data redaction and masking take the functionality from the application and put it in the database, leaving me to implement it.

Actually all this is good - the more work we have the better with the amount of jobs being outsourced, so if anyone asks if they should go to V12, just say yes. :) .

These are the notes:


3 Key database focus areas -

Big Data - Social, Blogs, Smart Meters.
Engineered systems - Exadata, Database Appliance.
Cloud - shared resources.

Oracle 12C Multi Tenant Architecture
CDB - Container Database, PDB - Pluggable Database.
Managing a Multitenant Environment

Pluggable databases - isolated from others, portable, no application changes required.
Reduces costs - less hardware, fewer databases.
Can upgrade older versions in place - V10.2, V11.2 and future versions - then plug into a container database.

There is resource management to share resources to prevent one DB from stealing all CPU, Memory.

Using Resource Manager with Cloud Control


Can backup the entire container and restore just one pluggable database.
Restore PDB

Patching the container patches all the pluggable databases (like patching an ORACLE_HOME).

Can take a PROD pluggable database and plug it into a DEV container, making a copy. Snapclone is almost instant.
Cloning a PDB

Automatic Data Optimisation - policy based compression and archiving, based on access time as well as age of data.
Automatic Data Optimisation

OEM12C has pluggable ready commands / displays. SQLDeveloper has pluggable commands.
Cloud Control




PDBs share the SGA and background processes of CDB.
As PDBs added to the container, only small increments of memory are required.
PDB has SYSTEM, SYSAUX and optional TEMP tablesspaces, plus application tablespaces can be added as required. Don't have UNDO or REDO, these are shared with the CDB.

DataGuard is at container level - if you add a PDB to the primary, it automatically gets copied to the secondary.

If you have 2 different versions of a CDB, ie V12.1 and V12.2, you can unplug a PDB from the 12.1 container and plug it into the 12.2 container and it is
automatically upgraded (the PDB doesn't actually change).

CDBs work with RAC.

A new PDB can be created in about 1-2 minutes, uses a "seed" database which is in every CDB.

Can upgrade a V10.2.0.5, 11.2.0.1, 11.2.0.3 database to V12.1 directly, then plug it into a container and it becomes a PDB. No application changes required.
SQLDeveloper has the functionality to make an upgraded db into a PDB.
Can use expdp and impdp to migrate as well.



New Security features

Redacting / Masking data built into the database with policies and roles. Can remove specific data / fields from reports using OEM12C, becomes effective immediately.
Real Application Security allows the database to enforce application security.
Unified Auditing - new roles - audit viewer and audit administrator.
Auditing turned on by default, new syntax for auditing. DB Performance not affected.
Privilege Analysis with Database Vault - reports on actual privileges / roles used and identify any not used that can then be removed.


Maximum Availability Architecture

Distant datacentre locations cannot use Dataguard synchronus replication due to the lag.
New feature called Far Sync Standby - small instance between primary and secondary, only controlfiles and redo logs. Zero data loss, no performance impact.
Far Sync
No licence required.
New feature called Application Continuity and Transaction Guard - coders currently have to allow for multiple errors and plan with exceptions. Transaction Guard has this built in so code doesn't need to try and cater for all events.
Transaction Guard and Application Continuity
True Transparent Application Failover - Can now do DML, but some conditions (can only use a specific JDBC driver).

RMAN can now do table restore.

RMAN Recover Table

New feature allows online datafile move.

Automatic Data Optimisation

Maintains a database 'heat-map' of frequently accessed data, less frequently accessed data. Can be displayed in OEM12C.
Can compress the older / less used data automatically based on policies. 3 levels - Advanced Row Compression, Columnar Query Compression, Columnar Archive Compression.
Syntax:
"alter table sales ilm add row store compress advanced row after 3 days of no modification;"
I got the impression that this requires a licence.