Re: ORACLE AND UNIX QUESTION

From: Output Services <output_at_netcom.com>
Date: Tue, 11 Oct 1994 22:28:31 GMT
Message-ID: <outputCxJ53J.J9p_at_netcom.com>


In article <781842670snz_at_sambusys.demon.co.uk> psb_at_sambusys.demon.co.uk writes:
>In article <outputCxFnIs.8C7_at_netcom.com>
> output_at_netcom.com "Output Services" writes:
>
>> In article <781720147snz_at_sambusys.demon.co.uk> psb_at_sambusys.demon.co.uk:
>> >In article <2aa.553.846%mpcbbs_at_ibase.org.br>
>> > Carlos.Netto_at_ibase.org.br "Carlos Netto" writes:
>> >> I use raw-devices on a production machine. I don't know anything about
>> >> performance improvement. I choose to use raw-devices because it's possible
>> >> to loose a data-file when using fsck. But be sure, it's harder to
>> >> administrate
>> >
>> >That's like saying that I leave the lawnmower outside so that we don't trip
>> >over it in the lounge.
>>
>> I implemented raw FS at our site for the same reason. After a crash,
>> fsck will come up with orphaned inodes that it will then "clear."
>> This looks awfully spooky to me. Maybe I'm paranoid, and this is
>> perfectly ok, but I don't think so. Altho, I'm still waiting for
>> someone to run newfs against an "unmounted" oracle partition and
>> waste the tablespace. :-)
>>
>> Marty
>
>The point I was making was that there might well be good reasons for
>using raw partitions rather than filesystems but that is NOT a good
>one B_E_C_A_U_S_E (and perhaps I should have made this explicit) the
>tablespaces can go in their own filesystems away from all other OS or
>user files. Then there will be no inode creation activity or file
>enlargement on that tablespace and fsck will never barf on _those_
>tablespaces.
>
>Paul Beardsell SAM Business Systems Ltd

Good point.

Marty Received on Tue Oct 11 1994 - 23:28:31 CET

Original text of this message