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: Nuno Souto <>
Date: Wed, 28 Sep 2005 01:31:26 +1000
Message-ID: <>

Murching, Bob apparently said,on my timestamp of 28/09/2005 12:32 AM:

> 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.

Not needed. That's not where they are useful.

> 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 that is you cannot apportion cache the way you can apportion disk. Not with standard run of the mill disk farms. It costs a lot to do that.

> 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.

You forgot the obvious fit:
4- I need to write my redo logs as fast as possible, in something other than vague cache shared with all the other disks in my disk farm.

That is the sole place where a solid state disk in its current technical form is darn useful. To try and run an entire database in one is ludicrous and entirely not the proposed target market.

The current size of solid state disks is perfect for redo and a much better use of storage space than a 6Gb slice of a dedicated 250Gb disk drive, mirrored/cached or whatever.

> 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.

Unless you are running the top of the line disk farm h/w, you cannot adequately control and apportion the RAM in that cache. Anyways, you are still stuck with using a smal slice of a large disk. And the top of the line of that disk farm defeats the cost advantage, that's for sure...

> the cost. Having to mirror solid state disk would 10x more painful.

No need. It's backed up by battery and disk. The memory is the cheap component of the solid state disk, it can cheaply be mirrored. In fact, the devices I saw four years ago all had mirrored memory and backup disks in a standard single slot rack mount. Oracle redo writes positively flew on them.

Of course, Texas might have a different way of packaging it which makes it more costly. Anything is possible in market-land. :)

Nuno Souto
in sunny Sydney, Australia
Received on Tue Sep 27 2005 - 22:05:21 CDT

Original text of this message