RE: The legacy of bad chunk names

Anyway to use HPL for this issue, maybe piped to compress?? Much faster than dbexport . . . . John Carlson Informix DBA EDS - WHSmith USA 3200 Windy Hill Road, Suite 1500 West Atlanta, GA 30330 > -----Original Message----- > From: Art S. Kagel [mailto:kagel@bloomberg.net] > Sent: Friday, September 29, 2000 2:05 PM > To: informix-list@iiug.org > Subject: Re: The legacy of bad chunk names > > > If your OS can handle files >2GB then myexport can handle it. Let me > know, Neil, if you want to give it a try, I have a new version in > testing I can give you that will unload the tables in > parallel! instead > of serially, great for larger databases. I have not uploaded it yet > because I have not worked the kinks out of the parallel myimport but > the myexport part works like a charm. > > Art S. Kagel > > Neil Truby wrote: > > > > Lateral thinking please! > > > > When I joined my client's site they were already on IDS > v7.24, but all the > > chunk names are > /opt/informixV7.13/dbspaces1/lawson_default_1 etc. It was > > set up this way because of a lack of foresight by the DBA. > > > > Now we're on v9.20, but still with the /opt/informixV7.13 > ... chunknames! > > It's really quite confusing but, more importantly, it's > high;y unpleasing > > aesthetically. I can't see that we can ever get away from > it. IDS 9.20 has > > re-introduced the old v7.24 bug in onunload where it tries > to put indexes > > into into their original dbspaces (well done those people > in QA!). But even > > if they hadn't, a "feature" of IDS9.2x, hightlighted by Art > Kagel et al, is > > that you cannoy use onunload to unload a database converted > from v7.2x. > > > > The database in question is over 200GBytes in size. So dbexport is > > untenable. Are we destined to be stuck with informixV7.13 > names forever? >

Yes, but with the 500+ table sin a Lawson schema, HPL is a high-maintenance solution. John Carlson <John_Carlson@whsmithusa.com> wrote in message news:8r32k4$sds$1@news.xmission.com... > > Anyway to use HPL for this issue, maybe piped to compress?? > > Much faster than dbexport . . . . > > John Carlson > Informix DBA > EDS - WHSmith USA > 3200 Windy Hill Road, Suite 1500 West > Atlanta, GA 30330 > > > > > -----Original Message----- > > From: Art S. Kagel [mailto:kagel@bloomberg.net] > > Sent: Friday, September 29, 2000 2:05 PM > > To: informix-list@iiug.org > > Subject: Re: The legacy of bad chunk names > > > > > > If your OS can handle files >2GB then myexport can handle it. Let me > > know, Neil, if you want to give it a try, I have a new version in > > testing I can give you that will unload the tables in > > parallel! instead > > of serially, great for larger databases. I have not uploaded it yet > > because I have not worked the kinks out of the parallel myimport but > > the myexport part works like a charm. > > > > Art S. Kagel > > > > Neil Truby wrote: > > > > > > Lateral thinking please! > > > > > > When I joined my client's site they were already on IDS > > v7.24, but all the > > > chunk names are > > /opt/informixV7.13/dbspaces1/lawson_default_1 etc. It was > > > set up this way because of a lack of foresight by the DBA. > > > > > > Now we're on v9.20, but still with the /opt/informixV7.13 > > ... chunknames! > > > It's really quite confusing but, more importantly, it's > > high;y unpleasing > > > aesthetically. I can't see that we can ever get away from > > it. IDS 9.20 has > > > re-introduced the old v7.24 bug in onunload where it tries > > to put indexes > > > into into their original dbspaces (well done those people > > in QA!). But even > > > if they hadn't, a "feature" of IDS9.2x, hightlighted by Art > > Kagel et al, is > > > that you cannoy use onunload to unload a database converted > > from v7.2x. > > > > > > The database in question is over 200GBytes in size. So dbexport is > > > untenable. Are we destined to be stuck with informixV7.13 > > names forever? > >