Dick, With all due respect, I'd like to interject. Due to the many levels of abstraction imposed by the various RAID schemes, volume managers, dynamic multi-pathing, file-systems, and databases, my eyes tend to cross whenever someone starts talking about the movements of the disk heads, rotational latency, and so forth. The perception of "contiguousness" in a file-system or database datafile on a modern server in relation to disk surfaces is purely illusory.
It is somewhat akin to the idea that every US dollar bill is backed by a sliver from a gold bar deep in the bowels of Ft Knox -- the facts are much more complex, by design. Your other comments about WAFL's side-effects are interesting and thought-provoking. It's been a few years since I've worked on NetApp and just this week I was called in to help improve performance on a large Oracle environment over NetApp. At this point, I'm glad that I had not blurted out my long-standing misgivings about the product, as it seems that its ability to support higher volumes of I/O from Oracle has improved. It just requires different methods of administration and configuration. It's not your grandfather's file-system, that's for sure... Respectfully, -Tim on 9/19/03 9:34 AM, Goulet, Dick at [EMAIL PROTECTED] wrote: > Matt, > > Well I'm happy to see that you consider WAFL as "crafty". In my book it does > not have such a nice connotation. Consider the typical disk drive where you > layout your files as contiguous blocks of space around the disk drive. So > long as the file remains it's current size all of the data is gathered > together and easy to read/write. You don't need to constantly slam that head > around to get where you want. With WAFL all of that heads for the hills. > Sure the original file is contiguous, but hit the first update and bingo > that's history. Now the head has to fly around reassembling the file from > blocks scattered all over the place, and what's the one thing about disk > drives that has remained a constant over the years, seek time. Therefore WAFL > file systems will slow over time, yuck. One other nasty item. Remember that > tree you need to update, well until a 'snapshot' (NetApp speak) occurs those > blocks that have been updated several times can't be reused therefore that 1GB > ! > disk file that you originally laid out could easily consume 100GB due to the > updates, inserts, etc... Double YUCK! How is that so you say, remember that > when you tell Oracle to create a datafile it acquires and formats all of the > disk space it needs, say 100MB, but all of it is empty blocks. Now you run a > SQL*Loader command to upload 50MB of data into that file. Well WAFL now needs > > 50MB of additional disk space to place all of those 'updated' blocks of data > into, so in reality the data file is now occupying ~150MB of space, but 50MB > of that is "hidden" from view until the snapshot fires. Fun part, your DB > stops running in the middle of the day due to a lack of disk space on your > NetAppliance. Your boss wants to know why your 10GB database has burned up a > 100GB NET App Filer. Of course you as a DBA don't know because the database > hasn't grown any. Add more egg on your face when the snapshot fires & bingo > there is 90GB of free space that 'suddenly' appears. The work! > around of course is to fire snapshots frequently and limit th! > e number > retained, but that just adds workload to the NetApp when I want it servicing > the database! As an old mentor once said, "You can't win for loosing!". > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > > -----Original Message----- > Sent: Friday, September 19, 2003 11:50 AM > To: Multiple recipients of list ORACLE-L > > > > This is actually platform dependent. For example, if you're using UDP > mounts under Linux, you can only have one request outstanding per mount. > Consequently, multiple mounts can improve performance by allowing parallel > operations. > > A side benefit of Oracle on Netapp is WAFL, which as Dick pointed out, > stands for Write Anywhere File Layout. Basically, an update to a block does > not cause a disk seek and an update - the system simply goes to the first > available raid stripe that's free and writes the block there, then updates > the tree. Besides being rather crafty, it creates a situation where > compound writes to multiple files - like a tablespace update and an index > update - migrate close to each other on disk. I/O patterns "train" the > filesystem structure. > > To actually answer your original question, it will not make a difference on > most platforms that are properly configured. What will make a difference is > your network settings. Are you using Gigabit + jumbo frames? > > Matt > *still pleased with how crafty WAFL is* > > -- > Matthew Zito > GridApp Systems > Email: [EMAIL PROTECTED] > Cell: 646-220-3551 > Phone: 212-358-8211 x 359 > http://www.gridapp.com > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Tanel Poder >> Sent: Friday, September 19, 2003 3:25 AM >> To: Multiple recipients of list ORACLE-L >> Subject: Re: asynch I/O >> >> >> Hi! >> >> You can have spread your datafiles in 1, 2, 3,4 ..100 >> different directories or mount points, but the performance >> remain the same for all of them as long as all the mount >> points are striped on the same disks. >> >> If you think of mount points as different sets of disks, e.g. >> when adding a new mount point, you add more disks, then yes, >> IO performance will improve, because larger number of disks. >> >> Tanel. >> >> >> ----- Original Message ----- >> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> >> Sent: Friday, September 19, 2003 5:09 AM >> >> >>> Could you clarify something for me? Are you saying that if I have a >> variety >>> of 'mounts' on our netapp >>> >>> say >>> >>> /mnt1 >>> /mnt2 >>> >>> I would not benefit by putting my datafiles on seperate ones? I >>> thought >> that >>> is where my I/O waits are coming from. Since we have all of our >>> datafiles >> in >>> the same directory? >>> >>> -- >>> Please see the official ORACLE-L FAQ: http://www.orafaq.net >>> -- >>> Author: Ryan >>> INET: [EMAIL PROTECTED] >>> >>> Fat City Network Services -- 858-538-5051 http://www.fatcity.com >>> San Diego, California -- Mailing list and web >> hosting services >>> >> --------------------------------------------------------------------- >>> To REMOVE yourself from this mailing list, send an E-Mail message >>> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in >>> the message BODY, include a line containing: UNSUB ORACLE-L (or the >>> name of mailing list you want to be removed from). You may >> also send >>> the HELP command for other information (like subscribing). >>> >> >> >> -- >> Please see the official ORACLE-L FAQ: http://www.orafaq.net >> -- >> Author: Tanel Poder >> INET: [EMAIL PROTECTED] >> >> Fat City Network Services -- 858-538-5051 http://www.fatcity.com >> San Diego, California -- Mailing list and web hosting services >> --------------------------------------------------------------------- >> To REMOVE yourself from this mailing list, send an E-Mail message >> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') >> and in the message BODY, include a line containing: UNSUB >> ORACLE-L (or the name of mailing list you want to be removed >> from). You may also send the HELP command for other >> information (like subscribing). >> -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
