RE: Do extents impact speed?

It is exactly because of the advances in technology,memory and disk size, that I first asked the question. We are using fully mirrored and striped logical volumes on AIX. We only have one or two mirrored disk pairs so there seems to be little benefit in putting different dbspaces/tables/fragments on different disks. (The only constraint we have on chunks is a 2Gbyte limit which comes from IDS 9.3 days) Doing a dbexport/dbimport to defragment is a non-starter. A VAR application is involved and they do not support the use of dbexport/dbimport. Instead they provide their own utility which is much slower but uses much less disk space. Also, there are thousands of tables, most of which are unused, but the tables that are used vary from site to site. Current performance is "acceptable" although nearly all of the customers have commented that the new hardware, new OS, IDS instead of SE, has given them no improvement in performance - and some say that it is worse. The only REAL reason I can see for defragmenting the tables is that on a few tables we are rapidly approaching the maximum number of extents but only on our Linux platforms. Regards Malcolm -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Neil Truby Sent: 03 September 2005 12:43 To: informix-list@iiug.org Subject: Re: Do extents impact speed? "Christopher Coleman" <Christopher.Coleman@mediware.com> wrote in message news:1125707836.27d72252da0b7b38721d279905f4197d@teranews... > > Yes, this many extents will almost certainly impact speed for the > worst. > At the very simple level, there would be a significant increase in disk > seek time. > > Even the Performance Guide says: "Performance suffers when disk seeks > for > a table must span more than one extent, particularly for sequential > scans." > http://publib.boulder.ibm.com/epubs/html/25122960/perf189.htm#idx2131 > > An even worse scenario is when the extents are no longer ordered > sequentially (i.e.. extent x, extent z, extent y). This means that, in > order to read through a table or index, the disk head must move backward > and forward, increasing the lag time. This can happen if some tables are > dropped or reorganized while other tables continue to grow, a common cause > of interleaving. Isn't this making some fairly sweeping assummptions about the nature of the storage technology in use (I know you went on to make this point in part, but I'm playing Devil's Advocate as I'd like to canvass views on how much if at all the above applies to cached SANs). Many users these days - although possibly not Malcolm's - will be using sophisticated, cached SANs where there will be a high level of indeirection between the apparent and actual physical layout. sending to informix-list