New Features of Oracle 12c Database Release 1 Patch Set 1

“NO RELEASE 1!!!”

I admit it, I’m one of those “no Release 1” bigots when it comes to new versions of Oracle’s RDBMS.

I know dogma is not meant to have its place in technology, but I have gone through far too much suffering in previous x.1 implementations to believe that it really is different this time, promise when Oracle try and persuade people to upgrade to their latest Release 1.

Oracle have been claiming that “this NEW version is rock-solid, man, none of the old teething problems” since 9.1, so it’s difficult for those DBAs who don’t enjoy pain to make the leap instead of waiting until the second patch set of the second release before starting on their upgrade planning.

HOWEVER, the latest patch set for Oracle 12cR1 was released this week and, BOY, does it have a lot of really cool features.

As ever, the proof is in the pudding – or, at least, the number of flies in the pudding – but these new features have attracted my attention to the degree that I’m willing to give it a chance, after it’s proven itself in on a test VM somewhere.

Not only are Oracle clearly implementing a lot of agile/cloud-ready features with their pluggable databases, but they’re also bringing even more of the technology they’ve refined on Exadata to the main stream with Zone Maps and Attribute Clustering. Think “Exadata Storage Indexes” and turn down your expectations a tad and you have Zone Maps.

Of course, the really exciting bit is the Oracle Database In-Memory – but don’t forget to turn it off if you don’t plan on licensing it!

Oracle Database In-Memory (high-level overview)
– Presents a columnar, in-memory representation of the (stored) row data inside a memory cache.
– This massively improves query performance, especially OLAP queries (cubes, dimensions, etc).
– This feature is enabled by default. As it’s a cost option, remember to disable if you don’t plan on using it!

Advanced Index Compression
– Compression for all indexes … as long as they’re not unique or bitmap indexes or index-organized tables.

Automatic Big Table Caching
– Dedicated cache (db_big_table_cache_percent_target) for caching data from full-table scans.
– In RAC, this only applies to parallel operations.
– In single-instance databases, this applies to both parallel and serial operations.

Full Database Caching
– Put the whole database into memory (if you’ve got it, flaunt it).
– Forces all full-table scans to be cached, instead of the default behavior of not keeping larger tables in the buffer cache.

In-Memory Aggregation
– Optimizes star queries – joins of dimension tables to fact tables and aggregate data.
– Eliminates the need for most summary tables, allowing for OLAP access to real-time data.

In-Memory Column Store
– Allows objects to be stored in memory in a columnar format.
– This is an additional, transaction-consistent copy of the data – the row format data is not changed in any way.
– This is entirely transparent to end users and greatly improves analytical query speeds.
– Run more ad-hoc analytics on the real-time Production data – no need for a separate OLAP data store.

JSON Support
– JavaScript Object Notation data can be stored, queried and indexed inside the database.
– A lot of the cool kids of the app world – such as IFTTT, Launch Center Pro and Numerous – use JSON for notifications/semi-structured data.

PDB Metadata Clone
– Pluggable databases can be cloned with only metadata (no real data) – thus creating a “template” for additional PDBs.

PDB Remote Clone
– Pluggable databases can be cloned over a database link.

PDB Subset Clone
– Only clone certain tablespaces into a pluggable database – the source can be a non-multitenant container database. Depending on how this works, this could save a whole bunch of time migrating databases from your “legacy” into your “new, agile” environment.

Rapid Home Provisioning
– Deploy ORACLE_HOMEs from a catalog of “gold” pre-created homes.

Zone Maps
– Allows I/O pruning of the data based on the physical location of the disks.
– This sounds a LOT like Exadata storage indexes.
– It looks like zone maps can be used in conjunction with attribute clustering to keep data together, depending on its content.

I imagine that a good example would be to keep the last week’s partitions of a table in a “hot zone”, the last month’s partitions in a “cooler” zone and the last year’s partitions in a “cold” zone.

I wonder if this is meant to work automagically with Oracle’s ILM … that would be really nice!