Defining chunks and extents using RAIS 5

Is there any performance gains separating rootdbs, logdbs, physdbs and datadbs when we use RAID 5? For the same reason should I define the apropriate first and next extents for tables? Thanks in advance, -- Ricardo Palmeira Tribunal de Contas do Estado de Pernambuco mailto:palmeira@tce.pe.gov.br

Ricardo Palmeira Tenório wrote: > > Is there any performance gains separating rootdbs, logdbs, physdbs and > datadbs when we use RAID 5? > For the same reason should I define the apropriate first and next > extents for tables? Yes, definitely performance gains and TREMENDOUS safety gains, you will sleep better knowing you cannot loose you data and logs in one fell swoop. Setting extent sizes to reduce fragmentation, as well as using multiple data dbspaces to isolate busy tables from each other to further enhance performance and reduce fragmentation, can have definite positive value. Please look up my periodic rants (I'm just too tired to rehash this in full right now) about NOT using RAID 5 for database chunks in the IIUG archives of this newsgroup or read the relevant sections of my recent TechNotes article on tuning. I STRONGLY dislike RAID 5 for database chunks and with the price of drives today completely reject ANY cost based objection to using Informix mirror, RAID1 or RAID10 instead. FWIW. Art S. Kagel

In article <79rrgs$buf$1@news.xmission.com>, palmeira@tce.pe.gov.br wrote: > > Is there any performance gains separating rootdbs, logdbs, physdbs and > datadbs when we use RAID 5? Before I go into performance aspects of RAID 5, let me suggest that you separate these dbspaces for monitoring and maintenance reasons alone. Disregard performance in this case, because splitting the dbspaces will definitely not hurt the situation. Performance on RAID 5 is debatable. The disk striping methodology that RAID 5 uses is so fine, that the "round-robin" format you end up with is pretty darn good. Splitting the dbspaces for performance reasons alone, whether you are in a DSS or OLTP environment, is fairly trivial. The control that optimal disk placement gives you would be the one reason I can think of to justify splitting dbspaces for performance reasons alone. However, I don't believe that RAID 5 technology allows you to build dbspace chunks in optimum disk locations (outer middle, inner middle, etc.). RAID just sort of "takes over". Most people would tell you not to even consider using RAID 5 in an OLTP environment, but it really depends on how DML intensive the application(s) is/are. I think the fine line is roughly around 30% writes/70% reads before you should even worry about considering other options. If you are running an OLTP environment, you should consider your disk write percentage vs. RAID write penalty above dbspace splitting. > For the same reason should I define the apropriate first and next > extents for tables? You should always size your first and next extents appropriately in order to prevent extent interleaving. This is true whether you use RAID 5 or not. > > Thanks in advance, > > -- > > Ricardo Palmeira > Tribunal de Contas do Estado de Pernambuco > mailto:palmeira@tce.pe.gov.br > Hope this helps, Bob ------------ -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own