Re: Oracle on NFS mounted drives

> >>oracle-l_at_CCVM.SUNYSB.EDU
> >>From: mwf_at_coat.com (Mark Farnham)
> >>Last time I knew for sure, you could not run Oracle on NFS mounted
> >>drives. Has this changed? If so, is the capability port specific?
> >>Does anyone know?
>
> My NFS vendor (Falcon Systems) has reference accounts where
> Falcon NFS servers are the source of Oracle's data. Now if you talk to
> Oracle directly, they will say that they do not officially support NFS as
> handing file integrity control to the operating system (and out of the
> hands of Oracle) means that in theory, you could corrupt a table.
>
> In practice, there are a number of companies using NFS as the source of
> Oracle data for a number of reasons. (My reason having to do with optimizing
> query speed.)
>
> lroomberg_at_aol.com
>

Platform: Hitachi 3500 Servers
OS HI-UX (99% compatible with HP-UX)
Oracle 7.1.3.4.0

With the above configuration, I was able to set up two server (A and B - B had Oracle installed, and A access it via NFS, daemons all thus running in A) and had Oracle running in EITHER of the machine, but not both, as some lock file had been created. Simultaneous access of database by two server also make no sense because NFS is controlling the files access/synchronisation mechanism (quoted below from rfc1813 )

>4.7 Synchronous modifying operations
>
> Data-modifying operations in the NFS version 3 protocol are
> synchronous. When a procedure returns to the client, the
> client can assume that the operation has completed and any
> data associated with the request is now on stable storage.

But in database concept this should be the responsibility of the database server. (Am I correct ?? Not sure either.)

I contacted Oracle before, but they said this configuration is senseless, as it defeats the purpose of SQL*Net, which is there to maintain database integrity running across the network, and to allow sharing of database across network.

NFS, running on top of TCP (or UDP?) does not guarantee database integrity when transferred across the network.

>From RFC1813:

> destructive replays of non-idempotent requests. Though to be
> more accurate, it is the inherent stateless design of the NFS
> version 3 protocol on top of an unreliable RPC mechanism that
> yields the possibility of destructive replays of
> non-idempotent requests, since even in an implementation of
> the NFS version 3 protocol over a reliable
> connection-oriented transport, a connection break with
> automatic reestablishment requires duplicate request
> processing (the client will retransmit the request, and the
> server needs to deal with a potential duplicate
> non-idempotent request).

NFS only provide reliability as to the connection, or the filename consistency, but does not guarantee for the contents of data transferred. (Correct??? Not sure either???)

Bye.

Peter Teoh                                      Information Technology Institute
Internet : peter_at_iti.gov.sg                     Science Park II
Tel : 65-7705585                                11 Science Park Road
Fax : 65-7791827                                Singapore 117685