Re: mounting shared file system for Oracle and multiple machines

NFS is totally outside SQL*Net.

SQL*Net only handles traffic between clients and the database server.

NFS is a shared disk scheme. One of your servers would have the actual disk drives. It would mount filesystems on those drives. It 'exports' the filesystems via its NFS server software. The other servers 'import' the filesystems via their NFS client software.

The NFS client server software makes the shared disk seem local to each machine. The NFS client server software also maintains inter-node security.

Depending on your network, NFS filesystems could look like 'slow' disk.

So, you would eliminate the ftp step. The file would automatically be sent over the network, synchronously (meaning: your database job might take longer, but still shorter than the database time + the ftp time). It also means that your database job fails if the network fails. With the two step job, the database step can complete and then you can run the ftp whenever the network comes up.

Steve Perry wrote:

> First, thanks for the help on disaster recovery. I never got a definitive
> answer on whether I only need the hot backups or both the hot and cold, but
> I received some things I can try out.
>
> Now, I have a question about having a common shared area for "utl_file_dir"
> access for Oracle on multiple machines.
>
> Currently, we create extract files, ftp them to another server, run a stored
> procedure (or package) that uses the utl_file_dir (I think that's the one)
> and they read and/or write files to that directory and then ftp and on and
> on and on...
>
> I got a request to have a staging area (group of disks) setup that can be
> NFS mounted by multiple machines and look local to them (i.e.
> /u09/stage_data). Many machines would could mount this and I would set the
> "utl_file_dir" to point to it.
>
> Our AIX admin said it's possible, but I don't think it's a good enough
> reason to do it. I'm not an AIX expert and don't know the
> impact/overhead/risks of doing it. From a dba point of view, I'm looking for
> opinions. I see a couple of problems like:
> what happens if the disks go down? Multiple machines are affected.
> Security??? I'm not sure on this
> Troubleshooting? I can see it being a potential problem that's not obvious
> to figure out
> disks fill up? potentially all instances sharing it are affected
> garbage can or heavy maintenance??? it becomes a trash can and I'm unable to
> determine what I can clean up
> more or less network traffic??? I don't know. I can't imagine you eliminate
> the ftp. It's a sql net transfer instead I guess.
>
> From the programming staff, they thought because it would look local it
> would eliminate ftp's. Like I said above, data still has to be passed back
> and forth. I don' t think sqlnet is faster than ftp...
>
> Any input would be apprecated.
>
> Thanks,
> Steve
Received on Tue Sep 22 1998 - 00:00:00 CDT