Dennis, That's awfully kind of you - I'd love to write a book on storage and Oracle (since I've dedicated a troubling amount of my life to those two things), but I have the faint suspicion that the last 100 pages would be nothing but "All Stripe and No Parity Makes Matt a Dull Boy".
The "try not to be too smart" comment (in retrospect) comes off as a little bit snarky, but I just meant that a lot of the conventional wisdom about configuring storage that makes perfect sense when reasoned out can not apply because of storage/OS/driver vendor X's attempt to be crafty. In some ways, the growth of the monolithic storage array really screwed things up for those of us in the trenches - as vendors scrambled to beat each other in featureset and performance, more and more "innovation" went into the array. Suddenly storage arrays and other hardware/software storage components are making some very aggressive decisions about how they're going to manage your data (and getting more aggressive all the time), and the complexity has gotten to a degree that even the vast majority of vendor representatives can't in-detail describe how the algorithms used work. Thanks, Matt -- 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 DENNIS WILLIAMS > Sent: Tuesday, July 15, 2003 1:04 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: should you seperate indexes from tables in > seperate datafiles > > > Matt > Thanks so much for your posting. I especially appreciated > your comment "try not to be too smart". Would you consider > writing a book on the topic of "I/O Devices for the Oracle > DBA"? I would like to learn more, but don't know where to begin. > > Dennis Williams > DBA, 80%OCP, 100% DBA > Lifetouch, Inc. > [EMAIL PROTECTED] > > > -----Original Message----- > Sent: Tuesday, July 15, 2003 12:15 PM > To: Multiple recipients of list ORACLE-L > datafiles > > > > Hrrrmmmm - as a wine-drinking, vegetarian, non-weightlifting > new yawk city boy, this explains why I never fit in with the > storage crowd.... > > However, to address the original idea about striping across > lots of disks, etc., you have to be very careful about how > you configure your storage volumes depending on your storage > arrays. The "intelligence" that is built-in to high-end > frames can be outsmarted (for better or > worse) by certain storage configurations. Case in point - > you have an EMC array that exposes 9 GB RAID-1 volumes that > you use Veritas to create stripe sets across. You make a > 10-volume RAID-0 stripe and following the "match the > filesystem block size to the oracle block size" principle you > make the stripe depth 8k. This makes a certain degree of > sense - linear reads and writes getting distributed among a > number of physical spindles, helps mitigate hotspots, etc. > However, on a Symmetrix, this will yield poor(er) performance > results. This is because of two factors - one, regardless of > the I/O on the host side, the Symm will always do backend I/O > and cache allocation in 32k objects and two, the symmetrix > readahead won't kick in until it sees two or three sequential > tracks being requested within a certain minimum amount of > time. So, the small stripe size ends up unnecessarily > placing objects in cache and negates the readahead that can > provide large performance enhancements. There's a whole host > of oddities like these that are present in all of the major > storage vendors, so you have to be aware of what's going to happen. > > The moral of the story is, of course, the more expensive your > storage array, the more you benefit by knowing the hows and > whys of what your storage array does. Also try not to be too > smart about how you set up your storage unless you have a > very deep understanding of the intelligence behind the > storage - it'll help keep you from shooting yourself in the > foot. I've seen too many oracle DBAs spend hours creating a > "highly tuned" storage configuration based on faulty or > lacking information on how the storage array actually works > and then they complain about how slow the array is.... > > Thanks, > > Matt > > -- > 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 Stephen Lee > > Sent: Tuesday, July 15, 2003 10:25 AM > > To: Multiple recipients of list ORACLE-L > > Subject: RE: should you seperate indexes from tables in > > seperate datafiles > > > > > > > > Steroids, weight lifting, and a flattop hair cut (orange or > > green). After two years of this, try talking to the storage > > guys while holding a beer in one hand and a Polish sausage in > > the other. If you can manage a good belch during the > > conversation, even better. > > > > (Are you a visual person?) > > > > > -----Original Message----- > > > get to control how my disks are set up (part of that "now > > now little > > > girl, don't you worry your pretty little head about how the > > disks are > > > set up, you just leave that sort of stuff to us big <male> > > data center > > > operations people" crap I get) > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Stephen Lee > > 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: Matthew Zito > 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: DENNIS WILLIAMS > 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: Matthew Zito 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).
