RE: RAMSAN Experience
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <Rob.Dempsey@xxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 9 Sep 2009 16:56:59 -0400
Read Tim's paper about scaling to infinity to see if you can apply his
methodology to your constrained situation. (Partition exchange is a
beautiful thing and Tim explains it better than most and how that in turn
enables you to keep up with having the structures you need to give fast
response. Very cool paper and if you can apply the concept to your situation
you will be a hero, spend less money on hardware, and your CFO will direct
your boss to give you a raise.
Greg's comments on price performance for persistent memory devices versus
spinning rust are exactly on target. In your situation where you are trying
to bust out TEMP space as an independent resource (if the Tim Gorman
strategy doesn't work out for you {and since you're already partitioned on
date it likely will work fine}), see if you can get your EMC savvy folks to
actually do that for you (and make sure they give you enough cache along the
way.) If they can and will, then you might be able to configure multiple
users utilizing several independently operating TEMP[1,2,..n] tablespaces
without collision such that the i/o actually streams. If they won't or
can't, then even though the price/performance is a loser at scale, you
*might* be able to get enough memory "disk" to fulfill your TEMP
requirements at a price that makes sense in comparison to the entire
existing diskfarm.
If I divide by 1000 correctly in my head, your tables are about 26G and 3G,
so you probably do want to price out getting to 64bit hardware and loading
up a big SGA.
And then there is always exadata, but your stuff seems a little small for
that.
Good luck,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Rob Dempsey
Sent: Wednesday, September 09, 2009 11:29 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: RAMSAN Experience
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
