fragmentation on SAN environment

All, I did a load of table that use to take 4 hours (20 m rows - with 2 text fields). After fragmentation with no change in anything else (divided into 20 dbspaces) the load took only 52 min. But I am not able to convince my boss that fragmentation is helping him. He wants more justification to impliment fragmentation. We are using informix 7.31 using SAN and Cooked File for the cunks (NO RAW devices - don't ask me why) Can someone guide me as to where will I find documented befefits of using Fragmentation under SAN disk environment. Thanks, Sunil Thakkar. ******************************************************************************** ******************* The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ******************************************************************************** *******************

DO NOT POST MIME/HTLM HERE! Most of us cannot read it. Looks like this below: Art ----- Original Message ----- From: Sunil Thakkar <ids@iiug.org> At: 2/16 11:28 All, I did a load of table that use to take 4 hours (20 m rows - with 2 text fields). After fragmentation with no change in anything else (divided into 20 dbspaces) the load took only 52 min. But I am not able to convince my boss that fragmentation is helping him. He wants more justification to impliment fragmentation. We are using informix 7.31 using SAN and Cooked File for the cunks (NO RAW devices - don't ask me why) Can someone guide me as to where will I find documented befefits of using Fragmentation under SAN disk environment. Thanks, Sunil Thakkar. ******************************************************************************** ******************* The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ******************************************************************************** ******************* ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Thakkar, Sunil said: > > All, > > I did a load of table that use to take 4 hours (20 m rows - with 2 text fields). After fragmentation with no change in anything else (divided into 20 dbspaces) the load took only 52 min. > > But I am not able to convince my boss that fragmentation is helping him. He wants more justification to impliment fragmentation. > > We are using informix 7.31 using SAN and Cooked File for the cunks (NO RAW devices - don't ask me why) > > Can someone guide me as to where will I find documented befefits of using Fragmentation under SAN disk environment. > > Thanks, > > Sunil Thakkar. > > h no change in anything else (divided into 20 dbspaces) the load took only 52 min. But I am not able to convince my boss that fragmentation is helping him. He wants more justification to impliment fragmentation. We are using informix 7.31 using SAN and Cooked File for the cuQ¡…­­…ȸ4(€4 -- Bye now, Obnoxio "Jesus you fucking people are hopeless." -- Double Anal "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com

According to Adcott's binary translator, OTCs response is MUCH prettier in base 2: 01100001 01000011 01000010 01110101 01100010 01111001 01000010 01101010 01100001 01000111 01000110 01110101 01011010 00110010 01010101 01100111 01100001 01010111 00110100 01100111 01011001 01010111 00110101 00110101 01100100 01000111 01101000 01110000 01100010 01101101 01100011 01100111 01011010 01010111 01111000 01111010 01011010 01010011 01000001 01101111 01011010 01000111 01101100 00110010 01100001 01010111 01010010 01101100 01011010 01000011 01000010 01110000 01100010 01101110 01010010 01110110 01001001 01000100 01001001 01110111 01001001 01000111 01010010 01101001 01100011 00110011 01000010 01101000 01011001 00110010 01010110 01111010 01001011 01010011 01000010 00110000 00100000 00001101 00001010 01100001 01000111 01010101 01100111 01100010 01000111 00111001 01101000 01011010 01000011 01000010 00110000 01100010 00110010 00111001 01110010 01001001 01000111 00111001 01110101 01100010 01001000 01101011 01100111 01001110 01010100 01001001 01100111 01100010 01010111 01101100 01110101 01001100 01100111 00110000 01001011 01001001 01000001 00110000 01001011 01010001 01101110 01010110 00110000 01001001 01000101 01101011 01100111 01011001 01010111 00110000 01100111 01100010 01101101 00111001 00110000 01001001 01000111 01000110 01101001 01100010 01000111 01010101 01100111 01100100 01000111 00111000 01100111 01011001 00110010 00111001 01110101 01100100 01101101 01101100 01110101 00100000 00001101 00001010 01011001 00110010 01010101 01100111 01100010 01011000 01101011 01100111 01011001 01101101 00111001 01111010 01100011 01111001 01000010 00110000 01100001 01000111 01000110 00110000 01001001 01000111 01011010 01111001 01011001 01010111 01100100 01110100 01011010 01010111 00110101 00110000 01011001 01011000 01010010 01110000 01100010 00110010 00110100 01100111 01100001 01011000 01001101 01100111 01100001 01000111 01010110 01110011 01100011 01000111 01101100 01110101 01011010 01111001 01000010 01101111 01100001 01010111 00110000 01110101 01001001 01000101 01101000 01101100 01001001 01001000 01100100 01101000 01100010 01101110 01010010 01111010 01001001 01000111 00110001 01110110 00100000 00001101 00001010 01100011 01101101 01010101 01100111 01100001 01101110 01010110 01111010 01100100 01000111 01101100 01101101 01100001 01010111 01001110 01101000 01100100 01000111 01101100 01110110 01100010 01101001 01000010 00110000 01100010 01111001 01000010 01110000 01100010 01011000 01000010 01110011 01100001 01010111 00110001 01101100 01100010 01101110 01010001 01100111 01011010 01101110 01001010 01101000 01011010 00110010 00110001 01101100 01100010 01101110 01010010 01101000 01100100 01000111 01101100 01110110 01100010 01101001 00110100 01100111 01000100 01010001 01101111 01100111 01000100 01010001 01110000 01011000 01011010 01010011 01000010 01101000 01100011 01101101 01010101 01100111 00100000 00001101 00001010 01100100 01011000 01001110 01110000 01100010 01101101 01100011 01100111 01001001 01000111 01101100 01110101 01011010 01101101 00111001 01111001 01100010 01010111 01101100 00110100 01001001 01000100 01100011 01110101 01001101 01111010 01000101 01100111 01100100 01011000 01001110 01110000 01100010 01101101 01100011 01100111 01010101 00110000 01000110 01001111 01001001 01000111 01000110 01110101 01011010 01000011 01000010 01000100 01100010 00110010 00111001 01110010 01011010 01010111 01010001 01100111 01010010 01101101 01101100 01110011 01011010 01010011 01000010 01101101 01100010 00110011 01001001 01100111 01100100 01000111 01101000 01101100 01001001 01000111 01001110 00110001 00100000 00001101 00001010 01010101 01100001 01000111 01000110 01110010 01100001 00110010 01000110 01111001 01001100 01100111 00110000 01001011 01001001 01000001 00110000 01001011 00100000 -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Obnoxio The.... Sent: Thursday, February 16, 2006 11:48 AM To: ids@iiug.org Subject: Re: fragmentation on SAN environment [6415] Thakkar, Sunil said: > > All, > > I did a load of table that use to take 4 hours (20 m rows - with 2 text fields). After fragmentation with no change in anything else (divided into 20 dbspaces) the load took only 52 min. > > But I am not able to convince my boss that fragmentation is helping him. He wants more justification to impliment fragmentation. > > We are using informix 7.31 using SAN and Cooked File for the cunks (NO RAW devices - don't ask me why) > > Can someone guide me as to where will I find documented befefits of using Fragmentation under SAN disk environment. > > Thanks, > > Sunil Thakkar. > > h no change in anything else (divided into 20 dbspaces) the load took only 52 min. But I am not able to convince my boss that fragmentation is helping him. He wants more justification to impliment fragmentation. We are using informix 7.31 using SAN and Cooked File for the cuQ¡…­­…ȸ4(€4 -- Bye now, Obnoxio "Jesus you fucking people are hopeless." -- Double Anal "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.