Agreed. Many times things may not be much helpful in real life scenario
unless used in correct usecase and can introduce other issues. So better to
start safe and hear from someone who already used these options to cater IO
issues in similar scale db etc.
On Wed, 22 Sep 2021, 1:26 am Lok P, <loknath.73@xxxxxxxxx> wrote:
Thank You Mark.
I see it's available starting with version 12C. In one of our 19C
databases I see in gv$parameter , we have inmemeory_force 'default'
inmemory_query 'enable'. So we can try experimenting with it on a test
database by tweaking a few table designs and running a workload to see the
difference in reduction in IO. And as it seems this in memory column store
is actually a hybrid architecture of row+column store and the column store
is going to be stored in buffer cache only which is not a persistent
storage area, so is it really recommended and going to make a difference in
IO/Performance for big databases , say 100TB-200TB in size in a real life
scenario? I may be thinking it in dumb way of requirement of buffer cache
in TB's.
And just curious to know, Is this additional licensing because of which
people are not using it or it's not much in use or popular? because even in
this forum i never saw questions/discussions on any database with in
memory columnar feature used. Or are there some drawbacks that come with it
in real life scenarios, if we use that option?
On Wed, Sep 22, 2021 at 12:34 AM Powell, Mark <mark.powell2@xxxxxxx>
wrote:
Lok, the extra-cost Oracle In-memory feature supports column store
tables/indexes
In-Memory Column Store Architecture (oracle.com)
<https://docs.oracle.com/en/database/oracle/oracle-database/19/inmem/in-memory-column-store-architecture.html#GUID-EEA265EE-8FBA-4457-8C3F-315B9EEA2224>
Mark Powell
Database Administration
(313) 592-5148
------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on
behalf of Lok P <loknath.73@xxxxxxxxx>
*Sent:* Tuesday, September 21, 2021 2:48 PM
*To:* Oracle L <oracle-l@xxxxxxxxxxxxx>
*Subject:* Question on IO consideration
Hello Listers, We have oracle exadata databases which are performing
mostly warehousing or batch type data processing. And few are hybrid i.e
combination of both oltp+warehousing/analytics types processing. ETL jobs
run on a few of these which move/read/write billions rows daily.
The databases are 50TB to ~150TB in size currently. Few architecture
team members suggested evaluating if we can use columnar database type of
offering for IO reduction and thus better performance considering the
future growth. As per my understanding , Oracle stores data in row format
only, so is there any other offering from Oracle for columnar datastore
format or columnar databases and we should evaluate that? Or is there any
clustering kind of technique which can be evaluated which will help reduce
IO? Want to understand experts' views here on this.
Regards
Lok
