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

Spencer,

I hear you loud and clear. It is exactly as you speak.

There is no easy way out for a poorly written and designed application.

Other than, figuring out what the real problems are, and solving them.

thx

Mark

Spencer wrote:

>"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 Tue May 29 2001 - 00:05:39 CDT