Re: external storage and commit?

Andrew Mobbs wrote:
>
> This is also true of HP XP series arrays, they term it a "cache lun".
> If you generate sufficiently little redo, and can spare a few GB of
> the array cache for it, it works very well. Certainly the Shark has the
> required battery-backed, mirrored RAM.
>
> Even though it should work in theory, I'd explicitly check with Oracle
> or IBM that the configuration is supported.

Probably just ask IBM, since afaik Oracle doesn't certify hardware. I'm surprised to hear about a restriction on the amount of redo for the Shark. For EMC towers (8430, 8730, etc.), the cache works quite nicely for all database files, even extemely large and/or active online redos. All writes go to cache first - you have no choice. Eventually the infomation gets moved to actual hard disk. Last time I checked these towers support 16GB of cache, if you can afford it.  

> In the sort of systems I'm involved with, using the array cache for
> redo isn't that useful, as it is too small and leads to too frequent
> checkpoints.

Not database checkpoints I assume? Or if so, I'm not sure I follow.

> Someday somebody will give me 100GB of solid state disk
> for my online logs, and I'll be happy, and wave goodbye to log buffer
> and log sync waits. :-)

Will 75 GB do? (http://www.bitmicro.com/ - actually, I don't know anything about the company but their site turned up on a google search) I think Compaq offers something similar. It'll cost you though. :)

Regards,
Sean Received on Mon Apr 15 2002 - 15:58:12 CDT