For anyone looking for information on 12c, there are several posts about OpenWorld at the dbi Services blog (see links at right). In particular there’s a summary post about the “pluggable database” describing how you could plug a database into a “container” database, clone it inside the container database, then unplug it and put it somewhere else.
When I heard about the feature, it crossed my mind that there were two “obvious” targets for this technology that Oracle had in mind – in no particular order:
- Consolidation onto Exadata – I’ve seen an Oracle presentation about a customer who moved 18 databases from 14 servers onto 2 Exadata quarter racks; that’s a lot of processes that have to be running per rack simply to keep the many instances idling. If you plugged all the database into a single instance you should get no application interference between databases and a minimal set of background processes.
- Applications as a Service (or should that be Software as a Service – SaaS): if a 3rd party wants to run your Peoplesoft system for you, they would probably prefer to run one database with multiple Peoplesoft databases plugged into it.
Currently “real” consolidation means lots of work to change multiple databases into multiple schemas in a single database, and worrying about public synonyms; running multiple copies of the same application in the same database demonstrates the most extreme example of how pluggable databases bypass the problem. Just think how nice it would be, as a service provider, to keep a single “empty” Peoplesoft pluggable database in your container database which you clone whenever you sign up with a new customer. And, as a customer, if you want to change your service provider, perhaps you could insist that you supplier unplugs your Peoplesoft database so that you can plug it in at your new service provider.
Another little detail that Hermann Baer mentioned in his presentation yesterday was the ability to create multiple indexes with the same column definition – something which currently gets you Oracle error “ORA-01408: such column list already indexed.”
No details, and there’s always the “safe harbour” slide of course – the one which says seomthing about the presentation being only an indication of current thinking and nothing is guaranteed to appear.
Having said that, this looks like an interesting option for those (possibly rare) occasions when you want to change a unique index into a non-unique index (for example, to change a unique constraint to deferrable). Rather than having to drop the index and create a new one – leaving the table unindexed while the index builds, you appear to have the option to: “create new index online”, “drop old index”. Moving a primary key constraint from one index to the other might not be so easy, of course, especially if there are foreign keys in place – but this certainly looks like a helpful step. [Update: actually it's easy to move the constraint - as I subsequently found in this post.]
Details to follow when 12c becomes available.
Update Sept 2013
Although you can create multiple indexes with the same column definition, only one of them can be visible at any time – so this should remove the temptation that Richard describes in his comment below. It won’t stop people creating “duplicates”, though, and leaving some of them invisible for a while just in case they need to change their minds. Always keep firm control of your indexing.
Most useful presentation of OOW so far, from Hermann Baer of Oracle on improvements in partitioning features in 12c – and there are lots of useful ones, including:
Online move of a partition – so easy to compress a partition when it has reached its final “read-only” state
multiple partition maintenance in one operation – e.g. merge 3 monthly partitions into one quarterly partition, or split one partition into 24 (think about “how do I partition a non-partitioned table”, and 12c has just made it easier and quicker – exchange it into an empty partitioned table, then do one massive split).
partial indexing – define which partitions of a partitioned table should be included in the indexes you create on the table – and the optimizer also knows that different partitions need different plans (an enhancement of “table expansion”.
interval-reference partitionining – you can create an interval partitioned table, and use ref-partitioning to create child (and further decendent) tables, and their partitions will automatically be generated, truncated, and dropped as the parent is extended, truncated or dropped (needs enabled foreign key constraints).
Lots more details – and lots of stress-testing to be done – but I’m off to hear “the optimizer lady” talk about hints.
Oracle has a “safe harbour” slide at the start of all presentations about future developments pointing out that the information presented is an indication of direction, but not guaranteed to make it into production.