Oracle Database In-Memory Reviews

Ours is a DW environment, ETL extracts data from SAP and loads into the reporting database. The DBA objective was optimal performance for both nightly batch and reporting. We used the below features which significantly helped improve he performance.

We used HCC with query high to compress all the fact tables, Interval partition the fact tables with daily partitions.

Most of the financial reports go back to maximum 2 months so we scheduled a stored procedure to load last 60 days partitions in to IN-MEMORY. We have also loaded highly used dimention tables as well in to IN-MEMORY.

Extended stats was the key to performance, we could achieve good performance of the reports by gathering extended stats. Histograms too were helpful, but extended stants and histograms dont go well together. in our testing phase, we had tested and chose the best one. Over the period when data changed, we switch between the two.

DMRM, was another key to make sure all the consumer groups get the required resources.

Forcing the optimizer to use BloomFilters, boosted the performance to a significant extent. We could achieve this by getting rid of quite a few indexes, parallel processing and optimizer statistics.

Tablespaces with NOLOGGING option. The nightly batch process also has a great performance with nologging tablespaces, parallel DML and insert append (direct path load).

Dynamic sampling set to 4 was. This was the value which gave us consistent performance across most of the reporting.

Disabling optimizer_adaptive_features. This feature turned on, flickered the performance of the reports. We could achieve consistent performance by turning this off.

Cognos Dynamic Cubing, This is a feature used at the cognos layer which helped increase the performance of the reports.

This data is of our BI reporting. This reporting is open for all the warehouse managers to know all their financial status.The period end . We have very tight schedules. Every report has to complete in milli seconds seconds. The SLA are very tight. In memory in combination with partitioning, HCC and offloading feature helped achieve this SLA's.

We use lots of aggregations, and a lot of transformations that happen beforehand. We use Information, and then the data comes into Oracle. Cognos actually runs those reports. That was a very big challenge for us. We didn't use in-memory before.

For most of the tables, we use partitions, we use HCC, and then we could not get through the day with that level of performance. What we did is we made sure that the latest partitions, on which most of the reports run, are actually put into in-memory, and then very highly compressed. We move the data – some of the key tables, master tables especially, and some of the FAT tables – into In-Memory, and we use very high compression ratios. After that, we saw a really dramatic improvement in the performance. We are doing much better than the SLAs require. Most of our reports are converting in 1, 2 or 3 seconds. Most of them are below 5, except if we have any stats issue or anything like that; it takes time for them to complete. After we started using the in-memory product, we saw really dramatic figures.

For some reason, the stats optimizer doesn't work well. We actually disabled some of these features, such as the optimizer adaptive features. On the fly, the optimizer actually changes the explained plan, and that feature is really not working fine. We had to disable that.

The plans were actually not stable when we enabled it, so we had to disable it. We had to lock the stats on some of the master tables, because the plan instability is the actual problem. We don't want the plan instability, and we saw that quite often. We had to disable some of the Oracle’s new features that are not quite mature. That’s one of the problems that we have seen.

We are using this solution for about an year now, The performance is good and is with the desired SLA's.

No we did not encounter any issues with the deployment.

In-Memory stability is really very good.

From the scalability perspective, the concurrency that we expect is 2,000 users. We're only keeping only two years’ worth of data; not more than that. The data comes in and the old data actually goes out to the archives, and only the new data is there. The old data is an SAP, so we don't maintain that. For reporting purposes, we don't want them; we only maintain two years’ worth of data.

The only issues is with concurrency, and we tested it with 2,000 users, so it's fine.

5 out of 10.

Oracle tech support is really not very good; I’m not pleased. For 90% of my tickets, I raise the ticket, and then I work on it and resolve it myself. Oracle provides a solution for only 10% of my tickets. I'm really not happy from a support perspective.

No we have built this on oracle.

Not applicable.

We did this inhouse. We ofcourse hired some contractors who were good at performance tuning.

Pricing and Licensing is not something I deal with. But since we have ULA, we did not have to bother about it.

No we did not evaluate other options, however we are moving out of this option to SAP Hana.

You need to understand the data. You do not want to use In-Memory for all of the data. You need to understand the data, understand the inquiries, understand which data you actually want to put in the In-Memory. You should not put all the data in there.

We do not INMEMORY ADVISOR in oracle, however this is obvious

Which data has to go into In-Memory is something that you only know from experience; how to get the most benefit out of In-Memory. Get access to the Oracle Learning Library School. There are some good videos there for the In-Memory. They're really awesome.

I cannot imagine IT today without Oracle databases. Oracle has basically delivered their data revolution with relational databases and their constant development and innovation going into the cloud.

They are coming up with more improvements than we actually want. If you ask most of the customers, they are happy with what they had 10 or 20 years back. The company has a need to make more money or beat the competition, so they constantly come up with these new features. They say these are cool features to have, but I don’t think they are needs. We don't need all the upgrades, practically speaking.

However, I am interested in the analytics of the data that is used for new research. Customers do need some of that information.

I have used this solution for 15 or 16 years.

This is a very stable solution. You always have kinks with any solution, but they have awesome support, depending upon how much money you pay them. You need to have platinum service to get good support. Otherwise, you'll have to struggle a bit.

The scalability is good, of course. Oracle is known for its scalability.

We have different levels of support. What makes the difference is how persistent you are. If you demonstrate that you have a lot at stake, then you will get good support. If you are very casual, then you will get slack support. This is the case with anybody.

The installations and upgrades are complex. It's a complicated, complex product, so you definitely need technology experts. You can’t just pick up anybody from the street, like a new graduate, to do this work. You definitely need inside help. You need expertise because this is complex technology. You're talking about Data Guard, which is a complex technology. You do need experts for help.

We are going to be an Oracle shop for a long, long time.

When looking for a vendor, I look for expertise, how quickly they can roll out the product, and the cost of implementation.

The most valuable features are the performance and speed.

The key thing for us is that we can meet our customer SLAs because of the performance and the response time we get.

The second thing is, personally, being a database person, I like Oracle Database In-Memory because of the backing of the support. If something goes wrong, I can call support anytime. That's one of the key reasons.

A lot of new technologies have been coming in to the market in recent years. For example, SPARC, and other analytics languages. Most of the legacy databases don’t have that good connections or connectors to those. It's still a challenge to efficiently use them. I don't know about small data, but we have large data. Especially, if you have a large data, then it's not very efficient. We don't have the tweaks to buffer it or stream it properly. Those are the kinds of things I think could be done.

Stability has been pretty OK. There have been some issues. Support was able to help us out with some configuration.

It scales well for our needs.

I've been an Oracle customer with different companies. I’ve worked with them for almost 10 years now. One of the key things that stands out for Oracle is the support, because I also work with other database vendors. That's the biggest differentiator. Even if I have some issue when I get up at 1 AM, I know I can call on support and I know I'll be able to get my problem solved.

We looked at other vendors before we started using this product, but because we were already an Oracle customer, using their database, it made sense to be in Oracle In-Memory.

I suggest looking mostly at the interfaces; that is the key. Even if the performance is good, but the interfaces are not right, to the application or to the front end, that could be an issue.

We’re really happy with Oracle Database In-Memory.

The Oracle database is easier to program and manage, and is secure. It’s a stable, dependable product. It can handle any size database. Reliability is one of the key features necessary for a database product.

Oracle is a large company that is constantly purchasing other companies to add functionality. I think that if I want a new feature, Oracle will not listen to just me. They are marketing to a large market and not just myself.

Oracle occupies the main space in the database market. Additionally, once we put data into Oracle, it's very hard to move it out to another solution, so we have to stay with Oracle. Also, while Oracle is expensive and MySQL is free, MySQL is more difficult to use.

I’ve been using Oracle for over 10 years.

We have not had any problems with stability.

We don’t have any issues with scalability. It will meet our needs for the future.

Oracle’s technical support is good. Even if you do all the right things and the system is working well, still, sometimes something happens. Oracle is a large company and their technical support is comparable to companies of the same size.

My advice it to realize that the cost of the product itself is not the only consideration. Cost for support of the product after purchase must be considered. A decision sometimes seems quite easy to make, but you need to consider many, many aspects. Not to just say, "This is a good one." Good products cost more. They may need more maintenance and more resources for them to work properly.

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.

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.

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.

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.

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.

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.

The most valuable feature of Database In-Memory is that it's really fast. We need very fast transactions that occur in the milliseconds. We've had a lot of traditional solutions that we've had to throw out, losing a lot of money in the process, in deciding to go with Database In-Memory. For us, it's proven to be very fast.

We can get analytics very, very quickly without needing to direct data to separate databases or change our applications.

It's good and it functions, but it's not the easiest add-on to Database to work with. It's still new, so hopefully it'll be improved in later versions.

We started with Database In-Memory probably a a few months ago.

We didn't have any issues deploying it.

The numbers show that it's very stable and very promising for high-transaction, low-latency systems.

We haven't needed to scale it yet in the two months we've been using it.

There was no such software for Database prior to this.

The initial setup was pretty straightforward.

We implemented it with our in-house team.

Our primary use case for the solution is within our on-premises environment. We do not utilize cloud services and rely on local hardware for our operations.

The solution's most valuable feature is its performance optimization within our hardware environment. This capability enhances processing speed, which is crucial for our operations, although the improvements are more hardware-dependent.

The product could benefit from enhancements in its graphical user interface.

I have been using Oracle Database In-Memory for approximately 25 to 30 years.

I rate the product stability an eight. 

I rate the product scalability an eight out of ten. 

The initial setup was relatively straightforward.

Oracle's local support team efficiently managed the deployment process, ensuring a smooth implementation.

The platform's licensing cost needs improvement. 

We selected the product due to its stability, security features, and ability to handle replication with minimal downtime.

The platform is reliable and effective within our setup. However, potential users should be aware of the high costs and evaluate whether the benefits justify the investment.