Re: Planning an Informix Database disk layout

In article <6vb7k1$krp$1@news.xmission.com>, "Wilson, David G" <david.g.wilson@nz.eds.com> wrote: > > Hi everyone.... > > Can anyone advise me if there have been any articles written, and ae > available on the web, about a disk layout strategy? We are in the > process for planning the disk layout of a 150Gb system with 300+ tables. > > 1. Do we put the data into multiple DBSpaces? > 2. Do we separate the indexes from the data or put the whole lot into > one big pool? > > To further complicate matters, data is being loaded over a 2 year period > on a geographical basis. This means that the data for the largest region > and most highly accessed will be in the end of the tables or last > extents. In an attempt to reduce the number of extents I though we could > make them initially large, however in the "one large pool" scenario this > would place all the initial extents on the same chunk thus channelling > all the IO to the one disk and not spreading the load. > > The plan at this stage: > > RAID 1 > Root DB Space > Physical Logs Space > Logical Logs Space > > No RAID > Temp DB Space > > RAID 5 > Data DB Space > Index DB Space <--- has potential to be merged with Data DB > Space > Smart Blobs DB Space > > You'll notice the introduction of RAID 5 here. > > So, any therories, or references? > In general, maximize your throughput by spreading disk i/o as evenly as you can over your controllers and disks to decrease bottlenecks. Mind which tables you are placing together on a disk -- you want high/low access together. Fragmenting your tables helps spread i/o around. (Some people might tell you that horizontal fragmentation strategies and raid don't mix -- but we found that they do quite well). If you have large central hgih-use tables, fragment these tables over a their own dbspaces (can't do a table level recover, but can recover dbspace, if table has own dbspace, can recover only table). For example: table geo_data might have geodbs 1-8 dbspaces dedicated to it (fragmented by roundrobin or expression, depending how you use it). Definately use raw partitions. We separate plog and llog into each own log space. We also separate indexes into own idx dbspace if table is large or fragmented (we use >300,000 rows roughly). Also if you can specify your chunks per partition so you don't have to deal with offsets, its much easier to administer, especially if you are dealing with many chunks. We allocate chunks in 2G increments, avoiding offsets. We use raid 3+1 -- 3 usable 2.G partitions per disk, 1 parity partition. We also have 1-to-1, where we've placed our logical and physical log dbspaces, as well as temp dbspaces. 1-to-1 is much faster for writes than other raid types. If you're like most shops, you're probably a combination of DSS and OLTP environments -- so separating your logs will benefit you. Also -- having more than one index dbspace decreases potential bottlenecks. The Performance Tuning Guide has some helpful hints you might want to look at. You can access one on the Informix website. Hope this helps. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own