Re: Re-building a database server

We're in the same boat here, and unfortunately, there isn't much you can do about it. We actually have a consultant here from Informix who is an expert in Lawson systems, and he claims that other than doing an iterative reorg (i.e., use dbreorg to get everything out of dbspace X, drop dbspace X, re-create dbspace X with better name, move stuff back, repeat for dbspace Y), the only thing you can do is use Informix to do a reorg, and Lawson utilities be damned. The catch here is that once you use Informix utilities, the Lawson utilities will no longer work. This isn't necessarily bad. The application and users are unaffected, it's just the Lawson administrative tools that go South. So once you've messed with something in Informix, you need to use Informix's tools (onstat, ALTER FRAGMENT, etc.) instead of Lawson's tools. If you want to do this the "Lawson Affirmed" way, you basically have to do a dbdump of the existing product line(s), drop everything db-wise, re-create everything (using the lawson tools) and do a dbload (Lawson's, not Informix's). Yuck! And that assumes that you have enough file system space to do the dbdump! In our environment, we're at almost 30 GB, and we've got a GL120 reorg of the "GLTRANS" table which we estimate will take better than 90 hours gate to gate. Ouch! We asked if there's any way to speed this up or work around it, and Lawson's answer is "nope." Regarding mirroring, you're probably best to do all the loads/reorgs first, and then add mirroring after the fact. This will probably be somewhat faster (although not necessarily dramatically so). Neil Truby wrote in message <364B5DC3.7443@netcomuk.co.uk>... >I have a client with a database server (v7.24) which contains a single >database, but which has multiple dbspaces. It's important that a table >remains in its allocated dbspace because the application (Lawson) >maintains its own table/dbspace mapping. > >I want to re-build the database server because it currently has stupid >chunk names, and I want to impose a new standard. Obviously I must >dbexport or ununload, then scrap and re-build the server, then >dbimport/onload. > >I'll have no problems restoring tables to their allocated dbspaces with >dbimport. But it will be slow (this is a 10GNyte database). But onload >will only restore all tables to the dbspace specifed in my onload >statement. > >Does anyone have any other ideas? > >Thanks > >Neil Truby >aracnet Limited >Weybridge, UK > >P.S. Furthermore, I may want to repeat this exercise on another client's >v5.02 server, and put mirroring on the re-built server. Does anyone >have any views on whether it's quicker to re-build the server first with >dbimport/tbload, THEN put on mirroring, or vice-versa?