Re: IDEA - put redo logs onto a non-volatile RAM DISK?

"Hagen Malessa" <malessa_at_webit.de> wrote in message news:9etic0$2u2c$1_at_news.space.net...
>
> "Mark Tompkins" <mdtompkins_at_home.com> schrieb im Newsbeitrag
> news:3B0D3FFE.C252ED93_at_home.com...
> > Hi,
> >
> > Has anyone ever tried this? If so, why is it a bad idea?
> >
> > thx
> >
> > Mark
> >
>
> How about this :-)
>
> Assume, RAM size is not a problem and you place your hole database (all
> datafiles) and redo logs to RAM disk. You only allow ARCH process to write
> archive files to disk storage. On disk storage you have a recent backup of
> all datafiles. So if the server has trouble you recover the database from
> storage to RAM using a script in init. If you use a HSM I would call it a
> HSM+ :)
> Okay, I know that it is not usefull for all kinds of database, but in some
> cases...
>
> Hagen
>

you are right, this is NOT useful. and i cannot think of a single case in which this would be a good idea.

if you had this kind of a budget for memory, why would you want to incur the overhead and bottleneck of accessing it via i/o operations over an i/o channel ?

if improving i/o throughput and performance are the issues, there are more appropriate, cost effective options than your proposed solution.

for example, introducing a storage subsystem with cache memory can produce a significant improvement without the need to hold the entire database on RAM disks.

in my experience, a poorly designed and written application is the primary culprit in poor application performance. excessive database i/o is often a symptom of the problem, not the problem itself. if you can address the root cause of the problem, you significantly reduce the need to add expensive hardware to address the "performance" problem. Received on Mon May 28 2001 - 12:58:47 CDT