Re: Why use Oracle In-Memory database from another perspective

From: <richard.rankin_at_ieee.org>
Date: Tue, 3 Oct 2017 11:06:36 -0700 (PDT)
Message-ID: <d67515e4-3c27-4d15-892d-64b595d7c8fb_at_googlegroups.com>


[Quoted] On Sunday, September 17, 2017 at 9:46:54 PM UTC-5, richar..._at_yahoo.com.hk wrote:
> Why use Oracle In-Memory database from another perspective
> A lot of people are talking about why or why not use Oracle In-memory database in their applications and most of them are too focused on the size of the database or whether it is an OLAP application. It seems that small and medium size databases are not suitable for using Oracle In-memory database option. But if your OLTP databases are suffering from performance bottleneck and you are looking for solutions, I think Oracle In-Memory database option should be on your solutions list, especially when you are planning to upgrade your hardware.
> https://tosska.com/use-oracle-memory-database-another-perspective/

[Quoted] It's always useful to put pin and code into memory. There are quite a few caching options and the option to put tables and other objects in memory. An in-memory database allows you to put an entire subset of the total system functionality into another database and have it in memory. This requires a lot of memory but it's not all that expensive these days. So the question may be: move a big chunk of your functionality into an entirely different database in memory or be more selective and pin objects, cache complex query results. You may have to make these decisions when building the physical database and trying different options to see which works best. Possibly even in production some or a large portion of, the heavily accessed objects into memory as you find the need (for speed). However, a no-brainer is to buy an Exadata machine with its caches, its varying disk speeds 7.2K rpm, 15K rpm, SSDs and let the system to decide where stuff will be (although you're not giving up control completely). The Exadata will move things around to accommodate changes in access patterns. There are a number of options and you can decide what to do based on a priori knowledge and make changes later based on numbers you gather. The hardest to make changes later with is using an in-memory, you either build it that way or not. Changing it involves a complete redesign. Moving to an Exadata system is as painful as moving any system to a new box. With using a variety of individual options you can add, remove and modify these options. I'm not going to make a decision for you. That's your job. Received on Tue Oct 03 2017 - 20:06:36 CEST

Original text of this message