This is how an upgrade with pluggable databases looks conceptually:
You have two multitenant databases from different versions in place. Preferably they share the same storage, which allows to do the upgrade without having to move any datafiles

You unplug the pluggable database from the first multitenant database, then you drop it. That is a fast logical operation that does not delete any files

Next step is to plug in the pluggable database into the multitenant database from the higher version

Another annual DOAG conference has passed, and I can only say the very best about it: Perfectly organized, large and modern location, impressive list of well known speakers and over 2100 attendees – wow!

My presentation Best of RMAN was scheduled at the first slot on the first day, so I was a bit concerned whether many people would attend that early. It turned out that the room got so full that I was asked by the organizers to deliver the same talk again next day – which I happily did, again with a packed room :-)

The recipients of the Oracle University Leadership Circle Quarter 1 Fiscal Year 2016 have just been announced. That is a corporate award for the best instructors worldwide according to customer feedback. Not less than four (!) come from our small team of 14 instructors:

Yes, we have a great team – supported by a great manager: Thank you, Richard! Congratulations to everyone in the circle this time, I feel honored to be listed together with you!

Say I have created a new tablespace recently and did not yet take a backup of the datafile. Now I lose that datafile. Dilemma? No, because I can do an ALTER DATABASE CREATE DATAFILE. Sounds complex? Well even if I wouldn’t be aware of that possibility, a simple RMAN restore will work – as if there were a backup:

FASTSYNC is a new LogXptMode for Data Guard in 12c. It enables Maximum Availability protection mode at larger distances with less performance impact than LogXptMode SYNC has had before. The old SYNC behavior looks like this:

LogXptMode=SYNC

The point is that we need to wait for two acknowledgements by RFS (got it & wrote it) before we can write the redo entry locally and get the transaction committed. This may slow down the speed of transactions on the Primary, especially with long distances. Now to the new feature:

There is a new auditing architecture in place with Oracle Database 12c, called Unified Auditing. Why would you want to use it? Because it has significantly less performance impact than the old approach. We buffer now audit records in the SGA and write them asynchronously to disk, that’s the trick.

Other benefits of the new approach are that we have now one centralized way (and one syntax also) to deal with all the various auditing features that have been introduced over time, like Fine Grained Auditing etc. But the key improvement in my opinion is the reduced performance impact, because that was often hurting customers in the past. Let’s see it in action! First, I will record a baseline without any auditing: