| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: asynch I/O
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: mzito_at_gridapp.com Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.comReceived on Fri Sep 19 2003 - 11:34:51 CDT
> -----Original Message-----
> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] 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" <ORACLE-L_at_fatcity.com>
> 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: rgaffuri_at_cox.net
> >
> > 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: ListGuru_at_fatcity.com (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: tanel.poder.003_at_mail.ee
>
> 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: ListGuru_at_fatcity.com (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: Matthew Zito INET: mzito_at_gridapp.com 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: ListGuru_at_fatcity.com (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: Goulet, Dick INET: DGoulet_at_vicr.com 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: ListGuru_at_fatcity.com (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).
 |
 |