Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: I/O tuning... Allocating spindles to databases

RE: I/O tuning... Allocating spindles to databases

From: Murching, Bob <>
Date: Thu, 15 Sep 2005 18:25:38 -0400
Message-ID: <>

In retrospect, you're right, I could see how the presence of cache could degrade performance (a little). Are there any arrays that are capable of streaming data from disk to both the host (via fiber/fcal/scsi/gbe/whatever) and cache *simultaneously* ? Or, when a physical read occurs that must be cached, is the data first placed in the onboard cache, *then* read from cache and sent on its way to the host as probably is the case with most arrays? I'd imagine this is the case with, say, a Symmetrix-type array which I believe has processors doing the dirty work on both sides of the cache. It takes a lot of of spindles before memory-to-memory throughput starts to become a bottleneck on an "intelligent" SAN but I can see how a couple of percentage points could get consumed. Moreover big SAN/NAS boxes have their own processors, operating systems, patches, crashes and performance issues that could add additional latency to a given IOP.

I miss the days when, in the event of throughput issues, you only needed to check into the size of the pipe and utilization of the disk spindles. Now you have to deal with storage backplane bandwidth, protocol overhead, CPU load, SAN/NAS OS efficiency, and so forth. In the push to up utilization efficiency (of any kind of hardware) through virtualization, the notion of guaranteed performance has been tossed out the window. Now you have 100 systems running virtualized on one server connected to one SAN that presents 100 virtualized disks, and heaven help you if something is slow! At least our end-user's desktop PCs aren't being too virtualized... oh wait, we got Citrix too....

-----Original Message-----
From: Kevin Closson [] Sent: Thursday, September 15, 2005 5:45 PM To:
Subject: RE: I/O tuning... Allocating spindles to databases

 >>>Even if such access patterns are less than likely, it's 

>>>still important to know how storage responds in worst case scenarios.
>>>Cache on the SAN/NAS is not a bad thing. I can't think of a
>>>situation where it would *degrade* performance merely by its

I've done a lot of benchmarking on systems configured with over 1000 disk drives and believe me, caching data that will never be revisted does not boost performance.

Think FTS. I have used arrays that allow you to completely disable cache and doing so on the tables that sustain scans was often a performance boost. Mileage varies.

>>>We've had a NetApp with rather fast disk and huge cache.
>>>Burst performance indeed can be good. But, the thing has effectively
>>>single gigabit fiber backbone and a single and heavily burdened
>>>storage processor that renders it incapable of sustaining more than
>>>maybe sixty (60) megabytes/sec

That is because it is a single headed NAS. You need to see HP's story with the Enterprise File Server Clustered Gateway. Supports 16 active:active heads with no SPOF.

Besides, it's OEMed PolyServe :-)

Received on Thu Sep 15 2005 - 17:27:50 CDT

Original text of this message