RE: The legacy of bad chunk names

Not necessarily . . . . I use it to do dbspace-level reorgs (inc. Lawson tables) quite easily . . . I have a script that autogenerates the required HPL information, then executes it as necessary, depending on the size of the table in question. > -----Original Message----- > From: Neil Truby [mailto:ntruby@netcomuk.co.uk] > Sent: Saturday, September 30, 2000 7:39 AM > To: informix-list@iiug.org > Subject: Re: The legacy of bad chunk names > > > 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? > > > > >