We are running Oracle on our filers currently and we didn't put the Oracle account in the /etc/passwd file on the filer. That really only comes into play if there are multiple systems attached to the filers and you are trying to do data sharing on these boxes, but the UIDs are not synced with NIS or something like that.

Roland,

I have been charged with a storage consolidation project. As part of this project, we did a survey of available storage technologies and looked at more from a "does this solve our problems?" perspective that from a "what is the fast storage available?" perspective. We did not however ignore the performance issues because I believed as you currently do that NFS just can't be as fast as local storage. We constructed a series of perl scripts and C programs to do I/O and log progress, timings, etc. I did this because I have in the past worked for a hardware manufacturer. My experiences working for a hardware manufacturer made me very jaded as to anything that any of the sales or marketing people said about performance.

What we found out was that for general filesystem I/O, our F760 using a Gigabit interface was slightly faster than our JBOD SCSI disks if we used separate channels on the SCSI and used the same Gig-e interface. Otherwise the filer was way faster. When we compared the performance on the filer versus HP's mod-20 disks (a differential SCSI attached disk array that has 20 drive slots using a RAID5 LUN - it's really a 20-slot CLARiiON), we found that reading data on the mod-20 was about the same as reading data on the filer, but writing data was again way faster (2 - 3X depending on block sizes) on the filer. I think that this was caused by the advantages the WAFL in the filer has over other RAID5 implementations.

All of these tests were done using an HP K-class and N-class boxes. If you were thinking that this is because Gig-e is just way fast, and that is what has to be used to get this type of performance, we also tested it with 100BaseT full duplex and found that it was about the same speed as locally attached SCSI. If I have a performance complaint it would be that Gig-e has shown as much improvement as I hoped for over local storage and 100BaseT full duplex. I'm hoping that Netapp will build boxes with more ram and/or fasters NICs to get the performance on Gig-e up to the 70+ MB/sec range.

When we tested database accesses using Sybase we found that database loads on the filer ran as much as 50% faster, general queries, inserts and deletes, ran about 30% faster, and backups ran about 15% faster without even using snapshots. We did not capture specific stats on Oracle, but our DBAs expect similar results.

There is another performance issue that is often overlooked that you get with filers or other systems that have 3-way mirror capabilities, and this is the part where we actually see some value in the storage. This is backup and recovery. On one of our database systems, we currently have a backup process that runs for about 10 hours. During this time our users are impacted because the database is in a state where all transactions are logged, but not actually committed to the database. This means that we can't do any heavy processing during this 10 hour window. With snapshots we will put the database in to backup mode only long enough to take a snapshot, and then return the database to online mode and continue normal processing. Next we use a separate Unix box to mount the newly created snapshot and send the files to tape without putting overhead on the database server. So from a performance perspective we gain 10 hours of processing time. This means that if the filer is only equal to our direct attached SCSI storage on a transaction by transaction basis, we get back 10/24ths of our processing time back which is about a 41% increase in performance.

>>> <rdobbins@netmore.net> 08/08/00 06:38PM >>>

No account/password is required for *NIX access to the filer via NFS; that's
all handled via the standard NFS permissions and *NIX filesystem
permissions.

As to running Oracle with the data and logfiles on a filer via NFS, I should
think that even with a NetApp using Gigabit Ethernet, you'd take a -huge-
performance hit as compared to a local disk array. I've no empirical data
to back this up, mind you; it's just that there's so much overhead
associated with NFS even on an optimized platform like the NetApp filer, I
can't see it as being a win.

If there's anyone out there with Oracle experience on filers via NFS, either
pro or con, I'd love to hear from you.

-----------------------------------------------------------
Roland Dobbins <rdobbins@netmore.net> // 818.535.5024 voice

-----Original Message-----
From: Jiang, Perry [mailto:Perry.Jiang@BMO.com]
Sent: Tuesday, August 08, 2000 2:18 PM
To: toasters
Subject: NetApp questions

Hi, there

I have a question regarding NetApp Filer 740.

Oracle account

I am running a Solaris Oracle server, which is a NFS client of the NetApp
Filer. Do I have to
create an Oracle account on NetApp Filer and put the entry in
/vol/vol0/etc/passwd?
If yes, what the purpose of that?
An on-line NetApp document, "Oracle for UNIX: Integrating with a NetApp
Filer", stated that you need to create an Oracle account on Filer. However,
according to the System Admin. Guide, /vol/vol0/etc/passwd is only for CIFS,
not for NFS.

You explaination is appreciated.

Perr Jiang