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

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. -- Regards, Lee E. Parsons Baker Hughes Inteq, Inc Oracle Database Administrator lparsons@exlog.com