Re: The old raw devices chestnut.

"Andrew Hamm" <ahamm@mail.com> wrote in message news:<c5i1eq$1uguo$1@ID-79573.news.uni-berlin.de>... > Mark Bole wrote: > > I haven't worked with an Oracle raw device since version 7.3 seven > > years ago, and would never go back. The administrative overhead is > > just too much of a headache. > > [Posting from comp.databases.informix] > > I've never understood the "administrative overhead" argument against raw > spaces. Can you elicidate on the administration you think needs to be > applied? In my experience, the only admin overhead is making sure that a > new, naive sysop doesn't try to turn a raw space into a filesystem - I saved > an engine by SECONDS once, by looking over the shoulder of said sysop as I > walked past.... Funnily enough, that very reason is the one I've considered most important for years: http://groups.google.com/groups?selm=1996Jun26.140851.7868%40rossinc.com&oe=UTF-8&output=gplain ( the "other hand" line has been superceded in more recent versions ). I'd add that if you are that close to saturation where a small percentage will make such a difference, you probably need some good tuning and/or more hardware. > > Apart from that, I find that admin is slightly simpler simply because you > don't need to run a mkfs style of command ;-) > > I have heard that Solaris (?) is in the habit of re-creating /dev at boot > time, and I know that DG-UX used to do the same thing. Therefore some sort > of tool is needed to make sure the raw devs exist after a boot. Is this what > you mean? jg -- @home.com is bogus. Please ignore this link. http://www.securityfocus.com/columnists/224

Joel Garry wrote: > > Funnily enough, that very reason is the one I've considered most > important for years: > http://groups.google.com/groups?selm=1996Jun26.140851.7868%40rossinc.com&oe=UTF-8&output=gplain > ( the "other hand" line has been superceded in more recent versions ). He-heh - 1996? that would be around the time my engine was under threat. However, dangerous people can do damage to nearly everything. I've also seen LOST engines from people either deleting or moving cooked files. You can run, but you cannot hide. > I'd add that if you are that close to saturation where a small > percentage will make such a difference, you probably need some good > tuning and/or more hardware. Wellllllll, no. NIMM (not in my mileage) a 20% improvement is good - why not? It also improves throughput - 20% would be Just About noticable too. But more importantly, it's during periods of heavy sequentials that it kicks in. An overall benefit of 20% will probably give you bursts of much bigger improvements. Like the (Informix) situations I've mentioned such as creating spaces, but also things like light scans, checkpoints (a major bugbear for some people) and of course big sequential reads and builds. Further (with Informix, once again) the engine can use KAIO, and with the architecture of Informix, this can lead to further significant improvements. It all adds up. Why do you think F1 now make their pedals out of carbon fibre? And they *still* drill 'em out for extra lightness. An Informix engine using raw with KAIO and a decent layout of spaces on the disk can feel very spiffy indeed even compared to one that merely drops KAIO and raw. Some UNIX platforms with Big Hairy storage boxes do provide device drivers etc that support KAIO by either faking the raw device or just providing the feature. What you do with that hardware depends on the machinery of course.