Re: refragging a table
Ah ok. Well that takes care of that then. I won't be checking any further into that. We're trying to get some better query times. Hey Art, here's one for ya. My boss is trying to save money again. He has this bright idea that raid 5 has as good as, or almost as good as read speed as raid 10. So he is wanting to consider putting some of our older data that is never written to, on fragments that are attached to raid5. Whatchya think of that ? I know how you feel about raid5. haha. ======================== -<<Floyd Wellershaus>>- Database Administrator Unix Administrator email: fwellers@yahoo.com Home: 703-430-0805 Cell: 703-477-6045 ======================== http://www.one.org/ ----- Original Message ---- From: Art S. Kagel <kagel@BLOOMBERG.NET> To: Floyd Wellershaus <fwellers@YAHOO.COM> Cc: Yunyao (Frank) Qu <Yunyao.Qu@noaa.gov>; bozon <curtis@crowson1.com>; informix-list@iiug.org Sent: Tuesday, July 18, 2006 5:14:39 PM Subject: Re: refragging a table Floyd Wellershaus wrote: > Gotchya. Thanks. > > Hey, I was reading the old performance tuning book, and noticed they > made mention of a supposedly EXCELLENT way of fragmenting a serial and > or an integer field, using mod. > > something like mod(token, 3) = 0 in dbs1 > mod (token 3) = 1 in dbs2 > > Does anyone know where I can get further info on that ? > <SNIP> It's a normal hash fragmentation scheme, that's in the Guide to SQL Syntax manual. It does load balance and roughly evenly spread the IOs. It is VERY efficient for rapid data insertion from multiple clients. However, there can be no fragment elimination so much of the savings at query time are traded away for the insert throughput. Art S. Kagel
Floyd Wellershaus wrote: > Ah ok. Well that takes care of that then. I won't be checking any > further into that. We're trying to get some better query times. > Hey Art, here's one for ya. My boss is trying to save money again. He > has this bright idea that raid 5 has as good as, or almost as good as > read speed as raid 10. So he is wanting to consider putting some of our > older data that is never written to, on fragments that are attached to > raid5. > Whatchya think of that ? I know how you feel about raid5. haha. Does he LIKE his historical data? If these disks are seldom accessed how will he know if the disks have degraded? How will he know if ANY of the last <N> archives (where N is the number of back archives you keep) even has a good version of the data from before the drives began to go south? You know how I feel, while important, the whole RAID5 write penalty issue is the least of the several problems with RAID5. Just point him at the BAARF web site and let him read my paper, the papers from experts working for Oracle like Carl Millsap's paper on configuring RDBMS servers for VLDB environments and Juan Loaiza's discussion Optimal Storage configuration where he pushes the SAME strategy which is essentially RAID10, and the many comments on the members' 'why I joined' area. (www.baarf.com) Art S. Kagel > ======================== > -<<Floyd Wellershaus>>- > Database Administrator > Unix Administrator > > > email: fwellers@yahoo.com <mailto:fwellers@yahoo.com> > > Home: 703-430-0805 > > Cell: 703-477-6045 > ======================== > > http://www.one.org/ > > > ----- Original Message ---- > From: Art S. Kagel <kagel@BLOOMBERG.NET> > To: Floyd Wellershaus <fwellers@YAHOO.COM> > Cc: Yunyao (Frank) Qu <Yunyao.Qu@noaa.gov>; bozon <curtis@crowson1.com>; > informix-list@iiug.org > Sent: Tuesday, July 18, 2006 5:14:39 PM > Subject: Re: refragging a table > > Floyd Wellershaus wrote: > > Gotchya. Thanks. > > > > Hey, I was reading the old performance tuning book, and noticed they > > made mention of a supposedly EXCELLENT way of fragmenting a serial and > > or an integer field, using mod. > > > > something like mod(token, 3) = 0 in dbs1 > > mod (token 3) = 1 in dbs2 > > > > Does anyone know where I can get further info on that ? > > > <SNIP> > > It's a normal hash fragmentation scheme, that's in the Guide to SQL Syntax > manual. It does load balance and roughly evenly spread the IOs. It is > VERY > efficient for rapid data insertion from multiple clients. However, there > can be no fragment elimination so much of the savings at query time are > traded away for the insert throughput. > > Art S. Kagel >