Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Solid State Disks for Databases

RE: Solid State Disks for Databases

From: <>
Date: Tue, 27 Sep 2005 13:19:31 -0400
Message-ID: <>


        A point very well taken. Actually SSD may cause a undesirable side effect, namely a lot of unexplained wait io on the system side as the SSD may deliver data to the server faster than it can move it through the backplane.

-----Original Message-----

From: Cary Millsap [] Sent: Tuesday, September 27, 2005 1:16 PM To:; Goulet, Dick;; 'Oracle-L'
Subject: RE: Solid State Disks for Databases

The one idea I'd like to highlight...

SSD will help performance of a task only in proportion to how much time the
task spent doing disk I/O in the first place. This is just one specific application of Amdahl's law.

Example: If a one-hour task spends 45 seconds executing disk I/O syscalls,
then SSD will make at most a 1.25% impact upon that task's runtime.

Specifically, I'll mention that if V$SYSTEM_EVENT shows that I/O "wait events" have consumed more time than any other "wait event" (Statspack, for
example), then you have no idea by how much SSD might help your end users'
performance, or whether in fact SSD will even help at all.

Cary Millsap
Hotsos Enterprises, Ltd.
Nullius in verba

Visit for curriculum and schedule details...

-----Original Message-----

On Behalf Of Murching, Bob
Sent: Tuesday, September 27, 2005 9:33 AM To: ''; ''; 'Oracle-L' Subject: RE: Solid State Disks for Databases

Texas Memory Systems had a presence at OOW and I had a chance to talk to them and take a look at some of their offerings. They had a 32GB solid state device (expandable to 128GB at a price that you probably can imagine)
that was handling 70,000 IOPS (8k blocks) which is pretty impressive, no question. I think it's available with the standard fiber channel interfaces
and you can cluster them, LUNs, etc. I think I might be able to get a Ferrari F430 for the price of one.

I think these things are being positioned as cache gateways between disk and
blades, for shops with 1U blade investments that can't be loaded up with 16GB of RAM. Even the solid state vendors will admit that real-time, on-the-fly caching is going to use expensive RAM more efficiently than a RAM
disk; this always has been the case. The problem with their proposed niche
is that if I'm using a 1U blade that can't be filled with 16GB or 32GB of
memory, then I am doing so primarily for one of three reasons, 1. I can't afford bigger iron --> then how can I afford solid state disk?
2. I'm short on rack space in the data center --> these solid state boxes
are rather big!
3. I need highly parallelized, compute-dense blade clusters --> then 32GB
solid state disk systems start to look really small if it's servicing a dozen blades, each of which can be outfitted with, say, 4GB of cache.

Smaller solid state, only 2GB? I'm hard-pressed to come up with a reason
why it would be better than tossing a few gigs of RAM into the box or SAN
and taking advantage of all the great tools we already have at our disposal
to optimize the usage of that RAM.

Moreover, mirroring 15,000rpm disk already can be painful when you consider
the cost. Having to mirror solid state disk would 10x more painful.

-----Original Message-----

From: Goulet, Dick [] Sent: Tuesday, September 27, 2005 9:48 AM To:; Oracle-L
Subject: RE: Solid State Disks for Databases


        Yes they appear to be much faster than normal disks, but they are
also substantially, like a factor of 3 or 4 times, more expensive as well.
We use EMC Symetrix systems and right now we can get 72GB mirrored for about
$5,000. Soliddata's E75 is roughly the same price and only has 2GB of space.

-----Original Message-----

[] On Behalf Of Hemant K Chitale Sent: Monday, September 26, 2005 6:20 PM To: Oracle-L
Subject: Solid State Disks for Databases

Has anyone used or tested Solid State Disks for Databases ?

The paper seems to indicate that Solid State Disks are now well on the way
to acceptance.
I have been asked to consider if we should look at this technology for High
I/O databases {first identify databases with very high I/O rates}.

Hemant K Chitale


-- Received on Tue Sep 27 2005 - 12:21:41 CDT

Original text of this message