Re: RAMSAN Experience

  • From: Martin Berger <martin.a.berger@xxxxxxxxx>
  • To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 9 Sep 2009 19:58:43 +0200

Rob,
If you really searching for the last bit of performance, I'd suggest to target your PGA-approach, even if it leads you into underscore_parameters. Even TEMP in a RAM-Disk will have a huge amount of overhead: at least all the file-system & OS-IO-code for a 'simple' memory-to-memory-copy.
If you want to be on the save side, you can ask Oracle directly for consultace, even from the support devision :)
I have no proper environment to strenghten my ideas (have to live on the really cheap side of the possible environment - not even to think of ram-disks or ssds or whatever), so please be careful with my ideas! 

hth
 Martin


Am 09.09.2009 um 17:29 schrieb Rob Dempsey:


Hi Tim / Greg

Thanks for the quick responses
I guess I should try and explain the problem a little bit more. This is a simplified version (it will make a much longer email to detail all our constraints and resources). We have a read only reporting application that allows users to query raw row level data. There are a number of combinations a query can have be it date period, type of products etc etc which makes it near on impossible for us to summaries the data - trust me I would if I could. For our large system the two main tables are in size 

A       25690.25M
B      2955.25M
We use Oracle compression, pctfree 0, parallel query and partitioning on date. As our users seem to be addicted to response time being as low as possible and not having enough expertise in storage one solution was to set a db_cache_size that could accommodate all the table data and throw it into memory. Simply a large in memory database. This solution has worked very well for our smaller database, however as the data got larger hash joins, group bys are spilling to disk. PGA is set to a large value and my next point of call is to test different value for the underscore parameters that control it.
We use EMC storage however the latest idea is to use RAMSAM for the temporary files. I always thought it might be a good idea for the redo logs but I am not sure about the TEMP files.
Like I said we have a number of constraints, but any help would be welcome. 

Rob

-----Original Message-----
From: Greg Rahn [mailto:greg@xxxxxxxxxxxxxxxxxx]
Sent: 09 September 2009 13:45
To: Rob Dempsey
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: RAMSAN Experience

Out of curiosity, how large is your DW and what is workload today?  Do
you use parallel query?

I ask because SSD is not really that beneficial for a DW, especially
when it comes to price/performance over spinning rust (HDDs).  SSD is
(mostly) about IOPS, not MB/s throughput which is where most DW are
sized inadequately.
On Wed, Sep 9, 2009 at 4:54 AM, Rob Dempsey<Rob.Dempsey@xxxxxxxxxx> wrote: 
I have been asked to consider a RANSAN for our Oracle DW database.
I was wondering if anyone had any experience of the technology? Pros and the 
Cons.


--
Regards,
Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 09-2009