Re: Solid state disks for Oracle?

  • From: "Alex Gorbachev" <gorbyx@xxxxxxxxx>
  • To: "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 10 Mar 2006 09:00:34 +0100

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@xxxxxxxxxxxx>:
> 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
--
//www.freelists.org/webpage/oracle-l


Other related posts: