RE: Solid State Disks for Databases

Ramfs is system memory and very few machines have any kind of power-out or even reboot persistence for system memory.

Solid state disks come in at least two classes:

1. No guaranteed persistence across reboots
2. Persistence and reliability competitive with or superior to the data loss due to a multidisk hit on RAID.

There are probably classes in between, but except for "temp" space or databases where you don't care if you lose the contents you need to use class 2 as defined above. The relevant value is the estimated mean time between data loss (as opposed to merely the mean time between failure). If the SSD is not at least as good as your disk farm in MTBL(oss), then you're asking for trouble.

Early in the thread, Cary made the essential point about Amdahl's Law, and I paraphrase: Even reducing effective service time to zero only helps 1% if the total time of that service is 1%.

Several years ago a long since sold company I helped found created a free product called "Terascape Dipstick" for precisely this reason: If you didn't have a significant disk i/o problem, you didn't need either further Terascape consulting analysis nor the Terascape product. If the Dipstick identified you, there was a high likelihood you needed one or both. If memory serves, something on the order of 5-10% of the self selected shops who thought they might have a disk i/o problem actually had a problem of significance. That number has probably dropped as an increasing fraction of shops execute i/o on increasingly capable cache array based drive sets. I don't know whether the dipstick is still available, and I can't remember if I'm allowed to say who bought it.

Now that all said, if you really have an i/o crunch that is driven by actual work and not a side effect of bad plans or stupid design, properly utilized SSD very likely can help.

A surprising amount of improvement in the service times of "medium hot" objects can be gained by reducing the "cache pollution and cache domination" of a few very hot objects onto SSD. If cycling redo logs is either occupying multiple units of i/o for ping-ponging, SSD can actually reduce your costs. How many shops actually need this? Good question, and the answer is dynamic. As an architecture safety play, building in some SSD to hold online redo logs and to serve as fast scratch space is getting to be quite affordable. If you're planning to buy some SSD in conjunction with a claim that you're about to fix some performance problem, then you had better measure in advance to be sure it is a problem you can solve.

In closing, a useful exercise is to model the service time from SFO to Oakland Airport with security, check-in, and luggage retrieval and then vary the flight time with a 737, a Concorde, and a propeller driven biplane. Then ride BART.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Dennis Williams
Sent: Wednesday, October 05, 2005 4:04 PM To: MFontana_at_verio.net
Cc: gogala_at_sbcglobal.net; mcdonald.connor_at_gmail.com; Oracle-L Subject: Re: Solid State Disks for Databases

> > Neither prayer, nor the ray of light, nor the whole Madonna collection
> > will help you if your redo logs are on ramfs and your machine crashes
> > for whatever reason.

I'm confused. Wouldn't the SSD have its own battery backup?

Dennis Williams

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l