Re: Solid state disks for Oracle?

Well, placing redo on SSD will give high throughput in MB/s as well as IO/s (which is I believe more imporant for redo). Back to practical setup - there is no point running database in noarchive log mode and SSD will provide even more benefits becuase bulk reads shouldn't affect writes. However, (!) your archive log destination should sustain very high IO throughput so that archivers can keep up with log writer. Obviously, placing archivel log destination on SSD is not feasible.

Regarding UNDO tablespaces - it might be cheaper to oversize buffer cache so that UNDO tablespace can be mostly cached. In this case only writes needs to be done but those are background things and tuned properly shouldn't affect performance. (ok, there can be some overhead of managing lager buffer cache) In our case, undo tablespaces usually experience very few reads and almost exclusively write IO.

I have done some benchmarking on redo logs on SSD (from TMS) and on EMC's DMX and results are not too bad for DMX - it seems that sometimes DMX experience cache saturation that gives some instability to write IO. Otherwise, it performs just a bit slower than SSD (my bottomline was "log file sync" waits).

Above is based on practical experience we had so far and our short benchmark we were able to do on SSD.

Just my two cents.

2006/3/10, Nuno Souto <dbvision_at_iinet.net.au>:
> Kevin Closson said,on my timestamp of 10/03/2006 9:16 AM:
> >
> > Does it really take 104 slides to point out that a solid state
> > disk is faster than 7 SATA drives? What am I missing here?
>
> Ah well, you're missing the rates... ;)
>
> > I tried to turn this thread into one of a bit more sophistication
> > by bringing up the fact that these things are very expensive and
> > you can't just sit one over in the corner and get your money's
> > worth because they are simple SAN arrays that serve up LUNS.
>
> They are not - at least at this stage - cost effective for entire
> tablespaces. Or even undo or temp. But for redo, I can't think
> of anything that is as cost effective.
> Recall that most sites nowadays slap-on a SAN on everything.
> RAID-5 is *not* the best config for redos but it takes a lot of pain
> to remove it from SANs and reconfig only redo areas for RAID-10.
> Much better to just add-on a small SSD, create the redo f/s there,
> and bang!: there is your turbo-charged write speed *exactly* where
> you want it.
>
>
> --
> Cheers
> Nuno Souto

--
Best regards,
Alex Gorbachev
--
http://www.freelists.org/webpage/oracle-l