Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambrium.nl!feed.tweaknews.nl!postnews.google.com!r15g2000prd.googlegroups.com!not-for-mail
From: Pat <pat.casey@service-now.com>
Newsgroups: comp.databases.oracle.server
Subject: Re: Replicated File System Consistency
Date: Thu, 1 Jan 2009 09:12:35 -0800 (PST)
Organization: http://groups.google.com
Lines: 57
Message-ID: <5e3c076f-8b36-4f75-8bb4-9d6cc9704542@r15g2000prd.googlegroups.com>
References: <e2b6f814-3e0f-42e9-b0f8-ccdd0b29485f@w1g2000prk.googlegroups.com> 
 <1230681062.28865@bubbleator.drizzle.com>
NNTP-Posting-Host: 76.176.128.125
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1230829956 31872 127.0.0.1 (1 Jan 2009 17:12:36 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 1 Jan 2009 17:12:36 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: r15g2000prd.googlegroups.com; posting-host=76.176.128.125; 
 posting-account=fN91uQoAAACHkEp9Vu564OuxPru2CJ5d
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; 
 rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20,gzip(gfe),gzip(gfe)
Xref:  news.cambrium.nl

On Dec 30 2008, 9:55 am, DA Morgan <damor...@psoug.org> wrote:

> David's link is a good one but I'd like to address the fact that you
> are not seeing any improvement from the NetApp 3040. Here are a couple
> of questions you might explore:
>
> 1. What is the limiting factor? CPU? Network bandwidth/latency? Storage?

  Nature of our app is that the working set fits in memory most of the
time, so we're largely CPU bound, and you wouldn't expect a SAN to
change that at all. We have certain queries/operations that tend to be
IO bound, but we didn't see a dramatic improvement on these (maybe 20%
if I recall).

> 2. How many LUNs? (one is never almost never the right answer)

   I think its 70 disks, split into 3 aggregates of 10, 30, 30. Dunno
how many luns the san has, but all the DB servers have three luns.
Boot LUN is on the 10 disk aggregate, /u01 is on the second aggregate
(30), and /u02 is on the third aggregate (30).

> 3. What RAID level?

   RAID-DP which is netapp's version of RAID-6

> 4. How is the cache configured? What percentage read? What percentage write?

   8G cache on each head unit (2 head units), but I don't know how its
configured. Frankly didn't even realize you could configure different
read/write percentages. I supect the SAN guys know though; is it worth
asking? Is there a recommendation as to how the cache should be
allocated? Our workload is very read heavy so I'd naively assume a
bigger read cache would be preferable.

> 5. How many physical disks are you striped over for your hottest data files?

   30 Fiber Channel 15k drives on each of the main data aggregates.

   All the numbers point to the SAN being much faster, but I think
what we basically proved is that we don't have an IO bound workload.
To give a little history, we used to have serious problems with IO
throughput, so maybe 2 years ago we went through a project to put
everything on 64 bit oracle (we used to run 32 bit) with uniform 24G
SGAs across all our databases. WIth that much memory and a read heavy
workload, our IO problems were largely solved even before we brought
the SAN into the picture.

   My suspicion is that if we took the old (IO bound) configuration
and moved it on top of the SAN we'd see a tremendous boost in
throughput, but the current config is largely CPU bound so the SAN
doesn't make a lot of difference.

   FWIW the main reason we went SAN wasn't throughput, but crash
recovery. If a DB server explodes, I can mount its 3 LUNS on a hot
spare and have it back up in a matter of minutes. Since nobody wanted
to pay for dataguard, its the best hot failover strategy we could come
up with.
