Valuable Features:
I'm going to be discussing Database In-Memory and Multitenant in Oracle 12c.
The multitenant features offer some really excellent flexibility, especially for an organization that's looking to consolidate their databases from smaller servers, especially smaller servers, possibly to desiloize, as I like to say, and bring their databases up under one larger database instance. It also makes it really easy to clone a database, either for read-only purposes or for read/write purposes extremely quickly, usually in less than a few seconds.
Database In-Memory, to me, is the most compelling reason to go to Oracle 12c, release 1. 12.1.0.2 is the beginning release for that. Database In-Memory offers the ability for analytic queries to run extremely quickly because essentially, it's employing what's called the columnar format. We've never had that in Oracle until 12.1.0.2. The idea behind that, especially if you have a table that's really wide and with several hundred million or even billions of rows, you can scan that table and filter it extremely quickly, even in a data warehousing environment, essentially join it extremely quickly from a fact table to multiple dimension tables in unbelievable speed. The idea there is that, because it's in a columnar format instead of a row major format, you can access the data much more quickly, especially if you have a very wide table because you can eliminate a lot of the intervening columns.
Improvements to My Organization:
Multitenant is going to get much better in the next release, but that doesn't mean you can't adopt it right now. The major advantage of multitenant, as I see it, is to be able to share memory on a larger server with larger amounts of CPU and especially larger amounts of memory. If you have an engineered system, especially an Oracle engineered system, you can take advantage of the extreme amounts of memory and CPU capacity and essentially share that memory across smaller databases by consolidating them. That's why they're called pluggable databases being plugged into a consolidated, as we call them, CDBs and PDBs. The advantages are that you can leverage that huge amount of memory and compute power for smaller databases.
Another major advantage of it is that you can also quickly clone a production database into a test or a dev database. That's extremely important in today's world where DevOps is happening so quickly and customers need to sometimes get a test database or a DevOps database, an exact copy of production, at almost the same point in time. It doesn't necessarily have to be synced perfectly with production, but that it can be very, very close to what you have right now and be able to test extremely quickly because the cloning mechanism is so blindingly fast with pluggable databases when you're in a 12c environment.
Room for Improvement:
The In-Memory database features are probably going to double in capacity and in power in the upcoming release; also, with pluggable and container databases. They're going to become much more flexible. Most of this is already public knowledge. I'm just not discussing details at this point.
The one feature that I'd like to see more emphasis on is security because as we move towards the Oracle Public Cloud, it's here already. The biggest concern and we heard this in many of the talks here at Collaborate 16 this week, but also among my clients and customers is, is it secure. That's an excellent question and the answer is it absolutely is. It's absolutely secure because you can't not encrypt. You must encrypt your data when it's placed inside the Oracle Public Cloud. Now the wonderful thing about that is that you hold the private key; the private key part of the private key infrastructure and public key infrastructure, so there is no way that a government agency, for example, could come to you and go, "I want all this data." All that they would get would be the encrypted files. That may not necessarily be true in other cloud implementations. I'll leave it at that.
Stability Issues:
The stability of the solutions are one of the more impressive things. Having come from Oracle 8i as my first Oracle DBA job, when a new release would come out, there were always tremendous numbers of bugs. That's not the case with these 12.1 releases. They're extremely well-tested. I'm not going to say there aren't any bugs but they're fewer and farther between than they were in earlier releases. There's a significant advantage to getting on the 12.1 juggernaut, if you will, because these releases have been very well shaken out.
Scalability Issues:
I'm not going to get into too much because I haven't tried that, I'll be honest. It offers quite a bit of scalability in terms of scaling out and scaling up because all of these features for pluggable databases and that’s the multitenant feature, but we also talked about the Database In-Memory feature, scale extremely well, especially in a real applications cluster or rack database environment. Container databases do take a little bit more thinking. You have a limited number, only 254 possible pluggable databases, inside a container database and you are essentially creating a different version of an Oracle database, container versus, as we call them, non-container or non-CDBs. When you're building that initial container database, you do have to think about which way am I going. The good news is there's a very simple procedure to take a non-CDB and make it into a PDB underneath a CDB with a very limited amount of downtime of the source non-CDB.
From the In-Memory side for 12.1.0.2 for setting up the In-Memory column store, it's literally change one initialization perimeter, bounce the instance, and you're ready to go. It's extremely simple to do that. There is also a really good tool that allows us to figure out which objects should be inside the In-Memory column store, called the In-Memory Advisor. That has even matured since about a year ago when that was first released, it's much easier to figure that type of thing out. In terms of implementation, it's really quick and almost painless, is what it comes down to.
Other Advice:
I would have to say the In-Memory column store is definitely a 9.5. It's really great right now in 12.1.0.2 and it's going to get gooder in the next release. Multitenant, to be honest, is a little adolescent at this point. There are some things I wish it could do right out of the box but what I'm seeing coming in the next release will probably get it up into the 8.0 or 8.5 range. In terms of security, I'd have to say some of the features we discussed are actually quite good right now. I'd put them towards a 9.0. Oracle Public Cloud needs some more work. As an Ace Director for Oracle, I'm working very closely with the team and my company, OnX Enterprise Solutions, as well, is working very closely with Oracle to make Oracle Public Cloud better, stronger and more easily deployable. For all of these, I'd have to say probably 8.5 to 9 on a scale of 1 to 10.
My recommendation is if you're going to go to 12.1, immediately take a look at the In-Memory column store. It's the biggest bang for your buck. I'm not going to discuss the L word, licensing here, while we're here. It is definitely not a free feature but, in my opinion, if it's implemented properly, it might save the cost of an extra DBA. A good DBA, I'm from Chicago, might cost somewhere between $110,000 to $130,000 a year in salary, not counting benefits. You could save that amount, if you will, OpEx with some CapEx. That's a compelling story. The ability to take a query that you might have dedicated a full DBA to, to make it run faster, and simply by throwing a switch make it run faster, that's a compelling case to me, as a DBA but also as someone who deals with C-level executives and DBA managers all the time.
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer: We're platinum partners.
