Oracle Database In-Memory Reviews

The stability of the platform is the most valuable feature. The solution can support large amounts of data once the architecture is in place.

The solution could benefit from AI improvements.

Technical support could be improved.

The usability of the solution could be better. They should make it easier in terms of system administration and for getting examples of statistics from the databases. An interface or dashboard for statistics would be better. Right now, we're using cloud controls to do that, but it's not good enough.

I've used this solution for the past five months and was an Oracle Database administrator from 2000 to 2005.

The database is very stable.

The scalability of the solution is very good. It's able to support large amounts of data.

Technical support is below our expectations currently. It could be improved.

The solution was already in place when I began to work for the company. I don't know if they previously used a different solution or not.

We have ULA agreements with commission in place with Oracle. The pricing is okay for now.

We use the on-premises deployment model in the virtualization environment.

I'd rate the solution eight out of ten. If technical support was better and usability was improved, I'd rate it higher. It's the best solution on the market right now, but it's more for big data. For us, it's the best solution we can get for our specific needs.

We primarily use the solution as a warehouse. In the front end we are using MicroStrategy, and we are using Oracle as a database.

The warehouse is the solution's most valuable aspect.

The solution is very fast.

I'm not sure about the improvements needed in the solution.

The solution is quite expensive.

I've been using the solution for two years.

The solution is stable.

The solution is scalable. Almost everyone in the company uses the solution.

The solution's technical support is good.

I did not install it myself, but the database administration team did, and they found it simple. In one day they were able to administrate the data stack file.

Our team handled the implementation.

Oracle is a costly product.

Choosing this solution was the choice of the database administrator. I didn't participate in the process, so I'm not sure what was used before of if other solutions were evaluated.

We use the on-premises deployment model.

I'd advise others to look at the solution, but to be mindful as it is costly. Whether it is right for a company or not depends on the requirements. If they have the budget, they should go for Oracle. If they do not, I'd suggest they look at something open-source like MySQL or Oracle SQL.

I'd rate the solution nine out of ten.

My solution has a big database with terabytes of data and we use Database In-Memory for a lot of our data. Normally, we partition it and create big tables, but we can use In-Memory for data that we use every day or every hour. We put some partitions in In-Memory from some tables and we use that. It normally has good performance.

Normally, every database server uses hard disks. In-Memory has a feature, apart from its database, which is very good. When we start our server, all your data needs loading memory. We can use that. It's a very good feature. I think they added this feature in 2019. We can mount memory in the partition, create partitions in there, and create tablespace from that spot to share. It's a really good feature. We use it a lot.

We use some partitions in In-Memory. We have a very large table and a low dose. It is very expensive in data to load all of them into In-Memory. It takes up more memory slots in the server, as well as a lot of RAM. We use the last partitions on the table. We always need to create a script and make a schedule that can load the last partition In-Memory. Oracle doesn't have features to do this automatically. I would like them to allow us to load last partitions, as well as other table partitions, in In-Memory. I think a good feature would do that automatically, letting you see a table, load a large partition, and monitor loading memory. It's quite a good feature.

I have been using this version for about four months.

We have used this feature for four months and it's stable. I used to load one terabyte of data in my memory servers each time. I think it worked okay. I don't have any problem for now.

I live in Iran. Iran is sanctioned by the US government so Oracle can't provide any services to us. I study on my own. I use Oracle documentation and watch YouTube videos. I don't have any company to support us.

It is very easy to deploy. I always work in Linux, Oracle Linux. If you want to work from the GNOME GUI, it's really simple. You must state a parameter in Linux and then use their installer. Click next, next, next, then finish. It's simple. In Oracle 80 and 90, we have an installation system in a common UI. It's very simple. You must have the prerequisites and after that, install RPM in just one comment. Check your configuration and set up the database. It's simple.

Deployment in the GUI version, if you want to use that, is I think 14 to 20 minutes. In the command line, it would take 10 to 15 minutes. I can't remember exactly, but something close to that.

Oracle is the best database, but I love open-source software. Oracle always has the first original features for three or four years and we use them because they are stable and we can buy in a large scale and use it for our office. It has no problems. I think Oracle is ten out of ten.

About Oracle Database In-Memory, in particular, I would rate it as eight out of ten. It's a new feature. I think it's improved from the last version three years ago.

Oracle's new features and data are very useful for us for storing data, loading it, etc. Oracle features based on processes are good. In Oracle, we just have four functions based on data types, but in post-production, we have more than ten functions. That is very useful for us. We'll add more functions and features like index and categorization based on data type, output, and large data. That would be very useful.

We are using Oracle Database In-Memory as an indirect approach to improving response times. In mixed-workload environments, we use the In-Memory column store to support OLAP-type queries without harming the latency-critical OLTP operations the systems "earn money with". This was successful for many customers throughout 12.2 and 18c.

It helps to build successful mixed-workload environments. Thus, for smaller setups, it's enough to have one database setup, not two, and it saves one interface in between.

In recent versions, Oracle implemented storing the In-Memory column store contents in the database, to resurrect the IMCS quicker and in a repeatable way.

One very nice side-effect is the in-memory index. If this would be developed a bit more into being configurable, users could use it as a kind of in-memory partitioning. That opens a big field of possible use cases.

Very stable.

In my experience, it scales quite well. Unfortunately, decent scale-out with RAC only works in Exadata, since Oracle relies on RDMA which is only available for InfiniBand.

"It depends". If you get a good support engineer, it is a dream. 

But, most times, it is not, unfortunately.

No, since there was no other solution offering in-memory without changing the SQL syntax.

We grew into it during beta and initial releases, so I can't answer this.

We do implementations ourselves, so I can't answer this.

If you can save setting up an additional interface and a second DB server, investment should return immediately.

The setup cost is not a big factor, but the engineer should have decent experience with Oracle's In-Memory system.

License cost is a factor; the benefit has to be carefully evaluated.

We tried several ways to offload OLAP queries from the database, especially using a second DB system.

We evaluated this product throughout the beta1 and beta2 phase.

It is always worth testing or running a proof of concept to check its value.

Oracle has a lot of features embedded. In my opinion, Oracle In-Memory offers a lot of improvements in database performance specially for data warehouses and analytics workloads. Combined with Exadata, it makes a solution that will deliver the best performance related to the volume of data.

As I’m very involved in database security, I can tell say that Advanced Security Option and Database Vault are most valuable features for me because I can propose them to my customers to deliver the best security options for their databases.

Each time I've implemented the In-Memory option, the improvements have been on the performance side. This option offers a way to drastically reduce batch duration with a minimum of work because we only need to enable it on columns we choose, test batch performance, and that’s it. We can do this cycle of work less than 10 times and the job is completed.

They need to improve the Decision Support System with analytics workloads.

I've used Oracle Database since 2001, and I officially used the In-Memory option since its general availability in June 2014. But, as I’ve been a beta tester for the Oracle version that delivered this option, I can say that I've used it since the beginning of 2014.

There have been no issues deploying it.

The product is stable. Of course, at this level of software, there are always some bugs. But, each time I have had to implement it, the bugs weren’t very problematic and I've always found a patch or a workaround.

It scales to the needs of my customers.

Technical support is useful with the My Oracle Support website. But when I have to open a service request, I have to find a solution on my own because technical support usually doesn't understand my problem or they always ask for the same logs, same questions, and I ultimately waste my time.

I tested the In-Memory equivalent in DB2 or SQL Server 2014, but they both have limitations in their uses. SAP HANA is one of the most concurrent of Oracle’s solution, but I have never used it.

The deployment was very easy because we just have to set a volume of memory as the In-Memory area, and the enable In-Memory for specific columns. This part is longer, but for me, it’s more a tuning issue than a deployment issue. Deploying Oracle In-Memory is very easy and takes only a few minutes.

Implementing Oracle In-Memory is very easy, but the tuning phase is mandatory to optimize it.

Performance. That's probably the number one.

When we use it for OLTP, which is the Online Transaction Processing, the response for the end-user is pretty fast, which is a good thing, especially if the user is looking at a website, the response time is really micro milliseconds as opposed to waiting a few seconds for that page to load.

I think it still goes back to the user benefiting the most out of this, it's basically a good customer experience, the product.

Nothing right now.

It is pretty stable.

It scales really well.

We had to scale it along with the rest of the ecosystem, not just this in particular, but the infrastructure as well. We had to scale both of them.

We had to involve them just because we ran into a couple of issues and they've been resolved in a timely manner. Pretty good.

No, we always needed something like this, and I've looked at Microsoft, they have a similar solution, I think they have something similar,

It's pretty straight-forward. It's actually more of an inbuilt core functionality as opposed to have us to go through an implementation process.

We did evaluate a few other vendors, but again this wasn't a product on it's own. It's part of the bigger ecosystem. So the decisions are for other reasons.

Try it out first. See if it meets your expectations and go from there.

The most valuable features are its real time performance and consistency.

We are not using it for our internal systems, but rather for our customer solutions. We can provide a high standard with this solution to our customers by using such products.

We are waiting for new features in the next release.

Stability is very good.

Scalability is also very good.

Technical support from Oracle is fantastic. We have been working with Oracle very closely and we are very satisfied with their performance.

We had started to use this solution from the beginning. We haven't switched from another solution. When selecting a vendor, we want someone who has a long term road map. This demonstrates sustainability.

The initial setup was not complex. It was no problem at all and it was straightforward.

We haven't used other vendors. We have a long relationship with Oracle and we have had a good experience with them in the past.

I recommend using this solution, just as we are using it.

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.