With the general availability of the Oracle Database version 12c imminent upon us - it's time to look at what - for now - before more information at the launch webcast tomorrow and real client adoption - is the key feature of 12c.
The end of multitenancy as we knew it
We already discussed the implications on the multitenancy term in a previous post. And to quickly re-cap - in the past multi-tenancy in the area of databases was always referred to as a striped database, where different tenant's record were stored in the same tables and the software programs had to find a way to only feed the right records to the right clients. That was a design approach pretty much dictated by system and software capabilities about a dozen years ago.
Alternatively vendors would bypass this design by running one database per tenant. And this approach inherently had advantages in regards of portability, data security and tools availability. But it came along with a higher hardware price tag and higher operations and maintenance costs - as more hardware would be needed to support this configuration.
With 12c Oracle now makes the important separation of its database metadata and user storage data. The two were combined in the past and only Oracle would know how to separate the two. Originally this was conceived for performance reasons, but with significantly more RAM in today's servers, that technical separation is no longer necessary.
Oracle 12c effectively makes the metadata of its database multi-tenant, that is to support multiple user databases. The advantage is that the user data bases now do not need to be striped, made multi-tenant anymore. Confusing? Certainly, but once understood - it makes sense.
And as Oracle's perspective to view the world from the database as the vantage point is certainly legitimate - so 12c makes the meta data (and with that the user data) multi-tenant.
How can a database by elastic?
Well out post title is certainly a bit contradictory - as a database itself cannot be elastic - as it stores data... And data needs to be kept and stay on HDD (or other media). So let's not confuse elasticity with caching - though there are some common elements. [Sidenote - caching becomes very relevant if you are an in memory database like HANA - see my post here].
The elasticity with 12c does not come in from the storage side, but from how the metadata to access the user data is handled... and that is highly elastic, with system load determining what part of the metadata and for which user database it will be running.
Basically Oracle applies similar principles as any IaaS vendor does when starting virtual machines to the meta data code for specific user data bases that are being requested and / or used. We will need to learn more on the details here - as Oracle with the Oracle VM has it's own virtualization technology - but we expect that to be too much geared to the needs of general programs and applications than to server the specific needs of the database - but we will see.
The result is an elastic database - and with that users benefit from the key benefit of elasticity - more software can run on the same or even less hardware. And Oracle has not been shy with demonstrating this - checkout the slide below for the specific claims made at OpenWorld 2012:
Back then Oracle (rightfully) garnered some criticism in regards of the use case chosen - and we are sure Oracle chose something favorable for the cause. But looking back - if Oracle can deliver on only 30% better utilization - then they will have secured their market leadership for years to come.
The irony is - Oracle can effectively create a business case out of the inefficiency of their former database architecture. But to be fair - that was always known and customers more than willingly traded for that architecture and in return received scalability, stability and reliability.
Backward compatibilty
All this would be good and great - but much more difficult to sell, if Oracle would not claim - and again reality checks will have to happen - that moving to 12c is a seamless upgrade. And we need to intuitively give Oracle the point here, as they should and would know how to move a pre 12c database structure over to a 12c one.
I would even expect that the formerly striped multi-tenancy databases will be able to be upgraded programmatially, especially if the Oracle supported feature of Virtual Private Database was used.
Salesforce.com as the proofpoint
A lot has been said and written about this partnership. And there are pros and cons for salesforce.com to renew its dependency on Oracle. But it's clear salesforce.com will gain operating cost advantages from Oracle - as Marc Beniof is on record, that these are only about 1/3 of their current costs. [To be fair that included also the usage of ExaData - not just Oracle 12c].
MyPOV
Oracle has delivered a key database release with 12c, that if it stands up to the claims made, will solidify Oracle's position as a database provider for years to come. We also think that in combination with the recent alliances, Oracle has taking the step to overcome the disruptions the overall market will face by moving from internet based to cloud based architectures.
Nonetheless the NoSQL challenge remains, equally as does the in-memory challenge - and Oracle will need to address these. But for now it's about congratulating Oracle on 12c and looking forward to see the proof points in real end usage scenarios.
My latest take on Oracle overall can be found here - takeaways from the Oracle analyst summit.
Oracle official 12c website
Reprints can be purchased through Constellation Research, Inc. To request official reprints in PDF format, please contact Sales .
Although we work closely with many mega software vendors, we want you to trust us. For the full disclosure policy, stay tuned for the full client list on the Constellation Research website.
