Re: Raw I/O vs files (was Re: Raw partitions / cooked files)

In <1993Jul29.213213.25205@exlog.com> lparsons@exlog.com (Lee Parsons) writes: >In article <1993Jul29.112058.20676@pyra.co.uk> graeme@uk.pyramid.com (Graeme Sargent) writes: >>In <2506@coyote.UUCP> gainer@slowmo.almaden.ibm.com (P. Gainer) writes: >> >>>In a recent append, lparsons@exlog.com (Lee Parsons) writes... >>>>Before I get flamed I should say there are cases where going raw is >>>>the thing to do, but those cases are rare and usually in situations >>>>where doing the Right thing is not an option. >> >>I am not convinced by this at all. I feel that the cases where I could >>be persuaded to go cooked (which I think of as the Wrong thing, but >>maybe that's my Informix-oriented heritage) are rare (or unimportant, eg >>a non-production requirement). >> >>I cannot see these supposedly many advantages in going cooked, so the >>thought that it *might* be slower is sufficient to vote raw. >Ok fair enough, We are all products of our environments. I for one have >heard the words 'Oh I was suppose to add that disk to the backup routine >last week' far to many times to feel real good about the idea of adding >a data file that can't be backuped by find . -name *.dbf -print | cpio . >I could go on about the bad things associated with raw, but you would >correctly rebuttal with 'But that only happens when someone doesn't >do their job right' or 'But what's a worst case situation'. >Unfortunatly, I have been stung enough times in both cases to make me >gun shy. I guess also I have been overlooking the fact that not all systems offer the same level of flexibility and control over raw devices as a Pyramid does. I would still have a script which automated my backup via *.dbf etc, it's just that *.dbf would be symbolic links to my raw devices (or more likely, a mirrored pair or trio of striped raw devices). I would create my tablespaces on the *.dbf slinks so that I could easily move my data to different raw devices transparent to Oracle, should I ever wish to. Sometimes I even put my Control files on raw devices, and I'm getting the impression that that idea would horrify some Oracle DBA's! The only file that I feel really *belongs* in a filesystem is init.ora. On a Pyramid if I want a new raw device of let's say 123 Mb then I just go ahead and create one, as long as I can find or free up enough free space on one or more of my disks. I understand that some environments (eg HP, I understand) are pretty brain-dead about raw devices, and you're effectively stuck with the ones they give you. In that scenario, I think I would probably come round to your point of view. I still find it surprising that Oracle (unlike Informix) does not allow you to put multiple files in the same raw device, which must limit flexibility somewhat in an HP type environment. graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.