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.

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.

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.

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

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.

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.

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 can get analytics very, very quickly without needing to direct data to separate databases or change our applications.