Oracle 12c New Features Part 1 (Pluggable Databases)

After recent experiences with Oracle 12C I thought I’d discuss some of the more interesting new features. There is quite a lot of information so this will be broken up into a number of articles.

Pluggable Databases

The headline feature of Oracle 12C appear to be the multi-tenant container and pluggable databases. However moving to a pluggable database is not simple process, particularly if you are running previous versions of Oracle.

Currently the 2 supported methods are:

• Data Pump export and import.
• Upgrade to 12c ‘normal’ database and run pluggable migration scripts.

While both methods worked well, this does mean significant down time is needed, particularly if you have a bigger database.

Once your pluggable database is live you have some very good features like the ability to clone from one pluggable database to another, so duplicating an environment for UAT testing is a lot simpler.

Architecturally, there are 2 system tablespaces when you have a pluggable database configuration:

• The Global Container database. This database holds all the views or procedures provided by Oracle, for example the utl_mail and dbms_metadata packages.
• Local Pluggable database. This database holds user defined functions, so any packages that are generated by application installs scripts.

This is the same for the SYSAUX tablespace also.

One of the issues I identified was around backups. If you run a RMAN backup for a pluggable database, which syntactically is possible and valid, this would not be sufficient to restore the user data. It would be missing the addition Oracle provided packages as these are stored in the Global SYSTEM tablespace.

Another issue identified is if you have a message indicating you have a data corruption in the SYSTEM tablespace. This message shows up while you are accessing data in a pluggable database.  You have no way of identifying if this is the Local system tablespace or the Global system tablespace.

If you need to restore this, you have to follow this process.

1. Change the pluggable database to a mounted state.
2. Run the RMAN restore database command for the local PLUGGABLE database.
3. If this fails, you need to stop the whole database and open this in a mounted state.
4. Run the restore global container database.

Why is this an issue?

If you have 10 pluggable databases, you could have to restore all 10 databases, of which 9 do not have any issues at all. While you should not lose any data as everything is backed up, downtime is the main issue. Why should other applications be forced into downtime unnecessarily?

Granted the risk of this sort of corruption is quite low, but why would you risk this if there is simple ways to avoid it. As a DBA one of the key requirements is to be able to recover a database in a timely fashion. This way of running Oracle puts you at risk of needing a restore and it not being related to an issue with your particular instance.

In the next post, I’ll discuss some of the other features in Oracle 12c.

Richard Thorpe is a Senior Database Administrator with over twenty years’ IT infrastructure implementation and support experience in environments ranging from telecommunications and manufacturing to retail. He is a specialist in relational database technologies with a primary focus on Oracle and Microsoft SQL Server.