RE: asynch I/O

True, true - snapshot management in database environments is certainly a pain point with Netapps, and its also true that the performance degradation due to filesystem aging is negative as well. However, a lot of that is mitigated through the use of lots of spindles, the fact that "tied" disk blocks tend to migrate near each other on disk, and the netapp's large read cache. Netapp definitely benefits more from high spindle count than traditional storage arrays - and is the only array using RAID-4 (contiguous write aggregation mitigates the dedicated parity disk as a bottleneck).

Thanks,
Matt

--
Matthew Zito
GridApp Systems
Email: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com



> -----Original Message-----

> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On 

> Behalf Of Goulet, Dick

> Sent: Friday, September 19, 2003 12:35 PM

> To: Multiple recipients of list ORACLE-L

> Subject: 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.com

> 

> > -----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).

> 


-- 
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).